Date: Tue, 28 Oct 2003 20:51:26 +0200 From: Timo Sirainen <tss@iki.fi> To: freebsd-advocacy@freebsd.org Subject: Re: Friendly and Secure Desktop Operating System Message-ID: <1067367085.15026.38.camel@hurina>
next in thread | raw e-mail | index | archive | help
> 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 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. > 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 filesystem). > 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 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067367085.15026.38.camel>