Re: setuid vs. EROS constructor

[Bas Wijnen]

On Wed, Oct 12, 2005 at 03:38:10PM -0400, Jonathan S. Shapiro 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.

You do.  I think you misunderstood what I meant by constructor server.  It is
equivalent to the EROS constructor, in that it constructs a process with some
capabilities.  The reason I called it a server is that it must be a process,
not just an executable file on disk.  This is because only processes can hold
capabilities in the Hurd.

> However: Bas has not taken the last step. If he digs a bit deeper he
> will soon conclude that uids of any sort are a bad idea altogether.

I already concluded that, but we need them anyway.  We want to be mostly
POSIX-compliant, and that isn't possible without them.  However I do agree
that the UID capability should almost never be passed on to children by the
shell, so in effect it shouldn't really be used.  But it should exist, and it
should be passed on to processes which don't understand anything else.

Of course users who care about security will not want to use those programs
:-)

> One way to think about a UID is that it names a set of capabilities.
> This is the total set of (object, permission) pairs that a given user
> account is permitted to manipulate. Such a large set of capabilities is
> intrinsically dangerous, simply because it is a lot of authority
> gathered in one place. Still, there must exist *some* places where
> exactly this authority is gathered. When I log in, I must have access to
> my resources. For practical purposes this is the set of capabilities
> named by my UID.

Right, so the shell has the UID capability.  Any server which wishes to work
with UIDs (filesystems will need to, I'm not sure if there are any others)
will accept that _in addition to_ a more specific capability.  So programs
which use UIDs will work, but programs which don't get them (which is most of
them) will work as well.

> This is probably the area in EROS/Coyotos that is most important, and
> where we have not yet been able to give adequate attention. Here is our
> current best model, but I am sure it is flawed.
> 
> 1. We assume that there is a limited number of process that serve as
> "shells". The job of a shell is to be the user's agent in the
> computational system. For practical purposes, the shell *is* the user
> within the system.

Right.  There must be a place where the user can take initiative (as opposed
to answering questions that programs ask).  We define this place to be the
shell.

> 2. There is a set of applications. With very few exceptions, we want to
> treat these applications as "presumed hostile".

I don't see any exception.  Well, except for the shell, but I think you didn't
mean it to be included. 

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

Sounds good.  Of course, specific consent doesn't need to be interactive,
users should be able to pre-answer questions with configuration files (as in:
mozilla is always allowed to use the network).

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

Is there a difference between this and 2B?

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

This does not allow for some optimisations which are very nice for the user.
For example, what if my application always wants more than one file (for
example, latex will want the .tex, .aux, .toc, .log).  It doesn't seem right
to give it access to the whole directory.  However, I don't want to be asked
multiple times if I want to open a file, and which one it should be.  Now
latex is not a graphical application, but the same can happen there of course.

Also, programs may include cleverness in predicting me which file I want to
open.

While I write this, I'm thinking of a solution: the program can tell the user
agent about the predictor, and the user agent will call it with read-only
access to the entire filesystem, but confined so it cannot speak to anyone
except the user agent.  When the user agent gets its prediction, it destroys
it again and uses it as the default.

> In the end, I'm really proposing a social attack on virus authors:
> viruses that don't spread just aren't very much fun.

And they don't make money.  That seems to be the new motive for them.

> By the way, notice that the protection provided by the open/save-as
> agent is *only* possible because the parent process does *NOT* have
> access to the internal state of its children!

I don't see this.  But I'm not sure who you're calling whose child here.  In
my terminology, the constructor is the parent, and the constructed process is
the child.  If I understand you correctly, processes cannot create children
themselves (unless they are constructors).  This sounds to me like unneccesary
simplification.  It can cost flexibility, but it doesn't seem to if you have a
publicly accessable meta-constructor.

So let's see how I would imagine the relationships between the processes (in
the hurd, assuming no set-capabilities, so no constructors):
login
 \- shell
     \- user agent
     \- program

The shell and the user agent have mutual trust.  Every program trusts its
parent (this is invariably true, if it doesn't it mustn't run).  The shell
does not trust the program.  It hands it a capability for some actions in the
user agent.  Only if the user agent says it's ok, the shell will give extra
capabilities.

Now as far as I see this works perfectly well when parents can access every
detail about their children.  They usually will not want to use that power,
but it doesn't break anything.

The only problem it does give is trusted information from other sources, in
particular passwords.  It means that in order to safely type in a password,
you must trust the whole chain of ancestors of a process.  In practise I do
not think this will be a problem, but it is a limitation.

One last note: In my constructor server proposal, no guarantee can be made
about confinement of constructed processes.  After all, the constructor is
just another process.

As far as I now see it, this is not a problem.  If we want confinement, we
shouldn't be running constructed processes.  After all, the reason they are
constructed is that they get external capabilities.  So effectively, asking
"can I confine this" is the same as "does this need to be constructed".

I haven't thought deeply about it though, so I may very well have missed
something.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature