Lighttpd and chroot jails

The http web server lighttpd has the configurable option of running within a "chroot jail". This usually requires the daemon to run with root privileges (as they are needed to change the root directory "/" in order to create the jailed file space). Thus the lighttpd server runs as root within the jail. The jail may appear like a secure thing to do, but I feel this is the wrong solution to the security problem being addressed.

The most widely used approach to improve security of the web server on Unix/Linux is to run the server processes with specific user and group IDs. The default apache and lighttpd web server configurations do this. Suppose an intruder manages to coerce the web server to spawn a malicious program (e.g. a script), then this program, like the server, only has the privileges of this user ID. This means the program can likely read all the web files, use the network interface, and (on many standard Linux installations) read much of the filesystem and run many non-privileged programs. However, it most likely cannot read important system configuration files, system logs, nor write anywhere except selected parts of the web file space.

A chroot jail isolates a process or running program from parts of the filesystem. It does this by changing the filesystem root directory for the program before it is started (see the man page for chroot). For example, suppose the directory containing the files that compose the web space is /var/jail/www then a web server running with the root file system set to /var/jail/ would see the web space directory at /www. It would have no knowledge of the file system outside its confined jail. [Note, I have glossed over a lot of configuration changes and set up to actually get a jail working]. Suppose an intruder manages to coerce the web server to spawn a malicious program then this program, like the server, only sees a file system consisting of the web space and executable and libraries the web server may need.

These two solutions offer different types of security. Servers running with a special user ID may allow a malicious program to see much of the filesystem, but it has to escalate to a privileged user ID to do real damage (on a well configured system at least). Servers running as root (a privileged user) within a chroot jail allows a malicious program to run with a privileged user ID, but it has to escape the jail to access the system. If it can escape the jail, it has access to the entire file system as a privileged user! Ideally we want the best of both worlds; to run the web server with a restricted user ID and with restricted access to the filesystem.

Although a jail could be set up to do this (with a little scripting and reconfiguring), a better approach would be to use a Mandatory Access Control (MAC) system. An example implementation of MAC is SElinux.