Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

On Mon, 2005-10-24 at 11:41 +0200, Bas Wijnen wrote:
> On Mon, Oct 17, 2005 at 08:53:19AM -0400, Jonathan S. Shapiro wrote:
> > On Mon, 2005-10-17 at 11:17 +0200, Bas Wijnen wrote:
> > > This doesn't seem to be true.  I thought all capabilities would be 
> > > enpoints,
> > > but (at least in EROS) they aren't.  With the scheme I described here, it
> > > would not be possible to guarantee confinement of xmms, because it needs a
> > > high priority scheduling capability.
> > 
> > As long as this scheduling capability is authorized, it does not violate
> > confinement.
> 
> The scheme I described didn't support authorization, it either gets external
> capabilities, or it doesn't.  The confinement check you described (which is
> used in EROS) is much more flexible than that, and that seems very useful.

We are speaking past each other.

When A gives a capability to B, A authorizes B to use that capability.
This is what is meant by "authorized".

> That would still need a trusted constructor, which is not something I planned.
> I was just claiming that the scheme I described sucks, and you seem to respond
> that all those problems don't occur with EROS constructors.  I already knew
> that. ;-)

Umm, I would not say "sucks" at all. I would say that wrestling with
capabilities takes some getting used to. Given where you are starting
from, the design wasn't bad. It's just that I have the benefit of 15
years thinking about this myself and a lot of mentoring from people who
*really* know how it works. :-)

> > > For some reason I don't like the constructor approach though.  I would
> > > prefer it if the default way of starting a new process would be to just do
> > > it directly.  I don't really know why I prefer that, and it seems to
> > > prevent good things to happen.  So it may not be a good idea.
> > 
> > I don't know how, in principle, to start a process more directly.
> 
> - Allocate some pages.
> - Fill them with code.
> - Ask the task server to make it a new process.

Why do you need a task server? The steps you describe are essentially
the steps that the constructor performs.

The problem with your approach is that you lose the ability to determine
confinement.

> > > > 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.
> > > 
> > > I think in the Hurd we would do this via a capability to the task server..
> > 
> > This would work functionally, but it would have a cost: you would no
> > longer be able to test confinement.
> 
> You would, since the task server is a trusted server, and the address spaces
> it gives out are guaranteed not to leak.

It cannot make this guarantee without doing all of what the constructor
does.

shap