Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Fri, 2005-10-14 at 23:23 -0700, Jun Inoue wrote:

> If the node (or its creator) can't be trusted, the user should
> sanbox it (which the shell might do by default to every executable not
> on the standard path).

Why on earth should binaries on the standard path be an exception? We
know perfectly well that those get tampered with too.

Sandboxing should be the universal default, violated only in extremely
exceptional situations and then with a great deal of fear, trembling,
and paranoia.

> > I am not sure whether this response makes things clearer, so I would
> > like to pause to get your reaction.
> 
> I still feel I'm missing some thing(s).  This sentence seems to be the
> root of my confusion:
> 
> > > > The only thing that Bas missed is that if you have persistence
> > > > you do not need a constructor server.
> 
> What is meant by this sentence?  What is the "constructor server" in
> this context?

Well, I'm not sure, since I didn't introduce the term. Let me try to
explain as best I can, but let me do it with a separate subject line.

> Somehow I was thinking that EROS tests for confinement, but given that
> it actually tests for leaky capabilities, I could imagine a pretty
> straightforward mechanism.  ...which you went ahead and desribed in
> another thread ("Re: instance and instantiator").

Yes. Testing for confinement after the fact is not really possible --
which is why unprotected capabilities cannot be used to build
pragmatically securable designs.

> > So in practice, a mediating agent is required when an application has
> > justified need for some capability that is contained in one of these
> > aggregates. That is: mediating agents exist to guard aggregates.
>
> That intuition was pretty much what I had in mind :)
> 
> I can see it works pretty nicely in most cases, but how can this work
> with applications featuring scripting?  Maybe I've got it all wrong
> again, so here's my understanding:

Why should scripting be any different? Do you want the script opening
large numbers of files or network connections?

> We wish to hand out capabilities in a way that more accurately
> reflects the (sub)set of the user's rights being exercised by the
> program (I imagine that's what an "authority boundary" is).  In many
> programs, the capabilities required for operation can't be determined
> at program startup.  We can't just let the program grab additional
> capabilities at will, so some trusted component must intervene.
> 
> The question I want to ask, then, is: "how far should that trusted
> mediator intervene?"  Let's say I want to add some capabilities to
> application A, using mediator M.  If M doesn't directly accept input
> from the user, A can lie to M about what I ordered.  So M needs to
> inspect and interpret input on its own.

I think you have the relationships confused. Our assumption here is that
M is willing to use capabilities provided by the user (possibly with
qualifications). For purposes of analysis, A *is* the user. A can lie to
exactly the same degree that the user might lie directly. No new issue
has been introduced here.

The mediator does not get involved at all with the capabilities that the
shell wishes to provide to the application at startup. This set can be
anything that the shell, acting on behalf of the user, thinks is
appropriate. Mediators only get involved when the application later
wants to request *additional* authority. The user's intervention is then
desirable and necessary because the user is the only person who can make
decisions about how to properly protect the interests of the user.

These decisions can be recorded in advance in order to support batch
processing. The goal here is simply to ensure that the user is not cut
out of the decision loop because the application has been given
excessive authority.

> I don't think such an agent which always manifests itself can play
> well with scripting....

> How would rename(1) work?
   Rename is a shell built-in. No problem.

>   Or emacs?  GIMP?

   Emacs and gimp consist of a very small portion that may be viewed
   as an application shell, and a very large portion that actually does
   the editing. Why should Emacs have the right to open arbitrary files?

   You may find emacs a convenient shell. I think that it's *way* too
   complicated to be safely trusted that way.

   GIMP is actually a really good example, and what it really reveals
   is the need for an interactive graphical shell and a model of
   applications that are "plug ins".

> Should they ask the user if they can temporarily fork a child with a
> huge number of capabilities?

No. No new authority is created by forking a child that receives
capabilities already held by the parent.

>   How do we know what to give to that
> child?

If the answer isn't obvious, the application is fundamentally broken.
But let's look at Gimp in reality. In actual practice, the *only* new
capabilities that it *ever* asks for are exactly the ones at the
open/save-as boundary. What other capabilities do you imagine that it
might ever need?

>   Should we put the target files in a directory with some
> trusted utility? 

Yes. The utility is called the shell.

> Maybe scripting can be dismissed as fundamentally insecure, but the
> line would be hard to draw, I think.

Scripting is fundamentally dangerous. It usually involves giving a
program a whole lot of authority to go do something unsupervised. Here
is my concrete suggestion for how to manage this:

  1. Put the files you want to operate on in a directory, using
     read-only capabilities to the objects.
  2. Give the scripts read-only access to this directory.
  3. Create an empty output directory. Give the scripts write
     access to that.
  4. Run the whole thing inside a confinement boundary, where
     the input and output directories are provided as arguments
     at startup time (at the same time that you say what script
     to run).

If you want to dig in to this more seriously, you may want to look at
Marc Seaborn's work on PLASH.

shap