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.

Many solutions have been suggested for this problem -- ranging from simple workaround changing the behavior of passive translators in a chroot; changing the context in which passive translators are executed; changing the interpretation of filenames in a chroot; to reworking the whole passive translator mechanism. Some involving a completely different approach 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: Justus Winter (teythoon)

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.

---

2016-02-14, Justus Winter

I have factored out the proxying-bits from fakeroot so that it can be shared. The most simple chrooting translator is the identity translator, which proxies RPCs without really modifying them. Combining the identity translator with settrans --chroot gives us chroot(8). With a little more work, I believe that can be used to implement chroot(2). Whether or not that is secure remains to be seen, maybe that is even an ill-conceived goal.