Re: setuid vs. EROS constructor

[Bas Wijnen]

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.

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

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

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

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

Access to a filesystem and the socket subsystem are both examples of
capabilies not pointing to yourself (or if they do and you proxy them, then
you can guarantee confinement by refusing requests on them).

I do agree that a true POSIX process cannot be confined, except by jailing it.
I don't think that that is a problem, as we should only _support_ POSIX, we
don't need to actually _use_ it.  That is, I consider it totally acceptable to
have no POSIX programs at all running on a real-world Hurd system.  Actually,
I would prefer that, since they are intrinsically insecure.  But that doesn't
mean it should refuse to run them if the user really wants it.

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

Anyway, I don't think my model is worth discussing any further, since I am
convinced that constructors are much better.

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