Re: setuid vs. EROS constructor

[Bas Wijnen]

On Thu, Oct 13, 2005 at 02:11:33PM -0400, Jonathan S. Shapiro wrote:
> 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.

Yes, I understand this, but I was talking about the (currently nonexisting)
constructor on the Hurd system.  Sorry for confusing the terms all the time.

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

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.  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.  (Actually, in our current design this would in fact be an
endpoint capability to the scheduling server, I suppose, so that would need to
be changed as well.)

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

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.

> 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,
which will do the address space creation for you (via the root server).
Revoking this capability (or not passing it) means the process cannot start
new processes.  However, if it has a capability to a "setcapabilities"
constructor (or can get it via a capability to some part of the filesystem),
it can still use that to start one (but only a specific one, of course).

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

> 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 :-)

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