[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled
[[GNU Free Documentation License|/fdl]]."]]"""]]

[[!meta title="Secure chroot Implementation"]]

As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a
`chroot()` system call.  However, the current implementation is not really
good, as it allows easily escaping the `chroot`, for example by use of
[[passive_translators|hurd/translator]].

Many solutions have been suggested for this problem -- ranging from simple
workaround changing the behaviour of passive translators in a `chroot`;
changing the context in which passive translators are exectuted; changing the
interpretation of filenames in a chroot; to reworking the whole passive
translator mechanism.  Some involving a completely different approch to
`chroot` implementation, using a proxy instead of a special system call in the
filesystem servers.

See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html>
for some suggestions, as well as the followup discussions on
<http://lists.gnu.org/archive/html/gnu-system-discuss/2007-09/msg00118.html>
and <http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00089.html>.

The task is to pick and implement one approach for fixing chroot.

This task is pretty heavy: it requires a very good understanding of file name
lookup and the translator mechanism, as well as of security concerns in general
-- the student must prove that he really understands security implications of
the UNIX namespace approach, and how they are affected by the introduction of
new mechanisms.  (Translators.)  More important than the actual code is the
documentation of what he did: he must be able to defend why he chose a certain
approach, and explain why he believes this approach really secure.

Possible mentors: ?

Exercise: It's hard to come up with a relevant exercise, as there are so many
possible solutions... Probably best to make an improvement to one of the
existing translators -- if possible, something touching name resolution or and
such, e.g. implementing file_reparent() in a translator that doesn't support it
yet.