Friendly and Secure Desktop Operating System

Timo Sirainen tss at
Tue Oct 28 10:51:28 PST 2003

> 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.

I think you didn't really understand what I was trying to say there. I
guess the web page isn't written well enough. I did begin writing a bit
better structured one with better explanations but got tired with it.

By operating system I mean the whole thing, not just the kernel. You seemed
to assume that all these security checks would be done by the kernel.

> 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?

Normal user most likely can't install kernel modules. I was talking about

But since you asked, it would be possible with microkernels since kernel
modules are running in user space. Kernel would give access to hard disk
only if the module says it needs it. The same goes with userspace processes.

> 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.
> 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 

Games could be a bit problematic, but they still don't access the hardware
directly. They use X11, OpenGL, DirectX or similiar APIs which then do the
actual drawing through some display system/driver.

AFAIK OpenGL and X11 SHM extension moves all the data through X server, so
it's only X server process that has any direct access to video hardware. So
here the security checks would be placed in the X server - a given X
session would be allowed to draw only inside a specific window.

So processes created by eg. clicking some executable in desktop would be
allowed to change video mode and take control of the full screen to be able
to run games and such. Web page processes on the other hand wouldn't have
been given such privilege, they'd be restricted to only specific X window.

Saving files isn't a problem - all processes would be able to save and read
files they already created (but nothing else). Launcher process would
decide if the files are permanent or temporary and the actual location of
the files (inside the launcher process's possibly restricted view of

> 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.

I don't believe I said anything like that. User still has full control of
the system, it's just that applications don't anymore have full control
of the system without explicitly requesting such permission from user.

> 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.

"dict 'operating system'" says to me that operating system is more than
just the kernel. But if you disagree, feel free to do
s/Operating System/Operating Environment/g before reading the web page :)


It wouldn'ta actually be all that difficult to implement it. If I'd base
it on top of existing UNIX kernel and X11, they'd mostly just need:

- Mandatory access control in kernel (eg. systrace). Possibility for
processes to give their existing privileges to other existing processes.
Possibility for processes to drop privileges from itself or child

- X11 access control extension which would let processes to define what
specified X connections are allowed to do. X server changes to enforce
these restrictions. Might require changes to the X protocol itself.

- Userspace applications to tie these into simple to use environment.

More information about the freebsd-advocacy mailing list