Re: setuid vs. EROS constructor

[Michal Suchanek]

On 10/13/05, Jun Inoue <address@hidden> wrote:
> On Wed, 12 Oct 2005 15:38:10 -0400
> "Jonathan S. Shapiro" <address@hidden> wrote:
>
> > 2. There is a set of applications. With very few exceptions, we want to
> > treat these applications as "presumed hostile". Most of the time they
> > will be fine. Sometimes they will have bugs. Rarely they will really be
> > out to hurt us. Where these applications are concerned we have two
> > objectives:
> >
> >   A. Restrict these applications to the narrowest set of authorities
> >      that will let them do their job.
> >
> >   B. In the places where these applications require access to the
> >      user's resources, make sure that the user has to consent
> >      specifically. Our open/save-as mechanism is an example of this.
>
> Agreed.  The problem is how to get that consent non-intrusively in an
> extensible manner.  (I think extensibility is crucial here; see below.)
>
>
> > 3. There is a set of mediators. Each user has their own set. The purpose
> > of a mediator is to allow users to grant specific authority to untrusted
> > applications, but to do so intentionally.
> >
> > Let me give an example of a mediator, because this idea sounds like it
> > should create a horrible overrun of "is this okay?" queries, but it does
> > not seem to in our limited experience.
> >
> > You have all seen a conventional file open dialog box. There are three
> > differences in the EROS version:
> >
> >   1. The rendering isn't done by the application.
> >   2. The code runs in a separate, user-supplied process.
> >   3. The return value is an open file capability, not a string.
> >
> > Instead of calling a library routine to put up an open dialog box, the
> > library routine performs an RPC to the user-supplied "open/save-as
> > agent". This agent runs user-selected code and acts entirely on behalf
> > of the user. The agent has access to the user files. The word processor
> > does not. The agent interacts with the user to find out what file to
> > open, opens it, and passes the desriptor back to the file.
>
> So it seems in essence you have a user-interface server, sort of like a
> subset of GTK or Qt implemented as a server rather than a shared
> library.  It has to be trusted, much like the shell is.

Or it could be part of the shell. You would have to modify every
toolkit or application (or run it in a special file-open wrapper that
allows it to open one file using its native way of  opening files, and
probably pick the file twice). But you can make all of them use the
same call to the same file-open server.
Of course, there are other capabilites than opening files. But I think
they can be generally managed either almost automatically (ie allowing
programs to allocate memory and cpu time, allowing web browsers to
open outgoing network connections) or they can be selected much like
files.

And the shell does not need to be the part you see. If I used
something like Nautilus as a shell it should be really a "shell
viewer". I would need some way to recover from Nautilus crashes, after
all. Nautilus does not need to get the capabilities, only display
queries from the applications that want file access and allow issuing
some commands to the actual shell.
That way random bugs in Nautilus are unlikely to corrupt the shell
state. An attacker with good knowledge about my system could still
craft a file that executes  arbitrary code inside Nautilus because of
its bugs. But I would have to get the file (ie in Firefox), save it,
and perform the action in Nautilus that triggers the bug (ie viewing
the directory with the file, although even the file-save dialog could
trigger the bug in some cases). This is what one pays for GUI. It is
too large to be bug-free.

Thanks

Michal Suchanek


--
             Support the freedom of music!
Maybe it's a weird genre  ..  but weird is *not* illegal.
Maybe next time they will send a special forces commando
to your picnic .. because they think you are weird.
 www.music-versus-guns.org  http://en.policejnistat.cz