FreeBSD jail
The FreeBSD jail mechanism is an implementation of operating system-level virtualization that allows administrators to partition a FreeBSD-based computer system into several independent mini-systems called jails.
The need for the FreeBSD jails came from service providers' desire to establish a clean cut separation between their services and their customers, 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 its files and its resources, in such a way that only the right person(s) are allowed access to the right compartment(s).
Contents |
Goals
FreeBSD jails mainly aim at three goals:
- Virtualization: Each jail is a virtual environment running on the host machine with its own files, processes, user and superuser 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 of security.
- Ease of delegation: 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 the chroot jail method of restricting the scope of processes. The FreeBSD 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 one IP address and cannot access raw, divert or routing sockets).
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 in FreeBSD 5.1. The jail subsystem has been significantly updated for FreeBSD 8, including support for multiple IPv4, IPv6 and SCTP addresses per jail and support for binding jails to specific CPUs.
Virtualization
With jail it is possible to create various different virtual machines, each of them having their own set of utilities installed and their own configuration. This makes it a safe way to try out software. For example it is possible to run different versions 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 the superuser) 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 new software himself by providing him access to the jail's root account.
However, the FreeBSD jail doesn't achieve true virtualization 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 or process 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 a PHP include vulnerability. With the traditional scheme, this would compromise the entire system: the attacker 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 accounts, only www and perhaps ftp (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 most sysctls and the securelevel is prohibited.
- Modifying the network configuration, including interfaces, addresses and routing table, is prohibited. Accessing raw, divert and routing sockets are prohibited. For example, a jail is bound to only one IP address and firewall rules cannot be changed.
- Mounting and unmounting filesystems is prohibited. Jails cannot access files above their root directory (i.e. a jail is chrooted).
- Creating device nodes is prohibited.
Easy delegation
The problem with traditional Unix rights management (e.g. ignoring MAC-like approaches, which are also supported in FreeBSD) is that users are either regular users with limited privileges, or superusers with all privileges. It is therefore difficult to establish fine-grained rights management. Firstly, it is hard to give regular users only part of root's rights because no matter what is done, at one stage the user gets (for a limited duration) full privileges. 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.
Jails are especially powerful in combination with ZFS, where the in-jail superusers can manipulate their own file systems.
Similar technologies
Other implementations of operating system-level virtualization technology are Solaris Containers, Linux's OpenVZ/Virtuozzo, Linux-VServer, and FreeVPS, and sysjail in NetBSD and OpenBSD.
External links
- Jails: Confining the omnipotent root
- jail(8) man page
- FreeBSD jails at ONLamp
- Jail on FreeBSD 6
- FreeBSD Handbook: Jails
|
|||||||||||
Why are we here?
All text is available under the terms of the GNU Free Documentation License
This page is cache of Wikipedia. History