Chroot

Last updated
chroot
Original author(s) Bill Joy, AT&T Bell Laboratories
Developer(s) Various open-source and commercial developers
Initial release1979;44 years ago (1979)
Operating system Unix, Unix-like, Plan 9, Inferno
Platform Cross-platform
Type Command

chroot is an operation on Unix and Unix-like operating systems that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name (and therefore normally cannot access) 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.

Contents

History

The chroot system call was introduced during development of Version 7 Unix in 1979. One source suggests that Bill Joy added it on 18 March 1982 – 17 months before 4.2BSD was released – in order to test its installation and build system. [1] All versions of BSD that had a kernel have chroot(2). [2] [3] An early use of the term "jail" as applied to chroot comes from Bill Cheswick creating a honeypot to monitor a hacker in 1991. [4]

The first article about a jailbreak has been discussed on the security column of SunWorld Online which is written by Carole Fennelly; the August 1999 and January 1999 editions cover most of the chroot() topics. [5]

To make it useful for virtualization, FreeBSD expanded the concept and in its 4.0 release in 2000 introduced the jail command. [6]

By 2002, an article written by Nicolas Boiteux described how to create a jail on Linux [7]

By 2003, first internet microservices providers with Linux jails provide SAAS/PAAS (shell containers, proxy, ircd, bots, ...) services billed for consumption into the jail by usage [8]

By 2005, Sun released Solaris Containers (also known as Solaris Zones), described as "chroot on steroids." [9]

By 2008, LXC (upon which Docker was later built) adopted the "container" terminology [10] and gained popularity in 2013 due to inclusion into Linux kernel 3.8 of user namespaces. [11]

Uses

A chroot environment can be used to create and host a separate virtualized copy of the software 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. Note that chroot is not necessarily enough to contain a process with root privileges.

Limitations

The chroot mechanism is not intended to defend against intentional tampering by privileged (root) users. A notable exception is NetBSD, on which chroot is considered a security mechanism and no escapes are known. On most systems, 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 these security weakness, chrooted programs should relinquish root privileges as soon as practical after chrooting, or other mechanisms – such as FreeBSD jails – should be used instead. Note that some systems, such as FreeBSD, take precautions to prevent a second chroot attack. [12]

On systems that support device nodes on ordinary filesystems, 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. It 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.

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. Tools such as Jailkit can help to ease and automate this process.

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 and /etc/shadow file) that would fool it into a privilege escalation.

Some Unixes offer extensions of the chroot mechanism to address at least some of these limitations (see Implementations of operating system-level virtualization technology).

Graphical applications on chroot

It is possible to run graphical applications on a chrooted environment, using methods such as: [13] [14]

Notable applications

The Postfix mail transfer agent operates as a pipeline of individually chrooted helper programs.

Like 4.2BSD before it, 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. Fedora, Red Hat, and various other RPM-based distributions build all RPMs using a chroot tool such as mock.

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). [16]

ChromeOS can use a chroot to run a Linux instance using Crouton, [17] providing an otherwise thin OS with access to hardware resources. The security implications related in this article apply here.

Linux host kernel virtual file systems and configuration files

To have a functional chroot environment in Linux, the kernel virtual file systems and configuration files also have to be mounted/copied from host to chroot.

# Mount Kernel Virtual File SystemsTARGETDIR="/mnt/chroot" mount-tprocproc$TARGETDIR/proc mount-tsysfssysfs$TARGETDIR/sys mount-tdevtmpfsdevtmpfs$TARGETDIR/dev mount-ttmpfstmpfs$TARGETDIR/dev/shm mount-tdevptsdevpts$TARGETDIR/dev/pts  # Copy /etc/hosts /bin/cp-f/etc/hosts$TARGETDIR/etc/  # Copy /etc/resolv.conf  /bin/cp-f/etc/resolv.conf$TARGETDIR/etc/resolv.conf  # Link /etc/mtab chroot$TARGETDIRrm/etc/mtab2>/dev/null chroot$TARGETDIRln-s/proc/mounts/etc/mtab 

See also

Related Research Articles

<span class="mw-page-title-main">Unix shell</span> Command-line interpreter for Unix operating system

A Unix shell is a command-line interpreter or shell that provides a command line user interface for Unix-like operating systems. The shell is both an interactive command language and a scripting language, and is used by the operating system to control the execution of the system using shell scripts.

<span class="mw-page-title-main">Root directory</span> First or top-most directory in a hierarchy

In a computer file system, and primarily used in the Unix and Unix-like operating systems, the root directory is the first or top-most directory in a hierarchy. It can be likened to the trunk of a tree, as the starting point where all branches originate from. The root file system is the file system contained on the same disk partition on which the root directory is located; it is the filesystem on top of which all other file systems are mounted as the system boots up.

<span class="mw-page-title-main">Virtual file system</span> Abstract layer on top of a more concrete file system

A virtual file system (VFS) or virtual filesystem switch is an abstract layer on top of a more concrete file system. The purpose of a VFS is to allow client applications to access different types of concrete file systems in a uniform way. A VFS can, for example, be used to access local and network storage devices transparently without the client application noticing the difference. It can be used to bridge the differences in Windows, classic Mac OS/macOS and Unix filesystems, so that applications can access files on local file systems of those types without having to know what type of file system they are accessing.

passwd Tool to change passwords on Unix-like OSes

passwd is a command on Unix, Plan 9, Inferno, and most Unix-like operating systems used to change a user's password. The password entered by the user is run through a key derivation function to create a hashed version of the new password, which is saved. Only the hashed version is stored; the entered password is not saved for security reasons.

fstab is a system file commonly found in the directory /etc on Unix and Unix-like computer systems. In Linux, it is part of the util-linux package. The fstab file typically lists all available disk partitions and other types of file systems and data sources that may not necessarily be disk-based, and indicates how they are to be initialized or otherwise integrated into the larger file system structure.

The Linux and Unix access rights flags setuid and setgid allow users to run an executable with the file system permissions of the executable's owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily elevated privileges to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

Filesystem in Userspace (FUSE) is a software interface for Unix and Unix-like computer operating systems that lets non-privileged users create their own file systems without editing kernel code. This is achieved by running file system code in user space while the FUSE module provides only a bridge to the actual kernel interfaces.

In computer security, a sandbox is a security mechanism for separating running programs, usually in an effort to mitigate system failures and/or software vulnerabilities from spreading. The isolation metaphor is taken from the idea of children who do not play well together, so each is given their own sandbox to play in alone. It is often used to execute untested or untrusted programs or code, possibly from unverified or untrusted third parties, suppliers, users or websites, without risking harm to the host machine or operating system. A sandbox typically provides a tightly controlled set of resources for guest programs to run in, such as storage and memory scratch space. Network access, the ability to inspect the host system, or read from input devices are usually disallowed or heavily restricted.

Unix-like operating systems identify a user by a value called a user identifier, often abbreviated to user ID or UID. The UID, along with the group identifier (GID) and other access control criteria, is used to determine which system resources a user can access. The password file maps textual user names to UIDs. UIDs are stored in the inodes of the Unix file system, running processes, tar archives, and the now-obsolete Network Information Service. In POSIX-compliant environments, the shell command id gives the current user's UID, as well as more information such as the user name, primary user group and group identifier (GID).

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

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. It is implemented through a system call, jail(2), as well as a userland utility, jail(8), 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.

mount (Unix) Unix command to mount a filesystem

In computing, mount is a command in various operating systems. Before a user can access a file on a Unix-like machine, the file system on the device which contains the file needs to be mounted with the mount command. Frequently mount is used for SD card, USB storage, DVD and other removable storage devices. The command is also available in the EFI shell.

OS-level virtualization is an operating system (OS) virtualization 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 Unix-like operating systems, a loop device, vnd, or lofi is a pseudo-device that makes a computer file accessible as a block device.

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

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">Unix filesystem</span> Directory structure used by a Unix-like operating system

In Unix and operating systems inspired by it, the file system is considered a central component of the operating system. It was also one of the first parts of the system to be designed and implemented by Ken Thompson in the first experimental version of Unix, dated 1969.

<span class="mw-page-title-main">LXC</span> Operating system-level virtualization for Linux

Linux Containers (LXC) is an operating-system-level virtualization method for running multiple isolated Linux systems (containers) on a control host using a single Linux kernel.

Android devices have the ability to run virtual machines or emulate other operating systems. It does this either via desktop virtualization, platform virtualization, or emulation via compatibility layer.

References

  1. "jail, section 9". docs.freebsd.org. Archived from the original on 2017-01-05. Retrieved 2016-03-14.
  2. Losh, Warner (February 2, 2000). "Warner's Random Hacking Blog: Whither chroot?". Archived from the original on June 28, 2020. Retrieved June 28, 2020.
  3. "Data Infrastructures for the rest of us - III - software". Archived from the original on 2020-06-30. Retrieved 2020-06-28.
  4. Cheswick, Bill (1991). "An Evening with Berferd: In Which a Cracker is Lured, Endured, and Studied" (PDF). USENIX Summer Conference Proceedings, Volume 1. USENIX. San Francisco, California: The Association. p. 163. Archived (PDF) from the original on 2018-11-05. Retrieved 2018-06-09.
  5. Carole, Fennelly. "Summertime potluck". SunWorld Online. Carole Fennelly. Archived from the original on September 28, 2021.
  6. Riondato, Matteo. "FreeBSD Handbook "Jails" Chapter". freebsd.org. The FreeBSD Project. Archived from the original on 2014-08-15. Retrieved 2018-10-30.
  7. Nicolas, Boiteux. "chroot shell". lycos.fr. Nicolas Boiteux. Archived from the original on 2002-10-14. Retrieved 24 March 2018.
  8. "Girafon". girafon.org. girafon. Archived from the original on 2004-06-12. Retrieved 24 March 2018.
  9. Schmidt, Klaus (2006-09-02). High Availability and Disaster Recovery: Concepts, Design, Implementation. Springer Science & Business Media. p. 186. ISBN   9783540345824. Archived from the original on 2023-02-20. Retrieved 2014-08-21.
  10. "SourceForge LXC Download Files". sourceforge.net. Archived from the original on 2014-08-19. Retrieved 2014-08-21.
  11. Rosen, Rami (2014-03-26). "Linux Containers and the Future Cloud" (PDF). Archived (PDF) from the original on 2016-04-18. Retrieved 2014-08-21.
  12. "chroot(2)". www.freebsd.org. Archived from the original on 2020-09-18. Retrieved 2020-12-02.
  13. "Development/Howto/Chroot". Mandriva Wiki. 25 July 2011. Archived from the original on 2014-03-26.
  14. "HOWTO startx in a chroot". Gentoo Wiki. Archived from the original on 2011-08-31. Retrieved 2011-10-13.
  15. David, Redfield (October 10, 2023). "Atoms is a Linux Chroot Management Tool with a User-Friendly GUI".
  16. "sshd_config(5) manual page". 2017-10-26. Archived from the original on 2018-02-05. Retrieved 2018-02-04.
  17. "Chromium OS Universal Chroot Environment (on github)". GitHub . Archived from the original on 2016-11-25. Retrieved 2016-12-17.