Editing Chroot (section)

==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 [https://web.archive.org/web/20160127150916/http://www.bpfh.net/simes/computing/chroot-break.html 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, or other mechanisms&nbsp;– such as [[FreeBSD jail]]s – should be used instead. Note that some systems, such as [[FreeBSD]], take precautions to prevent a second chroot attack.<ref>{{Cite web|url=https://www.freebsd.org/cgi/man.cgi?query=chroot&sektion=2&n=1|title=chroot(2)|website=www.freebsd.org|access-date=2020-12-02|archive-date=2020-09-18|archive-url=https://web.archive.org/web/20200918091526/https://www.freebsd.org/cgi/man.cgi?query=chroot&sektion=2&n=1|url-status=live}}</ref>

On systems that support device nodes on ordinary filesystems, a chrooted [[superuser|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 [[Input/output|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 node]]s and [[shared library|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 [https://olivier.sessink.nl/jailkit/ Jailkit] can help to ease and automate this process. 

Only the [[superuser|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 {{mono|[[/etc/passwd]]}} and {{mono|[[/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 [[Operating system-level virtualization#Implementations|Implementations of operating system-level virtualization technology]]).