32.1 Jail Basics
Brief History of Jail
The word Jail originally means "prison, imprisonment". In FreeBSD terminology, it refers to a container isolation technology improved upon chroot. Jail is pronounced [dʒeɪl].
The concept of container technology emerged in 2000: Jail technology was submitted to the FreeBSD source tree in 1999 and was first officially introduced with FreeBSD 4.0 released in March 2000, implementing triple isolation of file system, process space, and network binding. This technology can partition a FreeBSD system into multiple subsystems (also called Jails).
In 2001, through Jacques Gélinas's VServer project, the implementation of isolated environments entered the Linux domain. Subsequently, the Linux community saw the emergence of OpenVZ (2005), the cgroups resource control mechanism developed by Google engineers (started in 2006, merged into Linux kernel 2.6.24 in 2008), and the first general-purpose Linux container project LXC (first released in 2008).
In March 2013, the company originally named dotCloud (founded in 2008 in Paris) released Docker container technology, and renamed itself to Docker Inc. in October of the same year. Docker initially provided a simpler encapsulation on top of LXC, and later developed an independent container runtime, greatly promoting the popularization of modern container technology.
Jail is built upon the concept of chroot(2), which changes the root directory for a set of processes. This approach creates an environment isolated from the rest of the system. Processes created in a chroot environment cannot directly access files or resources outside of it. Therefore, if a service running in a chroot environment is compromised, it is typically difficult for an attacker to leverage this to compromise the entire system.
chroot has various limitations. It is only suitable for simple tasks and cannot meet complex scenarios requiring strong flexibility or advanced features. Multiple methods of escaping from chroot environments have been discovered, making it no longer an ideal solution for protecting service security.
Jail improved upon the concept of traditional chroot environments in multiple aspects.
In a traditional chroot environment, processes are only restricted in terms of file system accessibility. Other system resources, system users, running processes, and the network subsystem are shared between chroot processes and host system processes. Jail extends this model by virtualizing access to the file system, user sets, and network subsystems. It provides finer-grained control for adjusting the access permissions of the Jail environment. Jail can be regarded as an operating system-level virtualization technology.
References
Red Hat. What are Linux containers? [EB/OL]. [2026-04-04]. https://www.redhat.com/en/topics/containers/whats-a-linux-container. Introduces the basic concepts and technical principles of Linux containers.
Types of Jails
Administrators can classify Jails into different types based on actual needs, although they are technically identical at the underlying level. Each administrator must evaluate which type of Jail to create based on the problem to be solved.
The following lists different types of Jails, their characteristics, and considerations for their use.
Resource Efficiency
Each Jail independently contains a complete base system, higher disk and memory usage
Shares the host or template system, consuming fewer resources
Higher: does not copy the complete file system, only isolates service processes
Deployment Speed
Requires copying the complete system, slower to create and start
Relies on the shared system, faster to create and start
Faster: only needs service configuration to run
Maintenance
Each Jail is updated and maintained independently
Updating the host system affects multiple Jails, centralized maintenance
Minimal: typically only requires one line in /etc/rc.conf
Resource Sharing
Little to no sharing
Shares libraries and binaries, higher disk cache utilization
Fully shares host system resources (libraries, binaries, etc.)
Isolation
Stronger isolation, each Jail environment is independent
Weaker isolation, shares base system components
Weakest: lowest file system isolation, but still subject to Jail mechanism network and process restrictions
Security
Compromise of a single Jail has a smaller impact scope
Shared components pose a larger potential impact scope
Highest risk: may affect the entire host system
Dependency Management
Each Jail has independent dependencies, fewer conflicts
Multiple Jails share the environment, version conflicts may occur
No independent dependency management, fully relies on the host environment
Compatibility
Complete and consistent environment, more stable compatibility
Depends on host/template environment, version differences may occur
Depends on host system compatibility, least flexible
Thick Jail
Thick Jail is the traditional form of FreeBSD Jail. A Thick Jail replicates a complete base system within its own environment. That is, the Jail has an independent instance of the FreeBSD base system, including libraries, executables, and configuration files. A Thick Jail can be regarded as a complete, independent FreeBSD installation running under the control of the host system. This isolation ensures that processes inside the Jail are independent from the host system and other Jails.
Thin Jail
Thin Jails use OpenZFS snapshots or NullFS mounts to share the base system from a template. Each Thin Jail only copies a minimal subset of the base system, thus consuming fewer resources than a Thick Jail, but with weaker isolation and independence. Changes to shared components may affect multiple Thin Jails simultaneously.
Service Jail
By pointing the Jail root path directly to a subdirectory or the root directory of the host system, the Jail can share the file system with the host. This configuration does not copy an independent base system; processes in the Jail can directly access the host system's libraries, binaries, and configuration files, and share the same user accounts as the host system. The root directory of processes inside the Jail is restricted by the path parameter, and chroot file system isolation still exists, but the files visible inside the Jail largely overlap with those on the host. Additionally, processes in the Jail are still subject to other security mechanisms of the Jail framework, such as network isolation and process visibility restrictions, though some restrictions can be configured to be relaxed. This configuration is suitable for scenarios where a service or daemon needs to be quickly confined within a Jail environment without needing to know which files it requires. The configuration is minimal, but the security risks arising from weak file system isolation must be fully understood.
VNET Jail
FreeBSD's VNET Jail is a virtualized environment that allows isolation and control of network resources for processes running within the Jail. By creating an independent network protocol stack for the processes in the Jail, it achieves a high degree of network segmentation and security, ensuring that network traffic within the Jail does not mix with that of the host system or other Jails.
Essentially, FreeBSD's VNET Jail adds a network configuration mechanism. A VNET Jail can be created as either a Thick Jail or a Thin Jail.
Linux Jail
FreeBSD's Linux Jail is a feature of the FreeBSD operating system that allows running Linux binaries and applications within a Jail. See other related chapters for details.
Jail Management Tools Overview
Common Jail management tools include Qjail and iocage, each with different focuses. ezjail was once a widely used Jail management tool, but it is now essentially unmaintained and does not support VNET. It is not recommended for new deployments and only persists in legacy system maintenance scenarios.
Development Language
sh
Python
Current Maintenance
Continuously available
Original repository archived, FreeBSD project maintains it
File System Requirement
UFS / ZFS both supported
ZFS required
ZFS Dependency
No
Yes
UFS Support
Supported
Not supported
VNET Support
Supported
Supported
Network Isolation
Strong
Strong
Configuration Method
Shell scripts
Python CLI
Learning Curve
Moderate
Relatively high
Snapshot/Clone
Limited
Strong (depends on ZFS)
Resource Usage
Very low
Relatively high
Suitable for New Deployments
Recommended
Recommended (ZFS only)
Typical Use Case
General Jail management
Large-scale ZFS Jail environments
Main Limitation
Relatively simple functionality
Strong dependency on ZFS
Last updated