Chapter 9: Restricted Execution Environments

A strong network and system security policy implements redundant and complementary countermeasures to the threats faced by computers deployed on a network. Whether you want to consider an onion, a castle, or a domino theory as an appropriate metaphor for this strategy, the approach is a solid one that can reduce the scope of a compromise, help maintain service uptime, and enable administrators to take on a proactive security role rather than a continuous reaction to bug reports and security updates. This chapter details the steps necessary to create a restricted execution environment with the Linux chroot command. Other types of restricted environments are User Mode Linux and the BSD family s jail command. chroot is present by default on most Linux distributions, therefore we will focus on that command.

Restrict Functionality

One of the ideal ways to improve the security for a network service is to provide as little extraneous functionality to the service as possible. The definition of what is extraneous will vary. In the following example, a web server is used. Customers may need access to an e-commerce web server or employees may need access to an internal HR web application. In each case, the service itself (a web server) has a specific collection of data and scripts necessary to support its users. The service does not need access to a C++ compiler, text editor, web browser, or dozens of the dynamic libraries installed on the host operating system. A service has a level of risk associated with its current patch level and configuration. While the presence of additional tools, programs, and libraries does not affect the web server s initial risk of compromise, their presence does contribute to the level of impact should a compromise occur. Without a strong host configuration and restrictive policies, a single attack can fully compromise the host or even place other hosts on the network in danger.

A major threat to network services is the buffer overflow exploit. A successful buffer overflow typically gives the attacker root access to the entire host. Since it is impossible to protect a service from a zero-day exploit for which no patch exists, the administrator must be able to design a configuration in which a successful buffer overflow “based attack dumps the attacker into a non-root, limited privilege environment. Otherwise, the attacker will have immediate access to sensitive information (passwords, e-mail, databases, file shares) or additional attack vectors, such as turning user nobody access into root access via a local buffer overflow exploit. If you remove the password file and delete the vulnerable library used to gain root, the web server will still run normally, but the attacker will have to spend a lot more time trying to escalate privilege.

The restricted environment may or may not make your web server more resistant to a buffer overflow or other attack, but if the system is compromised, your hardening work can reduce the amount of time you need to spend containing, analyzing, and cleaning an attack. For example, if you have removed the password file, you will not have to spend time changing passwords for all servers on a network or instructing users to change their passwords. You may not have to rebuild the host from scratch. Any work that has to be done has a direct effect on the time ”and money ”that goes into managing your network.