FreeBSD jail

Last updated

The jail mechanism is an implementation of FreeBSD's OS-level virtualisation that allows system administrators to partition a FreeBSD-derived computer system into several independent mini-systems called jails, all sharing the same kernel, with very little overhead [1] . It is implemented through a system call, jail(2), [2] as well as a userland utility, jail(8), [3] plus, depending on the system, a number of other utilities. The functionality was committed into FreeBSD in 1999 by Poul-Henning Kamp after some period of production use by a hosting provider, and was first released with FreeBSD 4.0, thus being supported on a number of FreeBSD descendants, including DragonFly BSD, to this day.

Contents

History

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. [4]

Jails were first introduced in FreeBSD version 4.0, that was released on March 14, 2000. [5] Most of the original functionality is supported on DragonFly, and several of the new features have been ported as well.

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: 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 chroot jail, which only restricts processes to a particular view of the filesystem, the FreeBSD jail mechanism restricts the activities of a process in a jail with respect 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 received further significant updates with 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 environments, each having its own set of utilities installed and its own configuration. Jails on the 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. [6]

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 jails share the same kernel. There is no support for clustering or process migration.

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

FreeBSD jails are limited in the following ways: [6]

See also

Related Research Articles

<span class="mw-page-title-main">DragonFly BSD</span> Free and open-source Unix-like operating system

DragonFly BSD is a free and open-source Unix-like operating system forked from FreeBSD 4.8. Matthew Dillon, an Amiga developer in the late 1980s and early 1990s and FreeBSD developer between 1994 and 2003, began working on DragonFly BSD in June 2003 and announced it on the FreeBSD mailing lists on 16 July 2003.

A chroot on Unix and Unix-like operating systems is an operation that changes the apparent root directory for the current running process and its children. A program that is run in a modified environment such that it cannot name files outside the designated directory tree. The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program. The modified environment is called a chroot jail.

<span class="mw-page-title-main">Security-focused operating system</span> Operating systems, that are focused on anonymous, privacy and security.

This is a list of operating systems specifically focused on security. Operating systems for general-purpose usage may be secure without having a specific focus on security.

<span class="mw-page-title-main">Linux-VServer</span> OS-level virtualisation

Linux-VServer is a virtual private server implementation that was created by adding operating system-level virtualization capabilities to the Linux kernel. It is developed and distributed as open-source software.

The proc filesystem (procfs) is a special filesystem in Unix-like operating systems that presents information about processes and other system information in a hierarchical file-like structure, providing a more convenient and standardized method for dynamically accessing process data held in the kernel than traditional tracing methods or direct access to kernel memory. Typically, it is mapped to a mount point named /proc at boot time. The proc file system acts as an interface to internal data structures about running processes in the kernel. In Linux, it can also be used to obtain information about the kernel and to change certain kernel parameters at runtime (sysctl).

<span class="mw-page-title-main">Poul-Henning Kamp</span> Danish software developer

Poul-Henning Kamp is a Danish computer software developer known for work on various projects including FreeBSD and Varnish. He currently resides in Slagelse, Denmark.

sysfs is a pseudo file system provided by the Linux kernel that exports information about various kernel subsystems, hardware devices, and associated device drivers from the kernel's device model to user space through virtual files. In addition to providing information about various devices and kernel subsystems, exported virtual files are also used for their configuration.

sysctl Unix-like software that manages kernel attributes

sysctl is a software utility of some Unix-like operating systems that reads and modifies the attributes of the system kernel such as its version number, maximum limits, and security settings. It is available both as a system call for compiled programs, and an administrator command for interactive use and scripting. Linux additionally exposes sysctl as a virtual file system.

OS-level virtualization is an operating system (OS) paradigm in which the kernel allows the existence of multiple isolated user space instances, called containers, zones, virtual private servers (OpenVZ), partitions, virtual environments (VEs), virtual kernels, or jails. Such instances may look like real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can see all resources of that computer. However, programs running inside of a container can only see the container's contents and devices assigned to the container.

In computing, ioctl is a system call for device-specific input/output operations and other operations which cannot be expressed by regular system calls. It takes a parameter specifying a request code; the effect of a call depends completely on the request code. Request codes are often device-specific. For instance, a CD-ROM device driver which can instruct a physical device to eject a disc would provide an ioctl request code to do so. Device-independent request codes are sometimes used to give userspace access to kernel functions which are only used by core system software or still under development.

securelevel is a security mechanism in *BSD kernels, which can optionally restrict certain capabilities. Securelevel is controlled by the sysctl variable kern.securelevel. This value is an integer, which when set to a value > 0 enables certain classes of restrictions. Any superuser process can raise securelevel, but only the init process can lower it.

Netlink is a socket family used for inter-process communication (IPC) between both the kernel and userspace processes, and between different userspace processes, in a way similar to the Unix domain sockets available on certain Unix-like operating systems, including its original incarnation as a Linux kernel interface, as well as in the form of a later implementation on FreeBSD. Similarly to the Unix domain sockets, and unlike INET sockets, Netlink communication cannot traverse host boundaries. However, while the Unix domain sockets use the file system namespace, Netlink sockets are usually addressed by process identifiers (PIDs).

<span class="mw-page-title-main">FreeBSD</span> Free and open-source Unix-like operating system

FreeBSD is a free and open-source Unix-like operating system descended from the Berkeley Software Distribution (BSD). The first version of FreeBSD was released in 1993. In 2005, FreeBSD was the most popular open-source BSD operating system, accounting for more than three-quarters of all installed and permissively licensed BSD systems.

Single-user mode is a mode in which a multiuser computer operating system boots into a single superuser. It is mainly used for maintenance of multi-user environments such as network servers. Some tasks may require exclusive access to shared resources, for example running fsck on a network share. This mode can also be used for security purposes – network services are not run, eliminating the possibility of outside interference. On some systems a lost superuser password can be changed by switching to single-user mode, but not asking for the password in such circumstances is viewed as a security vulnerability.

authbind is an open-source system utility written by Ian Jackson and is distributed under the GNU General Public License. The authbind software allows a program that would normally require superuser privileges to access privileged network services to run as a non-privileged user. authbind allows the system administrator to permit specific users and groups access to bind to TCP and UDP ports below 1024. Ports 0 - 1023 are normally privileged and reserved for programs that are run as the root user. Allowing regular users limited access to privileged ports helps prevent possible privilege escalation and system compromise if the software happens to contain software bugs or is found to be vulnerable to unknown exploits.

In Unix-like operating systems, a device file or special file is an interface to a device driver that appears in a file system as if it were an ordinary file. There are also special files in DOS, OS/2, and Windows. These special files allow an application program to interact with a device by using its device driver via standard input/output system calls. Using standard system calls simplifies many programming tasks, and leads to consistent user-space I/O mechanisms regardless of device features and functions.

<span class="mw-page-title-main">Berkeley Software Distribution</span> Unix operating system

The Berkeley Software Distribution or Berkeley Standard Distribution (BSD) is a discontinued operating system based on Research Unix, developed and distributed by the Computer Systems Research Group (CSRG) at the University of California, Berkeley. The term "BSD" commonly refers to its open-source descendants, including FreeBSD, OpenBSD, NetBSD, and DragonFly BSD.

<span class="mw-page-title-main">Rump kernel</span> Software run in userspace that offers kernel functionality

The NetBSD rump kernel is the first implementation of the "anykernel" concept where drivers either can be compiled into or run in the monolithic kernel or in user space on top of a light-weight kernel. The NetBSD drivers can be used on top of the rump kernel on a wide range of POSIX operating systems, such as the Hurd, Linux, NetBSD, DragonFly BSD, Solaris kernels and even Cygwin, along with the file system utilities built with the rump libraries. The rump kernels can also run without POSIX directly on top of the Xen hypervisor, an L4 microkernel using the Genode OS Framework or even on "OS-less" bare metal.

The hw.sensors framework is a kernel-level hardware sensors framework originating from OpenBSD, which uses the sysctl kernel interface as the transport layer between the kernel and the userland. As of 2019, the framework is used by over a hundred device drivers in OpenBSD to export various environmental sensors, with temperature sensors being the most common type. Consumption and monitoring of sensors is done in the userland with the help of sysctl, systat, sensorsd, ntpd, snmpd, ports/sysutils/symon and GKrellM.

A virtual kernel architecture (vkernel) is an operating system virtualisation paradigm where kernel code can be compiled to run in the user space, for example, to ease debugging of various kernel-level components, in addition to general-purpose virtualisation and compartmentalisation of system resources. It is used by DragonFly BSD in its vkernel implementation since DragonFly 1.7, having been first revealed in September 2006, and first released in the stable branch with DragonFly 1.8 in January 2007. The long-term goal, in addition to easing kernel development, is to make it easier to support internet-connected computer clusters without compromising local security. Similar concepts exist in other operating systems as well; in Linux, a similar virtualisation concept is known as user-mode Linux; whereas in NetBSD since the summer of 2007, it has been the initial focus of the rump kernel infrastructure.

References

  1. David Chisnall (2007-06-15). "DragonFly BSD: UNIX for Clusters?". InformIT . Prentice Hall Professional . Retrieved 2019-03-06.
  2. "jail(2) — create and manage system jails". FreeBSD, DragonFly BSD.
  3. "jail(8) — manage system jails". FreeBSD, DragonFly BSD.
  4. Kamp, Poul-Henning; N. M. Watson, Robert (2000). "Jails: Confining the omnipotent root" (PDF). PHKs Bikeshed. Retrieved 15 June 2016.
  5. "FreeBSD 4.0 Announcement". FreeBSD Project. 14 March 2000. Retrieved 3 October 2019.
  6. 1 2 "Chapter 16. Jails". FreeBSD Documentation Portal. Retrieved 13 December 2022.

Further reading