Date: Tue, 28 Oct 2003 20:12:52 +0100 From: "Devon H. O'Dell" <dodell@sitetronics.com> To: Timo Sirainen <tss@iki.fi> Cc: freebsd-advocacy@freebsd.org Subject: Re: Friendly and Secure Desktop Operating System Message-ID: <3F9EBFB4.7040904@sitetronics.com> In-Reply-To: <1067367085.15026.38.camel@hurina> References: <1067367085.15026.38.camel@hurina>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F9EBFB4.7040904>