- FreeBSD jail
The FreeBSD jail mechanism is an implementation of
operating system-level virtualization that allows administrators to partition aFreeBSD -basedcomputer system into several independent mini-systems called "jails".The need for the
FreeBSD jails came fromservice provider s' desire to establish a clean cut separation between their services and theircustomer s, mainly for security and ease of administration reasons. Instead of adding a new layer of fine-grained configuration options, the solution adopted was to compartmentalize the system, both itsfile s and its resources, in such a way that only the right person(s) are allowed access to the right compartment(s).Goals
FreeBSD jails mainly aim at three goals:#
Virtualization : Each jail is a virtual environment running on the host machine with its ownfile s, processes, user andsuperuser accounts. From within a jailed process, the environment is (almost) indistinguishable from a real system.
#Security : Each jail is sealed from the others thus providing an additional level ofsecurity .
# Ease ofdelegation : Thanks to the limited scope of a jail, it allows administrators to painlessly delegate several tasks which require superuser access without handing out complete control over the system.Those familiar with
Unix will recognize thechroot jail method of restricting the scope of processes. TheFreeBSD jail mechanism is more than that: each process is attached to a specific kernel structure whose purpose is to limit its interaction with processes running in other jails and restrict the things they can do (for instance a jail is bound to only oneIP address and cannot access raw, divert orrouting socket s).The jail(8) utility and jail(2)
system call first appeared in FreeBSD 4.0. New utilities (for example jls(8) to list jails) and system calls (for example jail_attach(2) to attach a new process to a jail) that render jail management much easier were added inFreeBSD 5.1.Virtualization
With jail it is possible to create various different
virtual machine s, each of them having their own set of utilities installed and their own configuration. This makes it a safe way to try outsoftware . For example it is possible to run differentversion s or try different configurations of Apache in different jails. And since the jail is limited to a narrow scope, the effects of a misconfiguration or mistake (even if done by thesuperuser ) does not jeopardize the rest of the system's integrity. There isn't even anything to do to "revert changes" since nothing has actually been modified outside of the jail (deleting the jail's directory tree is a good way to get rid of it).Virtualization is valuable to service providers wishing to offer their users the ability to have custom configurations and yet keep the overall system easy to maintain. For example two different customers could need different versions of the same software. The traditional way of configuring different software versions is to install both versions in different directories and try to make sure that they do not encroach on each other. Needless to say, this configuration isn't easy to maintain and rapidly tends to become messy, especially if the software hasn't been designed with this in mind (e.g.XFree86 is notoriously hard to move around). The approach with jails is that every piece of software feels at home because it thinks it has the whole system for itself. It is even possible to allow the customer to do the configuration, or even the installation of newsoftware himself by providing him access to the jail's root account.However, the
FreeBSD jail doesn't achieve truevirtualization because it doesn't allow the virtual machines to run different kernel versions than that of the base system. All virtual servers share the same kernel and hence expose the same bugs and potential security holes. There is no clustering orprocess migration capability included, so the host kernel and host computer is still a single point of failure for all virtual servers. It is possible to use jails to safely test new software, but not new kernels.Security
FreeBSD jails are an effective way to increase the security of a server because of the separation between the jailed environment and the rest of the system (the other jails and the base system). This creates what is called a sandbox.For example, suppose that a system is running an Apache
web server as user www and that the administrator responsible for its contents introduces aPHP include vulnerability . With the traditional scheme, this would compromise the entire system: theattacker would have the rights of the user www which can typically modify files on the web server, wander about in the directory tree and get lots of information, such as the full user list, shell and home directory from /etc/passwd. If the box is serving other purposes than hosting a web server, this can be of a great concern.However, if the web server is jailed, the scope of user www is limited to the jail, which can, in turn, be minimalist enough not to give away unnecessary information. For example, besides the compulsory basic
account s, only www and perhapsftp (to update the web server's contents) would be added as users. So even an attacker who gains access to the root (superuser ) account could only mess around with the web server.If the root account of a
FreeBSD jail is compromised, the attacker still cannot access the entire system because jails are limited in the following ways:* Jailed processes cannot interact with processes in a different jail. For example, the
ps command will only show the processes running in the jail.
* Modifying the running kernel by direct access and loading modules is prohibited. Modifying mostsysctl s and thesecurelevel is prohibited.
* Modifying the network configuration, including interfaces,address es androuting table , is prohibited. Accessing raw, divert androuting socket s are prohibited. For example, a jail is bound to only one IP address and firewall rules cannot be changed.
* Mounting and unmountingfilesystem s is prohibited. Jails cannot access files above their root directory (i.e. a jail ischroot ed).
* Creatingdevice node s is prohibited.Easy delegation
The problem with
Unix rights management is that users are either regular users with limited privileges, orsuperuser s with all privileges. There is nothing in between.Fact|date=July 2007 It is therefore difficult to establish fine-grained rights management. Firstly, it is hard to give regular users only part ofroot 's rights because no matter what is done, at one stage the user gets (for a limited duration) fullprivilege s. Secondly, tasks that seem unconnected can in fact be very dependent on each other. For example allowing a user to modify every file enables him to su ("substitute user") as any user because he can change the logins.With jails it is possible to install different daemons in different jails and
delegate their administration to other people by giving them access to the jailed superuser account. It is safe for two reasons:# The jailed
superuser has limited privileges (so the administrator knows, for example, that he cannot modify firewall rules).
# He can't escape the jail because he cannot get any information about the base system.Similar technologies
Other implementations of
operating system-level virtualization technology areOpenVZ /Virtuozzo ,Linux-VServer ,Solaris Containers , andFreeVPS .sysjail provides jail functionality toNetBSD andOpenBSD .External links
* [http://phk.freebsd.dk/pubs/sane2000-jail.pdf Jails: Confining the omnipotent root]
* [http://www.freebsd.org/cgi/man.cgi?query=jail&format=html jail(8) man page]
* [http://www.onlamp.com/pub/a/bsd/2003/09/04/jails.html FreeBSD jails] at ONLamp
* [http://www.freebsddiary.org/jail-6.php Jail on FreeBSD 6]
* [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html FreeBSD Handbook: Jails]
Wikimedia Foundation. 2010.