Re: The Hurd: what is it?

[Thomas Bushnell BSG]

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

> 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 should say that I do not object at all with the goal of using
object permanence as a strategy.  Indeed, passive translators are
clearly just a poor-man's version of good persistent active
translators.) 

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

I believe the current directory of the newly started translator is
just root.  (Or perhaps it's the directory the translator was found
in?)  Still, you can only set a translator in the directory if you
already have a port to it.  

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

I agree.  This is certainly a difficulty.

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

Quite right; clearly the resource accountability would come from the
owner of the passively translated node, just as its authentication all
does. 

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

Totally agreed.

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

Agreed.

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

chroot is hard, and used only by particular specialized cases.  So
rather than bend the whole system to make chroot easy, it's a better
design decision to redo those particular specialized cases.  

Thomas