Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Thu, 2005-10-13 at 14:42 +0200, Bas Wijnen wrote:
> > 2. There is a set of applications. With very few exceptions, we want to
> > treat these applications as "presumed hostile".
> 
> I don't see any exception.  Well, except for the shell, but I think you didn't
> mean it to be included. 

There are two classes of exceptions:

  1. Applications that sit on your trusted path, for example the line
     discipline module. These are in a position to alter your input
     or your output, and must be trusted.

  2. Applications that encapsulate privileged system function. These
     hold capabilities that you do not, usually to shared system 
     databases (and for this reason, their constructor does not
     consider them confined).

> Sounds good.  Of course, specific consent doesn't need to be interactive,
> users should be able to pre-answer questions with configuration files (as in:
> mozilla is always allowed to use the network).

Mozilla is the last program in the world that should be given
unrestricted access to the network. But yes, I think that you are
entitled to shove a white hot poker into your eye.

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

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

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

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.


Response to the rest of your note later.


shap