World Library  
Flag as Inappropriate
Email this Article

FreeBSD jail

Article Id: WHEBN0002469109
Reproduction Date:

Title: FreeBSD jail  
Author: World Heritage Encyclopedia
Language: English
Subject: Operating-system-level virtualization, Solaris Containers, History of FreeBSD, Workload Partitions, OpenVZ
Collection: Free Virtualization Software, Freebsd
Publisher: World Heritage Encyclopedia

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 a small shared-environment hosting provider's (R&D Associates, Inc.'s owner, Derrick T. Woolworth) desire to establish a clean, clear-cut separation between their own services and those of their customers, mainly for security and ease of administration (jail(8)). Instead of adding a new layer of fine-grained configuration options, the solution adopted by Poul-Henning Kamp was to compartmentalize the system — both its files and its resources — in such a way that only the right people are given access to the right compartments.


  • Goals 1
    • Virtualization 1.1
    • Security 1.2
  • Similar technologies 2
  • External links 3


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: The limited scope of a jail allows system administrators to delegate several tasks which require superuser access without handing out complete control over the system.

Unlike common chroot jail, which restricts processes to a particular view of the filesystem, the FreeBSD jail mechanism restricts what a process in a jail can do in relation to the rest of the system. In effect, jailed processes are sandboxed. They are bound to specific IP addresses, and a jailed process cannot access divert or routing sockets. Raw sockets are also disabled by default, but may be enabled by setting the security.jail.allow_raw_sockets sysctl option. Additionally, interaction between processes that are not running in the same jail is restricted.

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.


With jail it is possible to create various 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 a web server package 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. Since nothing has actually been modified outside of the jail, "changes" can be discarded by deleting the jail's copy of the directory tree.

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. Without jails, configuring multiple software versions in different directories and ensuring they do not encroach on each other isn't always possible or easy to maintain (e.g. XFree86 is notoriously hard to move around). Jails on the other hand permit software packages to view the system egoistically, as if each package had the machine to itself. Jails can also have their own, independent, jailed superusers.

The FreeBSD jail does not however achieve true virtualization; it does not 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 support for clustering or process migration, 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.


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

For example, in a non-jailed system, a web server running as user www that introduces a PHP-include vulnerability 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.

But if the web server is jailed, the scope of user www is limited to the jail, which in turn can be minimalistic enough not to give away very much. Even if the attacker gained access to the jail's superuser account, he/she could only modify that jail, and not the whole system.

FreeBSD 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, interface or IP addresses, and the routing table, is prohibited. Accessing divert and routing sockets are also prohibited. Additionally raw sockets are disabled by default. A jail is bound only to specific IP addresses 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 chroot'ed).
  • Jailed processes cannot create device nodes.

Similar technologies

External links

  • Jails: Confining the omnipotent root
  • jail(8) man page
  • FreeBSD jails at ONLamp
  • Jail on FreeBSD 6
  • FreeBSD Handbook: Jails

This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from World eBook Library are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.