Use chroot to Protect a Service

chroot is available as a shell command as well as a system call for binary applications. We will focus on using the chroot command ( man 1 chroot ) since programming with chroot ( man 2 chroot ) introduces a different set of considerations. Also, our goal is to improve the security of an established service, not reinvent the wheel!

Note  

The chroot command is native to most Linux distributions. It is currently part of the GNU coreutils package, http://www.gnu.org/software/coreutils/, although you may find references to its previous package, shellutils. chroot ( change root ) enables the administrator to execute a shell in a specially restricted root directory.

Understand What Is Protected and What Isn t

Processes running inside a chroot environment are intended to be run with non-root privileges. Even though common services such as web, DNS, and SSH can be configured to run with non-root privileges, the process still has access to the entire file system. All of these services have also suffered from buffer overflow exploits. If the exploit provides shell access in the context of the process s owner (a non-root account), then you can strictly limit the scope of a compromise. Instead of allowing a buffer overflow to dump a root shell from a root-owned process, send the attacker into a non-root shell. Then isolate the service and its directory structure with chroot so that it doesn t even contain an /etc/shadow file. This way you expose less of the operating system while preserving the full functionality of the service.

chroot environments can also be placed on alternate partitions and closely monitored . Administrators have many areas to watch for potential security problems. By narrowing the focus to a specific portion of the operating system and its file system, the administrator s job becomes a little easier.

The chroot command shares a common attribute among security- related tools and techniques. If regarded as a panacea against attackers or relied upon as the sole defense, it is sure to cause the administrator headaches when a compromise occurs. A root process can escape a chroot environment, but this fact shouldn t lead you to unilaterally dismiss the command.

Remember that chroot environments only restrict access to the file system. This is an important distinction from restricting access to a process. One of prerequisites to running a service with chroot is that it is not a root-owned process. chroot tells the process only what it can access, not what types of processes it can spawn or ”if it is root ”how to escape the chroot directory. A detailed description of breaking chroot can be found at http://www.bpfh.net/simes/computing/chroot-break.html. A more detailed perspective can be found in The Shellcoder s Handbook (John Wiley & Sons), which has a two-line method of breaking chroot by a root process.

Yet just because chroot is not impenetrable does not mean it should be dismissed. This falls into a policy decision and careful consideration of the gains brought by implementing chroot versus the potential attacks that can still occur.

Automated hacks such as Internet worms will always be significantly impeded by chroot environments. These types of attacks rely on default configurations, known file locations, and the presence of specific files. A chroot environment will very often lack many of the resources exploited by the more dangerous aspects of a worm. Thus, even if a buffer overflow compromises an Apache, DNS, or SSH daemon, the worm s secondary attacks may be stopped . It is unlikely that the automated attack will include steps to identify and break out of a chroot environment.

Attacks that are manually executed pose more risk. If the service can be initially compromised (either by a buffer overflow or stolen user credentials), then the attacker will be limited to the chroot environment only until there is a desire to try and break out of the chroot . In some cases, the attacker may not be aware of chroot (thoroughly possible in the land of script kiddies) and leave the system because it does not offer any enticing items. More capable attackers may attempt to break the chroot , but the time spent on the machine in order to identify chroot and attack the system increases the chances that network or system monitoring will alert administrators to the attack.