chroot and Least Privilege

Software is vulnerable to various attacks that can cause different problems. One of the most insidious is attacks resulting in the attacker gaining root access to your mission-critical servers. BIND has been vulnerable to such attacks, but even so, the impact of such a compromise can be minimized. Not that gaining control of a nameserver isn't useful if you want to break into some network.

The principle of least privilege dictates that you run a service with exactly those access rights it needs, and you restrict its capability of accessing anything else. Although BIND does need to run as root to start, to be capable of listening on port 53, which is privileged, it does need to run as root after the port has been opened. To achieve this, BIND has the -u and -g command-line options, which instruct it to switch to the given user and group identity. The user called nobody and the corresponding group (sometimes called nobody, other times nogroup, and sometimes something else entirely) can be used. If you use these, the risk of root compromise is replaced with a nobody compromise, and no one worries about a nobody. A typical command line for running BIND this way follows:

 named -u nobody -g nogroup 

If you run several services on a machine, all as nobody, you run the risk of having insecurities in one allowing access to another. You might want to create separate accounts for each service that runs on the machine.

UNIX has another mechanism, called chroot, which enables software to be insulated into a chroot jail in the filesystem. After it's inside the jail, with the proper precautions taken, even if the software is compromised, the compromise cannot take over the whole machine because it is restricted to a few directories containing only a few files of limited value. (It has been repeatedly shown that chrooted programs can break out of chroot jails if the program does not take other precautions, which I will not go into here. Using a chroot call in your software and thinking you're safe is a fallacy. For these examples, we will, however, assume that BIND takes those precautions.) Figure 8.1 illustrates how chroot works, and Chapter 15 contains a section on setting up BIND in such a chroot environment. As noted there, the chroot option in BIND 8.2.2 is experimental, and changes might occur in how it works by the time you read this. Please check the release documentation. If you add the -u and -g options to drop root access to the -c option to chroot, you end up with a pretty secure setup. You should, however, police your BIND chroot jail to find out whether any files are changed unexpectedly. That will be a good compromise indicator.

Figure 8.1. The chroot call moves the / of BIND to the machine's /var/BIND-chroot directory, and BIND is incapable of accessing the filesystem outside the jail.