Friendly and Secure Desktop Operating System

[Devon H. O'Dell]

Hey, Timo

Thanks for checking this thread. Couple of comments here :).. First I 
want to say that I didn't mean to come across too harshly; it's a great 
idea, but I think there needs to be a good bit of clarification.

>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.
>  
>
Yeah, I did. I'm used to 'operating system checks' referring to the 
kernel. I'm not entirely sure where you are proposing these take place. 
I'd like to see this clarified.

>>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
>applications.
>
>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.
>  
>
What happens when a module or application (virus) comes across and says 
"I need access to this, this, this and this". Do these get granted or 
not? Does a window pop up and say "hey, this is trying to access x part 
of the system, is this okay with you?" If so, initial configuration 
would be a pain in the ass; you'd get popups for every app that ran.

>>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.
>  
>
Right, so a lot of what you're suggesting is actual application security 
and a set of protocols that applications could conform to. But what's to 
say that an application won't conform to these standards?

>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.
>  
>
Ah, ok, that clarifies my question a bit better :).

>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
>filesystem).
>  
>
What if I'm starting abiword and I want to do some shit with a file I 
made in openoffice? Do user ownerships then kick into effect?

>>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.
>  
>
Applications *don't* have full control of the system unless you allow 
them to do so. Running a process as a regular user will never allow you 
to access /dev/kmem for instance. And who's going to do all this work 
making the applications conform to this 'standard'?

>>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 :)
>  
>
Yeah sorry, I was being a bit pedantic.

>..
>
>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
>processes.
>
>- 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.
>  
>
It's a lot of work and it needs to be clarified on a couple of points 
still, but I think it's a neat idea. Except I don't think that it should 
try too hard to save said user from him/herself. Being TOO verbose is 
also not good.

Neat discussion; perhaps we can continue it on a more appropriate list?

--Devon