Jump to content

FreeBSD jail

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 164.67.97.133 (talk) at 02:52, 19 November 2009 (→Easy delegation: Most uses of "unix rights management" are crude and don't fully leverage the possible granularity, so the first sentence must be qualified with "often" or "typically".). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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. 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).

Goals

FreeBSD jails mainly aim at three goals:

  1. 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.
  2. Security: Each jail is sealed from the others thus providing an additional level of security.
  3. 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 7.2, including support for multiple IPv4 and IPv6 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 in-jail 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:

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 typically 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:

  1. The jailed superuser has limited privileges (so the administrator knows, for example, that he cannot modify firewall rules).
  2. 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/OpenSolaris
Solaris Containers

Linux
Linux-VServer
OpenVZ
FreeVPS

AIX
Workload_Partitions

Windows
Sandboxie
iCore Virtual Accounts
Feather Weight Virtual Machine

NetBSD/OpenBSD
sysjail no longer supported as of 03-03-2009

Mac OS X
Mac OS X does not have an equivalent feature


Retrieved from "https://en.wikipedia.org/w/index.php?title=FreeBSD_jail&oldid=326662099"