chroot
From Wikipedia, the free encyclopedia
A chroot on Unix operating systems is an operation that changes the apparent disk root directory for the current running process and its children. A program that is re-rooted to another directory cannot access or name files outside that directory, called a "chroot jail" or (less commonly) a "chroot prison". The term "chroot" may refer to the chroot(2) system call or the chroot(8) wrapper program.
The chroot system call was introduced by Bill Joy on 18 March 1982—17 months before 4.2BSD was released—in order to test its installation and build system.
Contents |
[edit] Uses
A chroot environment can be used to create and host a separate virtualized copy of the operating system. This can be useful for:
- Testing and development
- A test environment can be set up in the chroot for software that would otherwise be too risky to deploy on a production system.
- Dependency control
- Software can be developed, built and tested in a chroot populated only with its expected dependencies. This can prevent some kinds of linkage skew that can result from developers building projects with different sets of program libraries installed.
- Compatibility
- Legacy software or software using a different ABI must sometimes be run in a chroot because their supporting libraries or data files may otherwise clash in name or linkage with those of the host system.
- Recovery
- Should a system be rendered unbootable, a chroot can be used to move back into the damaged environment after bootstrapping from an alternate root file system (such as from installation media, or a Live CD).
- Privilege separation
- Programs are allowed to carry open file descriptors (for files, pipelines and network connections) into the chroot, which can simplify jail design by making it unnecessary to leave working files inside the chroot directory. This also simplifies the common arrangement of running the potentially-vulnerable parts of a privileged program in a sandbox, in order to pre-emptively contain a security breach. An attacker with root privileges, however, may trivially defeat this separation because the chroot does not bar system calls, shield processes outside the chroot from tracing or disallow access to block devices.
- Honeypotting
- A chroot can be populated so as to simulate a real system running network services. However, as chroot does not virtualize system calls, access to block devices or virtual file systems (such as /proc and /sys on Linux), it may still be possible for an attacker in the honeypot to detect the presence of the honeypot and the system outside the chroot.
[edit] Limitations
- At startup, programs expect to find scratch space, configuration files, device nodes and shared libraries at certain preset locations. For a chrooted program to successfully start, the chroot directory must be populated with a minimum set of these files. This can make chroot difficult to use as a general sandboxing mechanism.
- Only the root user can perform a chroot. This is intended to prevent users from putting a setuid program inside a specially-crafted chroot jail (for example, with a fake /etc/passwd file) that would fool it into giving out privileges. It also prevents chroot from being used as an unprivileged sandboxing mechanism (for example, for users to run and test untrusted applications downloaded from the Internet).
- The chroot mechanism is not intended to defend against intentional tampering by privileged (root) users. On some systems, for example, chroot contexts do not stack properly and chrooted programs with sufficient privileges may perform a second chroot to break out. To mitigate the risk of this security weakness, chrooted programs should relinquish root privileges as soon as practical after chrooting.
- A chrooted root user can still create device nodes and mount the file systems on them; thus, the chroot mechanism is not intended by itself to be used to block low-level access to system devices by privileged users.
- The chroot mechanism in itself also is not intended to restrict the use of resources like I/O, bandwidth, disk space or CPU time. Most Unixes are not completely file system-oriented and leave potentially disruptive functionality like networking and process control available through the system call interface to a chrooted program.
Some Unices offer extensions of the chroot mechanism—broadly termed operating system-level virtualization—to address at least some of these limitations. These include:
- Containers in Solaris
- Security contexts in Linux-VServer and Linux FreeVPS
- Jails in FreeBSD
- Sysjails in NetBSD and OpenBSD
[edit] Notable applications
- The Postfix mail transfer agent operates as a pipeline of individually-chrooted helper programs.
- The Debian and Ubuntu internal package-building farms use chroots extensively to catch unintentional build dependencies between packages. SUSE uses a similar method with its build program.
- Many FTP servers for POSIX systems use the chroot mechanism to sandbox untrusted FTP clients. This may be done by forking a process to handle an incoming connection, then chrooting the child (to avoid having to populate the chroot with libraries required for program startup).
- If privilege separation is enabled, the OpenSSH daemon will chroot an unprivileged helper process into an empty directory to handle pre-authentication network traffic for each client. The daemon can also sandbox SFTP and shell sessions in a chroot (from version 4.9p1 onwards).[1]
[edit] References
[edit] See also
|
||||||||||||||||||||||||||
