What Is a chroot Jail?

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:

  • If a program relies on configuration files, uses dynamic libraries, accepts or delivers files, or otherwise manipulates any local files, those files must exist within the chroot environment. This requirement can result in a very large chroot environment directory tree if the server requires many support files. One exception is that if the server implements its own chroot() call, and if it reads the support files before making the chroot() call, those support files should exist outside of the chroot environment.

  • A server running in a chroot jail can access only those files that reside within the same jail. This means that you should keep extraneous files within that environment to a minimum to give the jailed tool as little opportunity to do mischief as possible.

  • A corollary of the preceding consequence is that if you run multiple servers in chroot jails, you should create separate jails for each of them. This minimizes the chance that a bug in one server could be used to reconfigure the other server, thus giving the attacker greater access to your system.

  • Because the chroot jail environment exists as a subdirectory within the normal Linux directory tree, programs that are not run from a chroot jail can place files within the jail. This can be a convenience or a potential security risk, depending upon your point of view. This point is further elaborated in the upcoming section, "Controlling Local Access to the chroot Environment."

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.

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net