Date: Tue, 28 Oct 2003 22:20:46 +0200 From: Timo Sirainen <tss@iki.fi> To: "Devon H. O'Dell" <dodell@sitetronics.com> Cc: freebsd-advocacy@freebsd.org Subject: Re: Friendly and Secure Desktop Operating System Message-ID: <1067372446.15029.97.camel@hurina> In-Reply-To: <3F9EBFB4.7040904@sitetronics.com> References: <1067367085.15026.38.camel@hurina> <3F9EBFB4.7040904@sitetronics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2003-10-28 at 21:12, Devon H. O'Dell wrote: > 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. That is the potentially difficult part to get secure while still being user friendly. It would need a popup on installation which would have a list of what potentially dangerous privileges application needs. But like you said, it would be painful if it was asked all the time. So the system should be designed in a way that 99% of software doesn't require any special privileges. I believe it's possible - most software don't really require anything all that special (see the examples section at the bottom of the web page). > >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? Kernel and all server processes. Application simply isn't allowed to do anything bad. For example if application is restricted to only one X window and it tries to create new one, the call will simply fail. If application tries to open/create files outside it's sandbox, the syscall returns with EACCES. etc. > >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? That's the problem I intended to solve using "Operating system services" and the "open/save file service". Applications by default can't access any files that it didn't create itself. When you want to access other files, you'd ask the open/save file service to pop up a window requesting user to specify which files the application is given access to. So the open file dialog wouldn't be displayed by openoffice but the open/save file service. Once you select the files, the service gives openoffice access to the selected files. I think this is the most important thing in the whole OS idea. Pretty much the only application needing access to all files is the file manager (or /bin/sh). Viruses aren't possible simply because no software you run can modify any existing files without explicitly requesting it. And you don't get any annoying popup requests about giving access to file /foo/bar because you already granted that permission in the open file dialog. This is how I hope most of the commonly needed security checks could be done, but I'm not sure if it applies much elsewhere. It might be possible to create "connect to network service" which would display a dialog where you could enter host name and port and after clicking OK the application could connect to only that host/port, but that doesn't probably work very nicely with user interfaces. Another similiar idea I thought of was with links in HTML email message: To prevent any email worms from working you'd create a separate highly restricted process to display the email. The process would have access to limited area in mail client's window to render the message. It wouldn't have access to network so spammers can't create emails that call home. For the same reason it shouldn't have ability to invoke other programs (like "mozilla http://www.evilspammer.com/email=foo@bar.org"). Now with HTML mails, how exactly would you allow user to click on an URL? Only the renderer process knows where the links are, but it can't launch applications to process them. One kind of workable solution would be to allow the renderer process to launch applications but only when user has clicked mouse button inside the window. That at least prevents email from doing anything automatically. Better solution would be to let the renderer process specify screen regions which contain URLs and what the URLs are. Then the parent process would do the actual launching. The URL would be displayed in application's status bar so user could look at it before actually launching it. Again no need for extra popup window which requests permission to launch web browser. > >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. Even running as non-root applications still have way too much control over your system. They can do anything with files you own. > And who's going to do all this work > making the applications conform to this 'standard'? Most applications wouldn't need hardly any changes. If you change GNOME/GTK and KDE/Qt libraries' open and save file dialogs to use the open/save file service, you could probably run most of the GNOME/KDE applications without any changes. You could give each of the applications a virtual filesystem where they could create their files but the actual files would always be created inside eg. ~/.application-name/ directory. That'd need a bit of thinking though since you can of course have two identically named binaries in different directories. Anyway, the point is that most of this could be done by changing a few widely used libraries. Existing web browsers and email clients could work just the same, but to get per-web page and per-email protection they would need larger changes. > 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. Exactly. It should do as much as possible quietly without getting on the way. > Neat discussion; perhaps we can continue it on a more appropriate list? Any suggestions?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1067372446.15029.97.camel>