Re: Hurdish applications for persistence

[Marcus Brinkmann]

At Tue, 11 Oct 2005 12:29:35 +0200 (CEST),
Alfred M Szmidt wrote:
>    But let's take a closer look.  Take for example a "firmlink"
>    translator, which is a bit of a cross between a soft link and a
>    hard link.  Furthermore, consider a user running a shell in a
>    chrooted environment.  The user is malicious and wants to escape
>    the chroot.  If the user installs an active firmlink to "/"
>    somewhere in its chrooted filesystem tree, this fails: The firmlink
>    translator will see the same chrooted root directory as the user
>    themselves.  But what if the user installs a passive firmlink
>    translator and then accesses it (for example via an ls -l)?  Then
>    the filesystem will do the startup _and give the firmlink
>    translator a port to the real, unchrooted directory port_.  The
>    user can escape the chroot following the firmlink.  This is an
>    obvious security exploit.
> 
> A obvious security exploit in the chroot() implementation (or really,
> file_reparent) and not in how passive translators work.

I don't see what file_reparent has to do with it, you would have to
explain that to me.

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.

Note that it is not impossible to fix passive translators to at least
not be exploitable.  But if you ponder this problem, you will find
that this is not easy to do at all, and the result will in general not
be what you want.  Here is a hint: The translator must be started
without a root or current directory port, and the parent filesystem
will have to pass down the shadow root of the user down to the active
translator for each lookup separately.  But that is only the beginning
of the story.

There are other problems, too.  For example, the parent filesystem
uses its own root directory to lookup the passive translator
executable(!).

> If you want a secure chroot enviroment (right now atleast) then you
> should run a sub-hurd.

If you think my email was about the fact that chroot is broken on the
Hurd, you have totally missed my point.  That chroot is broken is
clear even without an elaborate discussion of passive translators.  It
suffices to point out that the proc server will happily hand out a
port to the root directory of the system.

Let's say you remove chroot from the system, and all related code.  I
suppose that's what you want to do if you think that chroot should not
be used (leaving an exploitable chroot implementation in the code is
clearly suboptimal).  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.  It's
conceptually open (filename), not dir_lookup (dir, name).  But the
lack of secure version of dir_lookup (one that can be chrooted, ie
disallows resolving "..") is one of the major security flaws in the
POSIX interface design, and one of the things that the Hurd at least
conceptually got right.  Removing chroot is a whole step backwards.

So, getting rid of chroot is exactly the wrong way to go about it.  It
takes away from the security design of the system.  Subhurds are no
answer either (see below).

But even if you do this step backwards, you are not save.  There is
still at least the problem that the parent filesystem leaks ports to
its own auth and proc server to the activated translator.

> Where this isn't possible (atleast, I have never been able to break
> out of a sub-hurd, and I have tried).  So instead of using broken
> UNIXoid ideas like chroot, it would make far more sense to implement
> a light-weight sub-hurd which can be used like chroot.

A subhurd is more or less completely isolated from the other Hurd
system, so it is, in this sense "secure".  But that means nothing in
the context of the discussion.  There is no reasonable way to share
resources between the Hurd and a subhurd (actually, there is a way: By
breaking the confinement and using firmlinks, thus introducing the
very security hole you tried to fix in the first place).

Thanks,
Marcus