This document discusses chroot protection and how it can be used as a security measure but also has limitations. Chroot changes the root directory for a process and restricts it to that directory. While chroot can prevent some attacks, there are ways for an attacker to break out of the chroot jail if certain conditions are met, such as having root privileges within the jail or exploiting vulnerabilities in programs running as root. For chroot to provide effective security, daemons must drop root privileges after chrooting and there should be no way to regain higher privileges from within the jail.

1. Chroot protection and breakingAnton Chuvakin, Ph.D. WRITTEN: 2001-2003 (unknown)DISCLAIMER:Security is a rapidly changing field of human endeavor. Threats we face literally change every day; moreover, many security professionals consider the rate of change to be accelerating. On top of that, to be able to stay in touch with such ever-changing reality, one has to evolve with the space as well. Thus, even though I hope that this document will be useful for to my readers, please keep in mind that is was possibly written years ago. Also, keep in mind that some of the URL might have gone 404, please Google around.Chroot command and chroot system call might sound like a good securitymeasure - one command executed and plain old UNIX \"
cd /\"
no longertransports you to a root directory of the system. Instead, you arebound to stay in the restricted part of the filesystem, surroundedonly by files chosen by a paranoid system administrator. In fact, thatis how it should be.Is it possible to break out of chroot solitary confinement? Yes, ifcertain conditions are met. In this paper we will analyze what chrootis good for and also what chroot is bad for. First, how does it work? When one types '/sbin/chroot directory_name'on the UNIX system command line one sees that the new root is now'directory_name' (the '/bin/ls /' command produces the listing offiles from 'directory_name' presuming that you have an 'ls' commandlocated within your new root). Chroot shell command changes the rootdirectory for a process, goes into this directory and then starts ashell or a user-specified command.Chroot command uses a chroot() system call. The command and the systemcall have an important difference between them: unlike the shellcommand, chroot() call does not change your working directory to theone inside chrooted jail. The source of chroot.c (shell command, inLinux part of sh-utils) shows the following sequence of system calls:-----------------chroot (argv[1]);chdir (\"
/\"
);-----------------As will be seen further, it will allow for easy chroot jail breaking.Chroot is often used as a security measure. If one has ever used ananonymous ftp server, one has used chroot. Ftp server chroots itselfinto a special directory upon the anonymous ftp login. DNS (DomainName System) daemon bind is often chrooted as well. People alsosuggested chrooting telnet/ssh remote shell users into theircorresponding home directories, so they can only update their webpages. Web servers can be run chrooted too. Smap secure email wrapperfrom FWTK firewall tool kit runs chrooted to the mail spool directory.When chroot is implemented, programs running inside cannot access anysystem resources on the outside. Thus all system libraries,configuration files and even devices files should be recreated withinthe chroot jail.What daemons can be chrooted? If a daemon has to access files that arenot easily collectible in one place, chrooting it will be hard. Forexample, sendmail needs mail spool (/var/spool/mail), other files inspool (such as mqueue), user's home directories (to check for .forwardfiles) and system configuration files in /etc. There is no place onthe filesystem where sendmail can be effectively confined. Of course,some makeshift solution is possible, but it is not clear that it willadd to security, but rather cause it to lax. If sendmail functionalityis separated into spool daemon and mail transfer program (like done inFWTK smap and smapd), than chrooting is entirely possible.Chrooting shell users is possible if there is a business need to keepthem in some particular directory. Suggestions for doing this withssh2 are provided here: http://www.ssh.com/faq/index.cfm?id=687, andfor openssh here: http://hints.linuxfromscratch.org/hints/openssh.txtand: http://archives.neohapsis.com/archives/sf/linux/2001-q4/0197.htmlHowever, it might involve copying multiple system libraries, files andother resources such as Linux Pluggable Authentication Modules (PAM)architecture, used by most modern Linux distributions. Anything else such as bind, apache, squid can be chrooted, butsometimes the benefits are unclear, especially for daemons that run asroot. This URL (http://www.networkdweebs.com/chroot.html) provides anice list of daemons that its author chrooted successfully.\"
What daemon should be chrooted?\"
is an entirely different questionfrom \"
What daemons can be chrooted?\"
Before we answer it, lets analyzehow attackers break out of chroot.First, the more software is deployed within chroot environment, themore dangerous it becomes, since it is hard to keep track of programsthat can be used by the attacker to elevate permission and escape.Second, the number of ways that root user can break out of chroot ishuge. Starting from simple use of a chroot() call with no chdir() [seecode below] to esoteric methods as the creation of your own /dev/hdaor /dev/kmem devices, injection code into the running kernel(http://www.big.net.au/~silvio/runtime-kernel-kmem-patching.txt),using open directory handles outside chroot or chroot-breaking bufferoverflows. While system capabilities can be used to render inoperablemany of these methods, new ones will likely be found by smartattackers.---------------Sample code to break out of chroot:#include #include #include #include #include int main(void){ int i; mkdir(\"
breakout\"
, 0700); chroot(\"
breakout\"
); for (i = 0; i chdir(\"
..\"
) ; chroot(\"
.\"
); execl(\"
/bin/sh\"
, \"
/bin/sh\"
,NULL);}compile statically (using \"
gcc -static\"
) and run within chrooteddirectory (after doing \"
chroot .\"
or similar from shell prompt) toescape. --------------Third, if there is no root user defined within the chroot environment,no SUID binaries, no devices, and the daemon itself dropped rootprivileges right after calling chroot() call (like in the code below),breaking out of chroot appears to be impossible. In other words, ifthere is no way to gain root shell or perform actions that only rootcan usually perform (e.g. create devices, or access raw memory)breaking chroot is not clearly possible. Ideally, if the customsoftware uses chroot for security the sequence of calls should be:---------------chdir(\"
/home/safedir\"
);chroot(\"
/home/safedir\"
);setuid(500);---------------Keep in mind, that after these lines are executed there will be no wayfor the program to regain root privileges. Fourth, in some cases attackers might not be able to break (i.e. runprocesses outside of chrooted directory), but instead will be able tosomewhat affect such processes. For example, if bind is chrooted,several devices should be created. One of them is /dev/log, necessaryfor logging bind messages into the regular system logs. By crafting amalicious log message and sending it into /dev/log from within thechrooted directory attacker will influence the behavior of syslogdaemon running outside the chroot. If there is a buffer overflow insyslog (which runs as root), additional privileges can be obtained.What daemons can be chrooted but with no valuable security outcome? Inlight of the above, chrooting programs that do not drop rootprivileges while running, or programs that provide root shell access(sshd, telnet with a root account within chrooted directory) does notprovide any extra security.To conclude, chroot() is a good way to increase the security of thesoftware provided that secure programming guidelines are utilized andchroot() system call limitations are taken into account. Chrootingwill prevent an attacker from reading files outside the chroot jailand will prevent many local UNIX attacks (such as SUID abuse and /tmprace conditions).ABOUT THE AUTHOR:This is an updated author bio, added to the paper at the time of reposting in 2009. Dr. Anton Chuvakin (http://www.chuvakin.org) is a recognized security expert in the field of log management and PCI DSS compliance. He is an author of books \"
Security Warrior\"
and \"
PCI Compliance\"
and a contributor to \"
Know Your Enemy II\"
, \"
Information Security Management Handbook\"
and others. Anton has published dozens of papers on log management, correlation, data analysis, PCI DSS, security management (see list www.info-secure.org) . His blog http://www.securitywarrior.org is one of the most popular in the industry.In addition, Anton teaches classes and presents at many security conferences across the world; he recently addressed audiences in United States, UK, Singapore, Spain, Russia and other countries. He works on emerging security standards and serves on the advisory boards of several security start-ups.Currently, Anton is developing his security consulting practice, focusing on logging and PCI DSS compliance for security vendors and Fortune 500 organizations. Dr. Anton Chuvakin was formerly a Director of PCI Compliance Solutions at Qualys. Previously, Anton worked at LogLogic as a Chief Logging Evangelist, tasked with educating the world about the importance of logging for security, compliance and operations. Before LogLogic, Anton was employed by a security vendor in a strategic product management role. Anton earned his Ph.D. degree from Stony Brook University.