bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Server overriding; chroot (was: Google Summer of Code participation)


From: olafBuddenhagen
Subject: Server overriding; chroot (was: Google Summer of Code participation)
Date: Tue, 18 Mar 2008 16:38:55 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Hi,

On Sun, Mar 16, 2008 at 12:47:23AM +0800, Wei Shen wrote:

> I read the project ideas list, and found "server overriding mechanism"
> is there. I have once tried investigating this issue, but failed to
> continue at last. Still, I wonder whether I should submit my
> modification to Glibc for an simple implementation of socket server
> overriding, though the work is rather minor (see attachment).

Well, it can certainly serve as a starting point :-)

> I also find "secure chroot implementation" in the list. IMHO, the
> unsafty of chroot is not caused by passive translator. In fact,
> currently chroot is implemented totally at client side by changing the
> INIT_PORT_CRDIR port matained by in Glibc. So, it is easy to escape
> from chroot by bypassing the file port resolving routine of Glibc, or
> just by modifying the CRDIR port. No need to exploit passive
> translators at all. We should first let the file server know and
> control chroot before making translators aware of it.

That's not true as far as I know. Of course, the process can easily
change it's own idea of what the root directory is. But that doesn't
help escaping the chroot. To access anything outside the chroot, the
process needs a port to the outside filesystem...

When creating a chroot, the port to the desired virtual root directory
is obtained, and the filesystem server responsible for that directory is
told -- by means of the file_reparent() RPC -- to treat it as if it was
indeed a root directory; i.e. instead of following lookups for "..",
just return the same directory. This way, in theory the chrooted process
should never be able to access anything above it's virtual root.

Now the problem is that a chrooted process can create a passive
translator. When this translated node is accessed, the translator
process currently won't be started in the context of the chrooted
process, but in that of the normal global filesystem -- it has access to
everything, and can pass it on to the chrooted process.

There have been discussions about that in the past (unfortunately not
linked from the task description, though I hope that can be fixed
still...), and many possible solutions have been proposed. The hard part
is deciding on the best solution, and demonstrating in a convincing
fashion, that it indeed solves the problem. (Many of my suggested
solutions have been refused in the past, though only based on
misunderstanding I believe...)

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]