What Is a chroot Jail?
Linux's directory system is built on a root ( / ) directory. All directories fall off of this one, and can be referred to relative to the root directory. A chroot jail effectively changes the root directory (hence the name ) to something else, as illustrated in Figure 23.1. For instance, if you set aside /opt/chroot as a new root directory for a server, all file references made by the server will be relative to /opt/chroot rather than the true root directory. Thus, even if a server is compromised and the attacker uses it to modify, say, /etc/passwd , the modification will actually affect /opt/chroot/etc/ passwd , which is not nearly as serious a matter as a change to the real /etc/passwd .
Figure 23.1. A chroot jail creates a special environment that contains only those files required for a particular server to run.
This scheme is implemented through a system call known as chroot() , often as used by a program called chroot . You can set up a chroot jail either by using a server that handles the matter itself with its own chroot() call or by using the chroot program to launch the server. These issues are described in more detail shortly, in the section "Configuring a Server to Operate in a chroot Jail."
The entire chroot jail system has several important consequences and implications:
Although a chroot jail sounds like a great way to minimize the risk of running servers, it's not without its drawbacks and limitations. One of these is that not all servers operate well in chroot jails. Some, such as most FTP servers using anonymous mode and some mail servers, are designed to operate partly or wholly in a chroot jail. Others, like Telnet servers, require more-or-less complete access to the normal Linux system in order to do their jobs. Thus, you can't simply set up all your servers to operate in chroot jails, although you can do this with some.
Because most chroot jails are configured by the system administrator rather than set up automatically by package management systems, it's possible to overlook the chroot server after you upgrade the server package. You must remember to recopy any changed files after any upgrade. If you don't, your chroot server may be left vulnerable.
Another limitation of chroot jails is that they aren't impenetrable. Processes run as root from within the jail can issue the chroot() call to return to the real root directory. (It's actually a bit more complex than issuing a single chroot() call, but not by much.) Thus, you should be very cautious about giving root privileges to any server run from within a chroot jail. Although servers are supposed to be well behaved, bugs and misconfigurations have been known to provide root access to undesirable outsiders in the past, and this is all but certain to happen in the future. Thus, although a chroot jail is a useful security tool, it's not a panacea.
A chroot jail can provide protection against attacks on your computer, but if a miscreant uses a server to attack other systems, a chroot jail provides little or no protection. For instance, a compromised DNS server may give false name lookups, allowing an attacker to access an NFS server that authorizes hosts by name rather than by IP address, even if the DNS server runs in a chroot jail. Similarly, a server run from a chroot jail might provide an attacker with a means to directly attack other systems from your server's IP address.
Finally, even if you run one server in a chroot jail, others may not be running in this way, and so may pose a risk. What's more, if the filesystem areas handled by these servers overlap, it may be possible to pass files between the chroot server and the conventional server, which might be risky if the files in question are configuration files or the like.