1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
[[!meta copyright="Copyright © 2008, 2009, 2010, 2016 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: 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.
|
