What Is a chroot Jail

The basic idea behind a chroot jail is to isolate a server in a minimal virtual Linux system. This system is defined by a special directory tree you devote to the jail. For instance, you might set aside /jails/ftp to house the FTP server. As far as the FTP server is concerned, /jails/ftp is the root directory; when the FTP server tries to access files in /pub, it's really reading files from /jails/ftp/pub. This configuration has several important implications:

No Access Outside the Jail The jailed application can't access potentially sensitive files that reside outside of the jail, such as configuration files in /etc. Even read access to these directories is unavailable. This fact makes it very difficult for jailed applications to abuse security flaws in other programs or to retrieve potentially unprotected but sensitive files.

Need to Reproduce Vital System Files All the files a jailed application requires must be duplicated within the jail. For instance, if a server needs a particular library file, you must copy it to an appropriate subdirectory within the jail. (In some cases, a hard link will work; but using a hard link gives the jailed application access to the file outside of the jail.) Depending on how the jailed server is started, it may need configuration files within the jail. You may also need to create duplicates of device files and even the /proc filesystem for some servers.

Super Server Interactions If a server is normally run from a super server, you must do one of three things: reconfigure the server or the super server to lock the server in the jail; run a copy of the super server in the jail along with the target server; or reconfigure the server to run without a super server.

Increased Maintenance Effort Servers don't usually ship configured to operate within jails, although some servers are easier to configure in this way. Therefore, when you upgrade a server, you'll probably have to copy the upgraded files into the jail and restart the server.

Multiple Jails You can set up multiple jail directories, one for each jailed server. Doing so can improve your security compared to operating just one jail. For instance, suppose two servers have security flaws that interact, enabling one server to be abused to modify another's configuration files, which in turn could give an intruder root access. If these two servers are run in separate jails, neither can see the other's configuration files, so the interaction vulnerability can't be abused without breaking out of the jail.

Unfortunately, chroot jails are imperfect. It is possible for root to break out of a chroot jail. Therefore, a server run as root might be able to break out of the jail if it's compromised. An intruder might also be able to do substantial damage even working from within a chroot jail. For instance, a mail server that's misconfigured as an open relay could be abused by a spammer to relay mail whether or not it's run from within a jail. Some servers may not work well within a jail. For instance, a file server might need access to users' home directories, which probably aren't in the jail. Of course, with some planning you could put users' home directories within the jail.

In sum, a chroot jail isn't a panacea, but it is a useful security tool. Some servers, such as many FTP servers, are designed to be run from within a jail and include configuration commands that make it easy to do so. Other servers aren't designed with chrootjail use in mind, but some of these can still be run from within a jail by calling them with the chroot command.

0 0

Post a comment