Apache chrooting made simple

Please note that this feature is still experimental. Make sure it works as you expect if you intend to use it in production.

Standard approach

Starting with v1.6 mod_security includes support for Apache chrooting. Chrooting is a process of confining an application into a special part of the file system, sometimes called the "jail". Once the chroot call is performed, the application can no longer access what lies outside the jail. Only the root user can escape the jail, and a vital part of the chrooting process is not allowing anything root related (root processes or suid root binaries) inside the jail. The idea is that if an attacker manages to break in through the web server he won't have much to do because he, too, will be in jail, with no means to escape.

Applications do not have to support chrooting. Any application can be chrooted using the chroot binary. The following line:

chroot /chroot/apache /usr/local/web/bin/apachectl start

will start Apache but only after replacing the file system with what lies beneath /chroot/apache.

Unfortunately, things are not as simple as this. The problem is that applications typically require shared libraries, various files, and other binaries to function properly. So, to make them function you must make copies of required files and make them available inside the jail. This is no easy task (take a look at http://penguin.epfl.ch/chroot.html for detailed instructions on how to chroot an Apache web server).

The mod_security way

While I was chrooting an Apache the other day I realised that I was bored with the process and I started looking for ways to simplify it. As a result, I built the chrooting functionality into the mod_security module itself, making the whole process less complicated. With mod_security under your belt, you only need to add one line to the configuration file:

SecChrootDir /chroot/apache

and your web server will be chrooted successfully.

Apart from simplicity, mod_security chrooting brings another significant advantage. Unlike external chrooting (mentioned previously) mod_security chrooting requires no additional files to exist in jail. The chroot call is made after web server initialisation but before forking. Because of this, all shared libraries are already loaded, all web server modules are initialised, and log files are opened. You only need your data in jail.

There are some cases, however, when you will need additional files in jail, and that is if you intend to execute CGI scripts or system binaries. They may have their own file requirements. If you fall within this category then you need to proceed with the external chroot procedure as normal but you still won't have to think of the Apache itself.

Required module ordering for chroot support

As mentioned above, the chroot call must be performed at a specific moment in Apache intialisation, only after all other modules are initialised. This means that mod_security must be first on the list of modules. To ensure that, you will probably need to make some changes to module ordering, using the following configuration directives:

ClearModuleList

AddModule mod_security.c

AddModule ...

AddModule ...
AddModule ...

The first directive clears the list. You must put mod_security next, followed by all other modules you intend to use (except http_core.c, which is always automatically added and you do not have to worry about it). You can find out the list of built-in modules by executing the httpd binary with the -l switch:

./httpd -l