Friendly and Secure Desktop Operating System

[Devon H. O'Dell]

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.