Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Mon, 2005-10-24 at 12:15 +0200, Bas Wijnen wrote:
> > > Also, programs may include cleverness in predicting me which file I want
> > > to open.
> > 
> > This is not cleverness. It is betrayal. Who do you want to be in charge, you
> > or the application?
> 
> I wasn't saying it should just be allowed to open it, but I do want it to make
> the suggestion.  Being in charge doesn't mean I want to fire all my advisors,
> even if I don't trust them.  They're only advisors after all, so I can just
> ignore their advice.  But I do want to hear it.

I understand what you are saying. The problem here is that you have a
trusted agent (the open/save-as subsystem) running untrusted code (the
recommended filter function). It can be done, but it requires care.

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

So: this is a case where a very simple filter specification mechanism
could easily handle 98% of real uses, and the right thing to do is to
give up the last 2% to preserve security. You will notice, I will
notice. The majority of users will never notice.

> > The security problem here is that we desperately need the open/save-as agent
> > to be simple. It is a program that manages an authority boundary, and these
> > programs need to be programmed with the same kind of care that we have
> > learned to give to setuid programs. More, actually, since we don't give
> > enough care to setuid programs.
> 
> 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.

We need to think about this more -- there may be a reasonable compromise
that is made possible with clever use of confinement (as there was for
secure cut&paste). For now, I would say that the predictor function
should simply be a list of regexps.


shap