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.
One of the tools which can be used to enhance the security of a FreeBSD system are
jails. Jails were introduced in
FreeBSD 4.X by Poul-Henning Kamp <[email protected]>
, but were greatly improved
in FreeBSD 5.X to make them a powerful and flexible subsystem. Their development
still goes on, enhancing their usefulness, performance, reliability, and security.
BSD-like operating systems have had chroot(2) since the
time of 4.2BSD. The chroot(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 FreeBSD kernel, it was clear that chroot(2) was not the
ideal solution for securing services. A new subsystem had to be implemented.
This is one of the main reasons why jails were developed.
Jails improve on the concept of the traditional chroot(2) environment,
in several ways. In a traditional chroot(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 FreeBSD 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 15.5.
A jail is characterized by four elements:
-
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 FreeBSD jails.
-
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.
-
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.
-
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.
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
15.5 below.