From owner-freebsd-advocacy@FreeBSD.ORG Tue Oct 28 07:08:23 2003 Return-Path: Delivered-To: freebsd-advocacy@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 730F616A4CE for ; Tue, 28 Oct 2003 07:08:23 -0800 (PST) Received: from amsfep15-int.chello.nl (amsfep15-int.chello.nl [213.46.243.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F11A643FBF for ; Tue, 28 Oct 2003 07:08:21 -0800 (PST) (envelope-from dodell@sitetronics.com) Received: from sitetronics.com ([213.46.142.207]) by amsfep15-int.chello.nl (InterMail vM.5.01.05.17 201-253-122-126-117-20021021) with ESMTP id <20031028150820.ZZQS11138.amsfep15-int.chello.nl@sitetronics.com> for ; Tue, 28 Oct 2003 16:08:20 +0100 Message-ID: <3F9E8659.9040102@sitetronics.com> Date: Tue, 28 Oct 2003 16:08:09 +0100 From: "Devon H. O'Dell" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-advocacy@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Friendly and Secure Desktop Operating System X-BeenThere: freebsd-advocacy@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Evangelism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 15:08:23 -0000 Daniela wrote: >Found this link today, I thought it might be an interesting thing to discuss: >http://irccrew.org/~cras/security/friendly-secure-os.html > >Daniela > > While there are some good ideas presented in this, I don't think that the author has the faintest idea of what an operating system entails. It seems that the author is confusing application security with operating system security. Who's to say that some kernel module isn't going to pop up and say "I don't access any files" and then wipe the hard drive? How does the operating system know that the application is a game and not an email client? It seems more of an application design standard -- and one that will never work. For instance, many games need to be able to save files, access the net and do low-level graphics stuff that generally requires more privileges than, say a word processor. There are operating systems that do implement this in some regard, but they're by no means in any usable form. From a developer's standpoint this sounds more like a plea to application developers to "please write secure software". Another problem is that with the 'stupid user' model that's mentioned in the article, the OS has to handle things that should be decided by the user. You get into the question of where to stop trying to save the user from him/herself and where to let the user make decisions. Again, this is a problem that *application* developers need to address, not operating system developers. Finally, a lot of the stuff that's mentioned about services that the OS should provide is actually more Operating Environment specific. An OS need only provide stuff for memory management, CPU control, device detection and usage, APIs for userland applications to interface with these devices, privileges and privilege-based systems to help determine who may actually access the devices, etc. Some of these "services" sound like they belong in the OE. For instance, the argument about making each webpage load in a separate process has several flaws. When we're writing to the video card (assuming doing direct output to 0xb8000 in text mode -- just to keep it simple) how do you define where something can be drawn? The operating system provides a couple of interfaces to the video card in text mode and they all amount to sending bits to 0xb8000 - 0xb8fa0 (forgive me if the range is incorrect). How would you say "okay, this webpage only gets the 4th line of the screen (0xb81e0 - 0xb8280)"? This is stuff that the operating system itself does not and should not handle. And without the OS letting the application actually output raw bytes to this area and letting the application determine what can draw where, there's no way to tell this. Additionally, how do you define the policies of who will be able to write in what space? While the article tries to go into the right direction, it's missing a lot of points and using enough words in the wrong place that I think the author needs to do a bit more research. I'd be interested in seeing this article come further, but it needs to really answer some of these questions. --Devon P.S. Feel free to correct my ranges for outputting to the vga video buffer if I'm wrong; it's been a good year or two since I've done this stuff. I'm assuming 0xb8000 as starting (which I know is correct), plus 80 * 25 * 2.