Re: setuid vs. EROS constructor

[Bas Wijnen]

On Mon, Oct 24, 2005 at 04:00:05PM -0400, Jonathan S. Shapiro wrote:
> On Mon, 2005-10-24 at 12:15 +0200, Bas Wijnen wrote:
> > > This specific solution does not work, but there are variations of this
> > > solution that could be made to work. The requirement is that the predictor
> > > needs to be a filter that can be proven to terminate.
> > 
> > That makes sense.  Or does it?  A program and a predictor are a pair, they
> > trust each other (although they don't actually interact at all).  So what
> > happens if the predictor fails to terminate?  It would only hang the
> > execution of the program (which is probably blocking for the agent to
> > provide a capability).
> 
> The problem is that the predictor filter code is running in the context
> of a trusted program. You may be right that non-termination is not a
> concern, but the open/save-as box definitely cannot run unsafe code
> supplied by the application. If it did, this code could invoke any
> capability held by the open/save-as agent, and the whole point of this
> exercise was that we did not trust the application to use these
> capabilities properly!

No, of course it should not run with access to those capabilities.  The idea
was to do it in a separate process, which is confined.

> > That makes sense.  So it should start the predictor from a separate
> > process or so, which has much less authority.  Still, allowing predictors
> > seems like a good idea to me.
> 
> The predictor needs access to the file system to make its prediction,
> and this is *precisely* the access that we must not give it! Even
> disclosing the *names* of my files to the hostile code must not occur.

This is where confinement comes in.  Since constructors can guarantee this, we
can know that the predictor cannot communicate with anyone, in particular with
the program it predicts for.  We give it read only access to the whole file
system, and simply ignore everything it does except the prediction.

> For now, I would say that the predictor function should simply be a list of
> regexps.

That is of course the simplest version, and that may be added to the agent for
optimization.  However, generic predictors would occasionally be useful, and I
see no reason why they cannot work safely.

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