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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
.\"
.\" $FreeBSD$
.\"
.NH
Implementation jail in the FreeBSD kernel.
.NH 2
The jail(2) system call, allocation, refcounting and deallocation of
\fCstruct prison\fP.
.PP
The jail(2) system call is implemented as a non-optional system call
in FreeBSD. Other system calls are controlled by compile time options
in the kernel configuration file, but due to the minute footprint of
the jail implementation, it was decided to make it a standard
facility in FreeBSD.
.PP
The implementation of the system call is straightforward: a data structure
is allocated and populated with the arguments provided. The data structure
is attached to the current process' \fCstruct proc\fP, its reference count
set to one and a call to the
chroot(2) syscall implementation completes the task.
.PP
Hooks in the code implementing process creation and destruction maintains
the reference count on the data structure and free it when the last reference
is lost.
Any new process created by a process in a jail will inherit a reference
to the jail, which effectively puts the new process in the same jail.
.PP
There is no way to modify the contents of the data structure describing
the jail after its creation, and no way to attach a process to an existing
jail if it was not created from the inside that jail.
.NH 2
Fortification of the chroot(2) facility for filesystem name scoping.
.PP
A number of ways to escape the confines of a chroot(2)-created subscope
of the filesystem view have been identified over the years.
chroot(2) was never intended to be security mechanism as such, but even
then the ftp daemon largely depended on the security provided by
chroot(2) to provide the ``anonymous ftp'' access method.
.PP
Three classes of escape routes existed: recursive chroot(2) escapes,
``..'' based escapes and fchdir(2) based escapes.
All of these exploited the fact that chroot(2) didn't try sufficiently
hard to enforce the new root directory.
.PP
New code were added to detect and thwart these escapes, amongst
other things by tracking the directory of the first level of chroot(2)
experienced by a process and refusing backwards traversal across
this directory, as well as additional code to refuse chroot(2) if
file-descriptors were open referencing directories.
.NH 2
Restriction of process visibility and interaction.
.PP
A macro was already in available in the kernel to determine if one process
could affect another process. This macro did the rather complex checking
of uid and gid values. It was felt that the complexity of the macro were
approaching the lower edge of IOCCC entrance criteria, and it was therefore
converted to a proper function named \fCp_trespass(p1, p2)\fP which does
all the previous checks and additionally checks the jail aspect of the access.
The check is implemented such that access fails if the origin process is jailed
but the target process is not in the same jail.
.PP
Process visibility is provided through two mechanisms in FreeBSD,
the \fCprocfs\fP file system and a sub-tree of the \fCsysctl\fP tree.
Both of these were modified to report only the processes in the same
jail to a jailed process.
.NH 2
Restriction to one IP number.
.PP
Restricting TCP and UDP access to just one IP number was done almost
entirely in the code which manages ``protocol control blocks''.
When a jailed process binds to a socket, the IP number provided by
the process will not be used, instead the pre-configured IP number of
the jail is used.
.PP
BSD based TCP/IP network stacks sport a special interface, the loop-back
interface, which has the ``magic'' IP number 127.0.0.1.
This is often used by processes to contact servers on the local machine,
and consequently special handling for jails were needed.
To handle this case it was necessary to also intercept and modify the
behaviour of connection establishment, and when the 127.0.0.1 address
were seen from a jailed process, substitute the jails configured IP number.
.PP
Finally the APIs through which the network configuration and connection
state may be queried were modified to report only information relevant
to the configured IP number of a jailed process.
.NH 2
Adding jail awareness to selected device drivers.
.PP
A couple of device drivers needed to be taught about jails, the ``pty''
driver is one of them. The pty driver provides ``virtual terminals'' to
services like telnet, ssh, rlogin and X11 terminal window programs.
Therefore jails need access to the pty driver, and code had to be added
to enforce that a particular virtual terminal were not accessed from more
than one jail at the same time.
.NH 2
General restriction of super-users powers for jailed super-users.
.PP
This item proved to be the simplest but most tedious to implement.
Tedious because a manual review of all places where the kernel allowed
the super user special powers were called for,
simple because very few places were required to let a jailed root through.
Of the approximately 260 checks in the FreeBSD 4.0 kernel, only
about 35 will let a jailed root through.
.PP
Since the default is for jailed roots to not receive privilege, new
code or drivers in the FreeBSD kernel are automatically jail-aware: they
will refuse jailed roots privilege.
The other part of this protection comes from the fact that a jailed
root cannot create new device nodes with the mknod(2) systemcall, so
unless the machine administrator creates device nodes for a particular
device inside the jails filesystem tree, the driver in effect does
not exist in the jail.
.PP
As a side-effect of this work the suser(9) API were cleaned up and
extended to cater for not only the jail facility, but also to make room
for future partitioning facilities.
.NH 2
Implementation statistics
.PP
The change of the suser(9) API modified approx 350 source lines
distributed over approx. 100 source files. The vast majority of
these changes were generated automatically with a script.
.PP
The implementation of the jail facility added approx 200 lines of
code in total, distributed over approx. 50 files. and about 200 lines
in two new kernel files.
|
