How to Use chroot for Increased Security

Every effort has been made on the part of the NCSA HTTPd Development Team to ensure a high level of security from break-ins through HTTPd. Occasionally, however, we miss one. For this reason, the server processes which handle outside connections are setuid to another user, such as nobody, who should have no permissions on the machine. This can be set using the User directive.

For some, this might not be enough. There is something more that you can do, however. Most systems have available a command line chroot command. This command allows the system administrator (its usually restricted to the root user) to force a program to run under a subset of the file system, without allowing access from it to any other parts of the file system. This is usually how anonymous ftp is handled, and more information about running programs chroot can be gleaned from manpages and such which correspond to setting up anonymous ftp.

The general form of the command is:
chroot directory command

Where directory is the new root directory and command is the command to run under that directory.

For example:
chroot /www httpd

In this example, /www will become the new / directory, and anything not under /www will not be accessible.

There are some difficulties associated with this, however. Anything you want to server/run/etc. needs to be in /www. This also means that if HTTPd is linked with shared libraries, the shared libraries have to be available under /www. Any cgi scripts must be under /www, as well as the interpreters (sh,perl,etc) needed to run them. Any shared libraries for the cgi scripts need to be in /www. The document tree, the server root, the logfiles, the user directories (and a copy of /etc/passwd in /www/etc/passwd if you want to have /~username/ paths). You don't want to have the passwords in the /www/etc/passwd file, and you could fake a different user directory in it for /~username/ paths that is under the /www directory.

Denice Deatrich of CERN set his server up in a chroot environment. He wrote a step by step guide available here

This is a non-trivial thing to setup, and it is unlikely to be necessary.

We will provide only minimal support for setting up a chroot server, as we don't use this locally.

Example

Using the following directory tree:


/www
/www/etc
/www/docs
/www/logs
/www/conf
/www/home
/www/home/blong
/www/home/httpd
/www/cgi-bin
/www/icons
/www/lib
/www/bin

Where /www will be the new root directory.

Into /www/lib you will need to copy at least the shared c library (libc.so, libc.sa, libc.a, libc.sl, or ..., depending on the system). Other libraries may be necessary depending on the system and what other binaries you want to run.

In /www/bin, you will need copies of sh, perl, tclsh, etc. If you have any gateways such as archie, uptime, date, finger, ph, copies of these programs will also have to be in in /www/bin.

/www/docs is your document root, but in the srm.conf file, it will be set to /docs (which is the directory after the chroot command).

/www/etc might need a copy of /etc/passwd and /etc/group. Make sure there are no passwords in this file (on most systems, this is the second field of the colon separated fields). Some systems require an entry for the uid of the user HTTPd will setuid to, so that entry would be the minimum for the passwd file (and group as well). If you intend to provide /~username/ URLs, you must have a valid directory entry as well, which must be under /www but without the /www part. Here is a sample /www/etc/passwd file:


httpd:*:25:607:NCSA HTTPd Tech Support:/home/httpd:/bin/false
blong:*:524:1:Brandon Long:/home/blong:/bin/false
nobody:*:4294967294:4294967294::/:

/www/conf will contain all of the configuration files for HTTPd, and /www/cgi-bin, /www/logs, /www/icons contain what you would expect. All of the configuration parameters which point to an absolute directory must assume that /www = /

Return to tutorial overview

NCSA HTTPd Development Team / httpd@ncsa.uiuc.edu / 9-11-95