Friendly and Secure Desktop Operating System
tss at iki.fi
Tue Oct 28 12:20:48 PST 2003
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
> 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
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
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://firstname.lastname@example.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
> 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
> Neat discussion; perhaps we can continue it on a more appropriate list?
More information about the freebsd-advocacy