Re: The Hurd: what is it?

[Marcus Brinkmann]

At Wed, 09 Nov 2005 09:44:18 -0800,
Thomas Bushnell BSG wrote:
> 
> Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:
> 
> > For problems with the Hurd passive translator design:
> >
> > http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00081.html
> 
> I would say in response to this that the only problem Marcus really
> identifies here is that you can escape chroot jails with passive
> translators, which is true, but also a part of the Hurd.  The Hurd
> does not support chroot jails of the Linuxy/BSD sort.

Well, I think it is a bit more severe than just that.  Let me try to
reframe it in a bigger picture:

I am not sure that the only current problem is the root directory
port.  You might want to throw in the current directory port as well.
The other initial ports may be safe: The auth port is given based on
the "file owner" privilege.  The proc server is a system-wide
property.  I don't know if there even is a controlling terminal ID
port given.  I don't think stdin/stdout/stderr are initialized.  And
the bootstrap port is of course part of the startup protocol.

However, there are several problems I have with this picture: There is
a usability issue, because the active translator and passive
translator do get different execution environments.  For example, you
only see error messages if you start the active translator directly.

There is the "who paus the bill" issue: Who _pays_ for starting the
translator?  Who pays for the resources, the kernel threads and the
memory?  Currently, there is simply no resource accountability.  Mach
gives you the illusion of infinite resources.  This is wrong even if
you do not care about security issues at all: It makes resource
scheduling very hard, and thus makes it hard to provide better quality
of service.  Getting this right however is imperative if you even only
want to come close to the performance of traditional systems like
GNU/Linux.  Once you want to fix this by introducing resource
accountability (as a first step), it becomes immediately obvious that
the filesystem can not start the translator.  Neither can the task
accessing it (and causing the startup).  The right task to pay is the
task installing the translator (or another task on that task's behalf).

There is also a flexibility issue: What if you add more initial
capabilities?  For active translators, this is simple: You just pass
them at exec.  For passive translators, it turns out to be quite
difficult: The only options I see is extending the filesystem startup
protocol, facing the same usability and potential security issues, or
let the translator look up its additional ports in the filesystem
somewhere.

Then there is a principle issue: The execution environment comes from
the wrong source.  Yes, it happens to be a correct, "safe" execution
environment---except for the root directory---but this seems to be
merely by chance.  What is the underlying design principle to which I
can track this specific implementation choice?  Why are passive
translators implemented differently than active translators?  What
justifies the difference?

And finally, there is the security issue.  It may not be your (or
mine) concern, but it sticks out nevertheless.  It is much harder to
argue convincingly that in this design the passive translator will not
get too much authority (ie, that no authority leaks from the parent
filesystem), then in a system where the parent filesystem is simply
not involved in the first place.

Another issue in response to your statement:

> That's ok, because we can make a jail a different way: by blocking the
> servers you have access to.

Ok, now I have two choices: I can give you full access to the system,
or none.  In each and every case I have to make a decision which one
it is, all or nothing.  In each and every case, if in doubt, I have to
fall back to the only secure option: I don't give you any access.

What this means is that nobody should hope that you can ever
successfully secure a "sub-Hurd" without denying it all direct access
to the other Hurd system.  But what you actually _want_ is to share a
bit, like, for example, a directory.  Total confidence (the "all"
approach) and total distrust (the "nothing" approach) are useful cases
to support.  They are the simple cases.  Unfortunately, they are not
the only useful cases in a world where users run untrusted, buggy, or
even malicious code all the time (think spyware, etc).

In other words: From a security point of view, this is the most
inflexible system design you can imagine.  It seems to contradict the
goal of user flexibility.

> But if you have access to the core servers, you have access to the
> real system root, in many many ways.  This was a conscious design
> choice, and I don't think it's problematic.

It may be the case that this is true.  However, I have not heard a
convincing reason why this _should_ be the case, and what the
rationale for this conscious design choice is.  Maybe you can explain
the rationale?  If the purpose was to write a deliberately insecure
system, there would have been easier ways to accomplish that :) In
particular, I would not look at capability systems in the first place.

At the very least, I hope it is clear that this is not about chroot.
It is about design principles (the implementation should be motivated
by design principles), and about design goals like proper resource
scheduling and security guarantees.

Thanks,
Marcus