Re: Hurdish applications for persistence

[Marcus Brinkmann]

At Tue, 11 Oct 2005 21:10:58 +0200,
Alfred M Szmidt wrote:
> 
>    Also, if you think it is just an exploit in the implementation, and
>    not a design flaw, you will surely have a way in mind to fix the
>    implementation.  Please share that with us.  I am very interested to
>    hear about it.
> 
> Well, since chroot is inherently unsecure on all platforms (chroot was
> never designed to be secure!), it would be simpler to deprecte it and
> come up with another scheme.  What the exact scheme is, I do not know
> yet, but something like sub-hurds.

It is not true that "chroot is insecure on all platforms".  This is
simply a false statement: chroot is "secure" on many platforms today,
and this does not only include specifically hardened platforms.  By
secure I mean that it effectively restricts filesystem access.

If you are looking for an alternative, one that works and is actually
used around the world, have a look at BSD jails.  They provide a more
thorough encapsulation than chroot.

>    Then you have reintroduced the single global namespace that Unix
>    has, and you have just removed security, and not added to it: All
>    files are accessible to all programs.
> 
> I fail to see how this has been reintroducded, sub-hurds don't have
> the same global namespace.

You keep beating on subhurds, but you fail to show how they are
relevant in this discussion at all.  A subhurd is as relevant here as
a second machine, with its own copy of the operating system.  Right, a
second machine is encapsulated, it can not access the files on the
first machine.  What's your point?

Let me take your argument to the extreme.  The extreme would be: "Ok,
the Hurd is insecure, but it wasn't meant to be secure.  So, just run
the program on a different Hurd system."

There are two flaws in this line of thinking: First, the second Hurd
system is not going to be any more secure than the first one.  That
can be acceptable, because its insecurities are contained.  More
seriously, there is no way of sharing anything between the two
separate Hurd systems.  This achieves your goal of separation, but it
over-reaches it at the same time.  The whole purpose of having this
discussion is to find out how to enable selective, narrow sharing.  In
your system so far, I have the choice to share everything, or to not
share at all.  This is overly restrictive and does not lead to usable
systems.

>    So, getting rid of chroot is exactly the wrong way to go about it.
> 
> I disagree.
> 
>    There is no reasonable way to share resources between the Hurd and
>    a subhurd (actually, there is a way:
> 
> Then such a means should be implemented, some kind of a proxy
> translator where you specify what resources you can use from within
> the sub-hurd (think firewall).

Right.  This is exactly the problem I was talking about in my original
mail.  How can you specify what resources a certain confined task is
allowed to use, and how do you enforce such restrictions?

You have now arrived at a point where you have to face the original
questions I was implicitely asking.  It doesn't really matter if you
put them into the context of passive translators, user IDs, or
subhurds.  It's always the same game.

Thanks,
Marcus