1 files changed, 48 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
new file mode 100644
index 00000000..57739861
--- /dev/null
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -0,0 +1,48 @@
+[[!meta copyright="Copyright © 2008, 2009, 2010 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 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: Carl Fredrik Hammar (cfhammar)
+
+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.