Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Thu, 2005-10-13 at 14:42 +0200, Bas Wijnen wrote:
> One last note: In my constructor server proposal, no guarantee can be made
> about confinement of constructed processes.  After all, the constructor is
> just another process.

I think that you wrote this before I described the constructor chain of
trust in EROS. Now that you have seen this chain of trust, do you
understand why in EROS the constructor is not just another process? It
depends critically on the identify operation.

> As far as I now see it, this is not a problem.  If we want confinement, we
> shouldn't be running constructed processes.  After all, the reason they are
> constructed is that they get external capabilities.  So effectively, asking
> "can I confine this" is the same as "does this need to be constructed".
> 
> I haven't thought deeply about it though, so I may very well have missed
> something.

I am afraid that you did. In EROS, *all* processes are constructed
processes. It is the constructor that certifies the confinement
guarantee. The vast majority of the time, this is the entire reason for
using a constructor (well, that plus it's really convenient).

Yes, the constructor has the ability to provide external capabilities.
In fact, it *has* to, because the initial address space capability for
the yield is an external capability. This is why you have to *ask* a
constructor whether its yield will be confined. But the constructor is
trusted code, so you can trust its response.

In practice, I think that in a real operating environment we would have
certain system directories where we would enforce some guarantees:

  1. All items bound in these directories are constructors.
  2. All of these constructors certify that their yield is confined.

A good example of where this is appropriate would be the equivalent
of /bin. The main reason to do it is that this entire directory can now
be handed to a hostile program (the directory must be read-only, of
course). The hostile sub-program can happily run any of these programs
that it chooses to run, because none of them extend the authority of the
sub-program in any way.

shap