removed
[ikiwiki.git] / docs / handbook / handbook-jails-intro.mdwn
CommitLineData
77932a88 1# 12.3 Introduction
2
3 Since system administration is a difficult and perplexing task, many powerful tools were developed to make life easier for the administrator. These tools mostly provide enhancements of some sort to the way systems are installed, configured and maintained. Part of the tasks which an administrator is expected to do is to properly configure the security of a system, so that it can continue serving its real purpose, without allowing security violations.
4
5***
6
5720368d 7 One of the tools which can be used to enhance the security of a DragonFly system are jails. The jail feature was written by Poul-Henning Kamp <phk@freebsd.org> for R&D Associates. [[http://www.rndassociates.com/]] who contributed it to FreeBSD 4.X. Support for multiple IPs and IPv6 were introduced in DragonFly 1.7. Their development still goes on, enhancing their usefulness, performance, reliability, and security.
77932a88 8
9
10
753308b7 11# 12.3.1 What is a Jail
77932a88 12
13 BSD-like operating systems have had [chroot(2)](http://leaf.dragonflybsd.org/cgi/web-man?command#chroot&section2) since the time of 4.2BSD. The [chroot(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=chroot&section=8) utility can be used to change the root directory of a set of processes, creating a safe environment, separate from the rest of the system. Processes created in the chrooted environment can not access files or resources outside of it. For that reason, compromising a service running in a chrooted environment should not allow the attacker to compromise the entire system. The chroot(8) utility is good for easy tasks, which do not require a lot of flexibility or complex and advanced features. Since the inception of the chroot concept, however, many ways have been found to escape from a chrooted environment and, although they have been fixed in modern versions of the DragonFly kernel, it was clear that chroot(2) was not the ideal solution for securing services. A new subsystem had to be implemented.
14
77932a88 15
16 This is one of the main reasons why ***jails*** were developed.
17
5720368d 18
77932a88 19
20 Jails improve on the concept of the traditional [chroot(2)](http://leaf.dragonflybsd.org/cgi/web-man?command#chroot&section2) environment, in several ways. In a traditional [chroot(2)](http://leaf.dragonflybsd.org/cgi/web-man?command=chroot&section=2) environment, processes are only limited in the part of the file system they can access. The rest of the system resources (like the set of system users, the running processes, or the networking subsystem) are shared by the chrooted processes and the processes of the host system. Jails expand this model by virtualizing not only access to the file system, but also the set of users, the networking subsystem of the DragonFly kernel and a few other things. A more complete set of fine-grained controls available for tuning the access of a jailed environment is described in Section 12.5.
21
22***
23
24 A jail is characterized by four elements:
25
77932a88 26
77932a88 27
28
29* A directory subtree -- the starting point from which a jail is entered. Once inside the jail, a process is not permitted to escape outside of this subtree. Traditional security issues which plagued the original chroot(2) design will not affect DragonFly jails.
30
77932a88 31
5720368d 32
33
77932a88 34
35
36* A hostname -- the hostname which will be used within the jail. Jails are mainly used for hosting network services, therefore having a descriptive hostname for each jail can really help the system administrator.
37
77932a88 38
5720368d 39
40
77932a88 41
42
43* An IP address -- this will be assigned to the jail and cannot be changed in any way during the jail's life span. The IP address of a jail is usually an alias address for an existing network interface, but this is not strictly necessary.
44
77932a88 45
5720368d 46
47
77932a88 48
49
50* A command -- the path name of an executable to run inside the jail. This is relative to the root directory of the jail environment, and may vary a lot, depending on the type of the specific jail environment.
51
52***
53
54 Apart from these, jails can have their own set of users and their own root user. Naturally, the powers of the root user are limited within the jail environment and, from the point of view of the host system, the jail root user is not an omnipotent user. In addition, the root user of a jail is not allowed to perform critical operations to the system outside of the associated jail(8) environment. More information about capabilities and restrictions of the root user will be discussed in Section 12.5 below.
55
56
57
58----
59
60
61