DOCUMENT UNDER PREPARATION
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
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
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).
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.
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
no OS specific files are needed.
However, several named files and directories are needed:
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.
- 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.
- (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.
- is needed to allow logging after the cycling of the syslog files(!).
On Linux 2.4.0 and later,
--bind /dev/log /new/path/dev/log' will make
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.
This is the system I use.
It requires no OS specific files,
but does try to use
(presumably to generate random numbers, but uses some other source if absent)
/etc/localtime so datestamps may be in UTC.
It does require compilation with `
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
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.
- ... systems1
- 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
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.