DOCUMENT UNDER PREPARATION

Introduction

This document describes experiences with running a chroot'ed BIND 9.1 named's (9.1.0rc1 to 9.1.1rc1) on a production RedHat 6.1 / Linux 2.2 external NameServer. However, some of the information may be relevant to other enviornments, and I hope users of other setups will contribute their experiences.

Information has been reported in ISC-Bugs #677, but I was asked to contribute an example. As reporting it appears not to qualify, here are some comments, etc. which may help.

Please send any corrections, comments about applicability to other envionments, etc to me as email to bc+pb at this site (cl.cam.ac.uk).

Other considerations

Before making things more secure by using chroot, there are some other things to consider.

It is reported in Section 7.2 of the ARM that chroot by itself is of limited use, as programmes can climb out, so all chroot'ed programmes should be setuid to something other than root.
For Linux 2.2 (see below), this requires named to be compiled with `--disable-threads' - this should not impact Uni-Processor systems. However, as the programme drops all prive except the ability to bind on a priv port and to ... this should not be a concern.

Required files

Contrary to Section 7.2.1 of the ARM it appears that /dev/null is not needed, but /dev/log is, at least on some Linux systems. In fact, it appears that now that named does not exec any programmes (e.g. the old named-xfer), at least until rndc allows restart, no OS specific files are needed. However, several named files and directories are needed:

etc/named.conf

Contrary to the man page for named prior to 9.1.1rc1, this is opened after the chroot. Thus it needs to be in the chroot'ed FS, and only in the chroot'ed FS.

etc/named.data/

(or wherever named.conf says the zone files are).

var/run/ (or wherever pid-file lives - OS depenent)

This is where the startup / restart / shutdown scripts expect to find the lock file, as set by pid-file in named.conf. These will need to be changed to point at the new location, or use suitably created symbolic links.

dev/log/

is needed to allow logging after the cycling of the syslog files(!).

On Linux 2.4.0 and later, `mount --bind /dev/log /new/path/dev/log' will make it visible.

On pre Linux 2.4.0 systems, a HACK is to move /dev into the chrooted environment, and then make /dev/log a symb link to the new location.

On devfs systems, it should be able to remount the devfs on the new root.

RedHat 6.1 / Linux 2.2

This is the system I use. It requires no OS specific files, but does try to use /dev/random (presumably to generate random numbers, but uses some other source if absent) and /etc/localtime so datestamps may be in UTC.

It does require compilation with `--disable-threads' as mentioned above to get round various problems with libraries and kernels. It is reported that this should have no adverse effects on any Uni-Peocessor systems ¹.

Starting named

Start named with the flag `-u $user -t $path' $user is the owner of the directory containing any secondary zone files which require to be written, and $path is the root directory to be used.

Footnotes

... systems ¹: This is all very complicated. The FAQ file says that as setuid() only operates on the current thread, bind cannot use it. It does NOT explain why every thread cannot setuid() at a suitable point.
With kernel 1.3.99-pre3 and later, it is possible setuid() before creating threads, as setuid() allows the capability to bind to reserved ports to be retained.
It also says that it already throws away man root capabilities even if it is running as root, but does not say if these include those necessary to be able to climb out of a chroot'ed environment.