Re: setuid vs. EROS constructor

[Bas Wijnen]

On Thu, Oct 13, 2005 at 12:31:45PM -0400, Jonathan S. Shapiro wrote:
> On Thu, 2005-10-13 at 14:42 +0200, Bas Wijnen wrote:
> > 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.
> 
> Yes. There do exist programs in the world that are badly designed. The
> correct design for latex was to use a directory for these files.
> 
> In practice, the majority of these cases concern temporary files. There is
> no reason why a running application cannot create an entirely private file
> system for its own use.

That makes sense.

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

> > 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.
> 
> 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 agent will at least not answer any more requests from that
program until the predictor terminates.  This doesn't harm anyone else, so I
don't think it is a problem.  Unless you would call "not terminating" a covert
channel, but it isn't, since the application cannot distinguish between taking
a long time to find the file (for the user, who ignored the predictor result)
and killing the predictor and choosing a file.

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

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