Chroot-BIND HOWTO
Scott Wunsch, scott at wunsch.org>
-v1.3, 24 February 2001
+v1.4, 1 July 2001
-This document describes installing the BIND 8 nameserver to run in a chroot
+This document describes installing the BIND 9 nameserver to run in a chroot
jail and as a non-root user, to provide added security and minimise the
-potential effects of a security compromise.
+potential effects of a security compromise. Note that this document has
+been updated for BIND 9; if you still run BIND 8, you want the Chroot-BIND8
+HOWTO instead.
@@ -21,19 +23,19 @@ potential effects of a security compromise.
Introduction
-This is the Chroot-BIND HOWTO; see for the master
-site, which contains the latest copy. It is assumed that you already know how
-to configure and use BIND (the Berkeley Internet Name Domain). If not, I would
-recommend that you read the DNS HOWTO first. It is also assumed that you have
-a basic familiarity with compiling and installing software on your UNIX-like
-system.
+This is the Chroot-BIND HOWTO; see for the
+master site, which contains the latest copy. It is assumed that you already
+know how to configure and use BIND (the Berkeley Internet Name Domain). If
+not, I would recommend that you read the DNS HOWTO first. It is also assumed
+that you have a basic familiarity with compiling and installing software on
+your UNIX-like system.
What?
This document describes some extra security precautions that you can take when
you install BIND. It explains how to configure BIND so that it resides in a
-``chroot jail'', meaning that it cannot see or access files outside its own
+``chroot jail,'' meaning that it cannot see or access files outside its own
little directory tree. We shall also configure it to run as a non-root user.
The idea behind chroot is fairly simple. When you run BIND (or any other
@@ -42,7 +44,14 @@ filesystem outside the jail. For example, in this document, we'll set BIND up
to run chrooted to the directory /chroot/named>. Well, to BIND, the
contents of this directory will appear to be />, the root directory.
Nothing outside this directory will be accessible to it. You've probably
-encounted a chroot jail before, if you've ever ftped into a public system.
+encounted a chroot jail before, if you've ever used ftp> to log into a
+public system.
+
+Because the chroot process is much simpler with BIND 9, I have started to expand
+this document slightly, to include more general tips about securing a BIND
+installation. Nevertheless, this document is not (and is not intended to be) a
+complete reference for securing BIND. If you do only what is outlined in this
+document, you're not finished securing your nameserver!
Why?
@@ -52,7 +61,8 @@ any malicious individual could gain by exploiting vulnerabilities in BIND. It
is for the same reason that we run BIND as a non-root user.
This should be considered as a supplement to the normal security precautions
-(running the latest version, using access control, etc.), not a replacement for
+(running the latest version, using access control, etc.), certainly not as a
+replacement for
them.
If you're interested in DNS security, you might also be interested in a few
@@ -71,18 +81,21 @@ The latest version of this document is always available from the web site of the
Linux/Open Source Users of Regina, Sask., at .
+There is now a Japanese translation of this document, maintained by Nakano
+Takeo nakano at apm.seikei.ac.jp>. This is available at .
+
BIND is available from at . As of this
-writing, the current version of BIND8 is 8.2.3. BIND 9.x has now been
-released, but I haven't had time to look at it in depth yet, so I don't know
-how much of this document will be applicable. Some administrators are now
-putting BIND9 into production use, but it still requires a taste for living on
-the bleeding edge (and upgrading every couple weeks), so you may be better off
-staying with BIND8 for now.
+writing, the current version of BIND 9 is 9.1.2. BIND 9 has been out for some
+time now, and many people are using it in production. Nevertheless, if you
+are the conservative sort, you may prefer to remain with BIND 8. If this is
+the case, please see my Chroot-BIND8 HOWTO (available from the same loation)
+for details on chrooting it. Be warned that BIND 8 is much messier to chroot
+though.
-Keep in mind that there are known> security holes in all
-versions of BIND8 less than 8.2.3>, so make very sure that you're
-running the latest version!
+Keep in mind that there are known> security holes in many earlier
+versions of BIND, so make very sure that you're running the latest version!
How?
@@ -103,7 +116,7 @@ this.
Disclaimer
-These steps worked for me, on my system. Your mileage may vary. This is but
+These steps worked for me, on my system; your mileage may vary. This is but
one way to approach this; there are other ways to set the same thing up
(although the general approach will be the same). It just happens that this
was the first way that I tried that worked, so I wrote it down.
@@ -113,6 +126,10 @@ of the instructions in this document should be easily applicable to other
flavours of UNIX as well, and I shall try to point out differences of which I am
aware.
+If you run Linux, you need to make sure that you're running a 2.4 kernel before
+attempting this. The -u> switch (to run as a non-root user) requires
+this newer kernel.
+
Preparing the Jail
Creating a User
@@ -149,11 +166,10 @@ structure:
/chroot
+-- named
- +-- bin
+-- dev
+-- etc
| +-- namedb
- +-- lib
+ | +-- slave
+-- var
+-- run
@@ -172,16 +188,20 @@ and the zone files can go in /chroot/named/etc/namedb>. For example:
# cp -a /var/named/* /chroot/named/etc/namedb/
-BIND will likely need to write to the namedb> directory, and probably some
-of the files in it. For example, if your DNS serves as a slave for a zone, it
-will have to update that zone file. Also, BIND can dump statistical
-information, and does so in this directory. For that reason, you should
-probably make the named> user the owner of this directory and its contents:
+BIND would normally need to write to the namedb> directory, but in the
+interests of tightening security, we will not allow it to do this. If your
+nameserver serves as a slave for any zones, it will need to update these zone
+files, which means we'll have to store them in a separate directory, to which
+BIND does have write access.
-# chown -R named:named /chroot/named/etc/namedb
+# chown -R named:named /chroot/named/etc/namedb/slave
+
+Keep in mind that'll you have to move any slave zones you have into this
+directory, and update your named.conf> accordingly.
+
BIND will also need to write to the /var/run> directory, to put its
-pidfile and ndc socket there, so let's allow it to do so:
+pidfile and statistical information there, so let's allow it to do so:
# chown named:named /chroot/named/var/run
@@ -190,50 +210,27 @@ pidfile and ndc socket there, so let's allow it to do so:
Once BIND is running in the chroot jail, it will not be able to access files
-outside the jail at all>. However, it needs to access a few key files, such
-as the system's C library. Exactly what libraries are required will depend on
-your flavour of UNIX. For most modern Linux systems, the following commands
-will be sufficient to put the necessary libraries in place:
-
-# cd /chroot/named/lib
-# cp -p /lib/libc-2.*.so .
-# ln -s libc-2.*.so libc.so.6
-# cp -p /lib/ld-2.*.so .
-# ln -s ld-2.*.so ld-linux.so.2
-
-As an alternative, you could simply build statically-linked versions of the BIND
-binaries to put in your chroot jail. You should also copy ldconfig> into
-the jail, and run it to create an etc/ld.so.cache> for the jail environment.
-The following commands could take care of this:
-
-# cp /sbin/ldconfig /chroot/named/bin/
-# chroot /chroot/named /bin/ldconfig -v
-
+outside the jail at all>. However, it needs to access a few key files,
+although not nearly as many as BIND 8 did.
-BIND needs one more system file in its jail: good ol' /dev/null>. Again,
-the exact command necessary to create this device node may vary from system to
-system; check your /dev/MAKEDEV> script to be sure. Some systems may also
-require /dev/zero>. For most Linux systems, we can use the following
-command:
+One file that BIND will need inside its jail is good ol' /dev/null>.
+Note that the exact command necessary to create this device node may vary from
+system to system; check your /dev/MAKEDEV> script to be sure. Some
+systems may also require /dev/zero>, which can created similarly. For
+most Linux systems, we can use the following command:
# mknod /chroot/named/dev/null c 1 3
-Finally, you need a couple extra files in the /etc> directory inside the
-jail. In particular, you must copy /etc/localtime> (this sometimes known
-as /usr/lib/zoneinfo/localtime> on some systems) in there so that BIND
-logs things with the right time on them, and you must make a simple group>
-file with the named> group in it. The following two commands will take
-care of this:
+You also need another file in the /etc> directory inside the jail. You
+must copy /etc/localtime> (this is sometimes known as
+/usr/lib/zoneinfo/localtime> on some systems) in there so that BIND logs
+things with the right time on them. The following command will take care
+of this:
# cp /etc/localtime /chroot/named/etc/
-
-# echo 'named:x:200:' > /chroot/named/etc/group
-Keep in mind that the GID, 200 in this example, must match the one you defined
-in the real /etc/group> above.
-
Logging