Chapter 7. Chroot Jails

In this chapter we will be looking at how ModSecurity can help us to create a chroot jail for Apache. A chroot jail is used to isolate a program from the rest of the file system. This is done so that if the program gets compromised (for example, if someone is able to exploit a hole in a web application to execute files with the privileges of the Apache server program) then the attacker will not be able to access the rest of the file system.

What is a chroot jail?

An attacker who is able to exploit a vulnerability in a server program running on a system will often want to gain additional privileges to get full control of the system. The initial exploit will almost always take place through one of the server processes (daemons) on a system that is exposed to the outside world—daemons such as FTP servers and HTTP servers are what an attacker has to work with if he wants to gain access to a system. The next step, once a vulnerability has been found, is to gain full control of the system.

When a process is confined to a chroot jail, the root directory of the process is set to the directory specified as the argument to the system call chroot(2). If, for example, the chroot directory is set to /chroot, then that means that if the process now requests any file under /, it is in reality accessing files located in /chroot/. Anything above /chroot/ in the directory hierarchy will not be accessible to the process.

Chroot was not originally...

A sample attack

As an example of an attack that allows privilege escalation, imagine that an attacker was able to successfully exploit a bug in an FTP server daemon that would allow him to run commands of his choice as the root user. A smart attacker who wanted to gain full interactive shell access to the system could add a second user with root privileges by executing the following:

useradd -u 0 -g 0 -G 1,2,3,4,6,10 -o -M root2

The above adds a new user named root2, and sets its user ID (uid) and group ID (gid) to 0. Since uid 0 and gid 0 are associated with the root user, this creates a second root account. If the attacker is successful in executing the command he will have a shiny new root account waiting for him. There is only one problem—the account is disabled and doesn't have a password set for it. To set a password for an account you would normally use the Linux passwd command, however this requires that the new password is input at the command line—something which the attacker doesn...

Traditional chrooting

Chrooting the Apache process can be a tedious and error-prone process. The reason for this is that once the root directory changes, Apache still expects to find all the normal supporting libraries and other required files in their regular locations. If anything is missing, Apache will not start up, or will function abnormally.

Putting Apache in a chroot jail the traditional way (without the help of ModSecurity) involves at least the following steps:

• Finding out which supporting library files Apache requires

• Creating the proper directory structure inside the jail

• Copying all needed library files to the chroot jail, making sure everything ends up in the right directory

• Making sure the Apache configuration file, module files, and any other supporting files needed are available inside the jail

• Setting up user accounts for Apache inside the jail

• Finding out which files are needed by supporting modules (such as mod_php) and putting them inside the jail

All of the above takes patience...

How ModSecurity helps jailing Apache

When we use ModSecurity to put Apache in jail, it performs a chroot() system call from within the Apache process once Apache has finished loading all its required libraries and opened handles to things such as log files. This has the advantage of allowing Apache to completely initialize and avoids having to place all of Apache's required libraries and supporting files inside the chroot directory. Also, since log files have been opened and Apache has obtained a valid handle to them, logging will take place to the log files in their normal location outside the jail.

The ModSecurity directive used to perform the chroot jailing is SecChrootDir and it takes exactly one argument—the directory to be used as the new root directory for Apache:

SecChrootDir /chroot

It's essentially that simple! There are a few more touch-ups needed, and we will look at those in the next section, but that is nothing compared to the process outlined in the previous section on the...

Using ModSecurity to create a chroot jail

To successfully be able to use SecChrootDir to jail the Apache process, we need to create the actual directory that we will confine Apache to, as well as a few more directories that Apache needs:

mkdir -p /chroot/etc/httpd/run
mkdir -p /chroot/var/run

Using the -p flag when executing mkdir ensures that sub-directories are created as needed and avoids the need to issue an mkdir call for each directory in the path. For example, the first command creates the following directories for us:

/chroot
/chroot/etc
/chroot/etc/httpd
/chroot/etc/httpd/run

Let's also change the permission of /chroot and the files and directories it contains so that the owner is the Apache user:

chown -R apache:apache /chroot

The final piece of the puzzle is to copy all the files in your web server's document root to the corresponding location under /chroot. For example, if you store your web content in /var/www, then you would need to copy this directory to /chroot/var/www:...

Verifying that the jail works

Once a process has been jailed, the chroot directory will become the new root directory for the process. In our case, /chroot becomes the new /, and we can verify that things are working as expected by attempting to access a file in the root directory and see where the retrieved file is actually located in the real file system.

Let's create two files—both called testfile, but one located in the real root directory and the other located in /chroot:

$ echo "Inside the jail" > /chroot/testfile
$ echo "Outside the jail" > /testfile

To see if we are running inside or outside the jail, we want to create a web page that will display the contents of the file /testfile. If the text "Inside the jail" is displayed, we will know Apache was successfully jailed.

Apache comes with a feature called Server Side Includes (SSI), and one of the commands that is provided by this feature has the ability to execute a command and include the output of it in the web page. The syntax...

Chroot caveats

Using SecChrootDir works great for some setups, but not for others. If your site relies heavily on third-party modules or external programs (such as PHP or Perl) then trying to jail Apache may not be worth it because of all the extra effort required to get those external applications to work correctly while in jail. If you're just hosting plain HTML files, though, and want the extra security provided by a jailed Apache process then using SecChrootDir should be a straightforward process with a minimum of complications.

Here are some additional things to look out for when using SecChrootDir:

• Restarting Apache may not work as expected. If a command such as apachectl restart or apachectl graceful does not work, try stopping and then starting Apache using two separate commands.

• Similarly, sending a SIGHUP to Apache to make it restart will not work as expected, as the required modules may not be available inside the jail and if they are, ModSecurity will be attempting to perform...

Summary

In this chapter we learned what a chroot jail is, and how it can help increase security by isolating a server process by placing it inside a "jail" confined to a specific directory. We saw an example of the kind of attack that could be used to gain access to a system once a remote hole has been found, and how a jail would have stopped the attack since the binaries required to complete the attack would not be available inside the jail.

We looked at the traditional way of putting a process in jail by using the chroot binary or the chroot() system call, and saw how ModSecurity helps simplify the process by working from within Apache to achieve the chroot functionality after Apache has initialized. Finally, we learned some caveats to watch out for when using SecChrootDir.

In the next chapter we will be looking at REMO, which is a graphical editor to create ModSecurity rules.