Re: setuid vs. EROS constructor

[Jonathan S. Shapiro]

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.

>   If we don't want to give this capability
> to the user, xmms will be "setcapabilities" to achieve this, which will make
> the check fail.

Yes, although we can use the extended "authorized holes" check to let
this pass.

> 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. What
the EROS constructor implements in this regard is simply "spawn". The
*ability* to run the confinement check is not an obligation to do so.

> Well, if you start your own child and don't give it any capabilities except
> ones pointing to yourself, you can also guarantee confinement of course.  I
> would think that this should be possible in the majority of cases.

If you are doing this in POSIX, the answer is: no, you cannot. Every
POSIX process has access to a file system and the socket subsystem, both
of which allow it to extend its capabilities without any authorization
from the parent process.

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

> > 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.
> 
> This is just an optimisation, I suppose?  This can be tested without any
> problem.

Yes. It is an optimization both in time and in mental concept space. It
allows the developer to say to themselves "okay, here is a pile of
known-safe reusable components".

> > 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.
> 
> That would be /bin with all setuid files removed :-)

Nah. We didn't support setuid anyway. As long as the bit doesn't *mean*
anything we might as well keep it for sentimental reasons. :-)

shap