Re: setuid vs. EROS constructor

[Jun Inoue]

On Sat, 15 Oct 2005 15:50:17 -0400
"Jonathan S. Shapiro" <address@hidden> wrote:

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

You're right.  Confinement must be the default.  I thought I'd put the
secure-system-design shoes on, but their laces were untied...


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

It shouldn't be different.  My intention here is not to claim a
pitfall in the approach, much less to suggest a solution.  It's to
learn your take on scripting, which doesn't seem to fit well into the
picture.  I thought you might either a) have a clever solution to make
it fit, b) declare it a bad idea altogether and advise to set up a
specialized sandbox when a task can't be accomplished otherwise, or c)
have a framework in mind that would obsolete scripting (in its current
form).

I suppose your position is some mixture between b) and c).


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

I'm afraid I do have the relationship confused.  Isn't the mediator's
job to provide a mechanism for user intervention?

When I want to open a file with emacs (do you desire something else
for a change? :p), for example, I can't just tell emacs which file I
want.  A trusted component must deliver the right capability to emacs.
As I understood it, this trusted component is the mediator, M.

Here, emacs (which would be A) is the one willing to use the
capability and also the one presumed hostile.  A cracked version of
emacs may well tell the mediator that I'm asking for foo when I'm
actually asking for bar.  The only way for the mediator to be sure
that no such tampering has occured is to do the interaction itself.

But maybe you're looking way ahead:

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

This exactly addresses a concern I've had for some time now.
Applications should not interact with the user unless absolutely
necessary (contrary to what current GUI apps tend to do), and really
focus on manipulating and presenting data.  They should be plugged
into a generic framework which does all interactions not directly
pertaining to data manipulation.  I came to that conclusion through a
very different path, but it looks like it'll work very well for
security, too.

Were your notes on mediator assuming the use of such a framework?  If
so, then a lot of things make sense (I still don't get why M would be
*using* the additional capability, though).  All application processes
will become server instances.  They'll serve the shell's request,
presenting text/picture/whatever, and every sensitive operation will
be triggered and handled by the shell itself, such as open, save,
connect to network, etc.  Some such operations may consult the
application for hints like what to put up on the clipboard.

That makes me curious: is that why the EROS servers are predominantly
single client[0]?  Because a lot of them are confined plugins serving
a particular shell?  (Perhaps I should go dig into the actual EROS
code...)


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

None.  I guess the GIMP wasn't a good example.  I meant to illustrate
a program that provides shell-like functionalities for batchwork, in
addition to its interactive functions.  But one of your assumptions, I
presume, was that such an incomplete separation is the root of evil.
I agree with that.


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

That answers my question about your take on scripting.


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

I will.


[0] http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00123.html


-- 
Jun Inoue
address@hidden