Re: setuid vs. EROS constructor

[Jun Inoue]

On Wed, 12 Oct 2005 15:38:10 -0400
"Jonathan S. Shapiro" <address@hidden> wrote:

> I found Bas's note stunning, because I did not expect anyone to connect
> the dots about setuid vs. confinement so quickly. It is a point that
> usually requires several explanations. Indeed, setuid is not required at
> all in a capability system. The only thing that Bas missed is that if
> you have persistence you do not need a constructor server.

Do you mean we can run a "constructor process" indefinitely as a
translator?  For example if I compile a program foo, which needs my
capability bar, and make it accessible to everyone as /pub/jun/foo, I
would do:

run-with-cap bar /pub/jun/foo-constructor

Then I get a capability to an idle process, the foo constructor.  Let's
call it P.  I do:

settrans --active --persistent /pub/jun/foo P

Then P runs indefinitely as the active translator for node /pub/jun/foo.
Later, whenever someone types /pub/jun/foo, the process denoted by P
would spawn() the image (or fork() if foo-constructor contains an image
of foo), passing bar to it.  Thus, /pub/jun/foo will effectively be
setcap'ed, without the need for a central server.

But this scheme doesn't seem to leave room for others to verify
if /pub/jun/foo would leak additional capabilities given to it.  How is
the verification done on EROS?  Is it exact or conservative; ie can it
have false positives?


> 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.

What do I do if I'm not satisfied with the mechanism provided by the
mediators I already have?  Do I trust it blindly?  Do I inspect code?
It seems to me the number of components I must trust grows
proportionately to the number of incompatible user interfaces.  Or are
you saying that the number is managably small?


> Why do I say this about viruses?

Because they're a perfect example of what happens if the principle of
least authority is violated.  Yes?

-- 
Jun Inoue
address@hidden