chroot-ed bind 9 (was: Users Want *Seamless* Solutions, Not Patchwork)

[Bill Larson]

A chroot jail provides you one, and only one, thing.  If someone were to
connect to the application, and then break out of the application, they
would have the exact same privileges to modify files in the jail as the
user that the application was running under.  Note that this implies
that named shouldn't be run as root without risking that an attacker can
obtain root access.

The security provided by a chroot jail is simply that any damage
inflicted by an attacker is limited to damage to the chroot jail itself
rather than the system as a whole.  The idea is simply to minimize the
impact that an attacker can have on a system when (not if) the
application is broken out of.  There is another advantage of providing a
very minimal chroot jail for an application.  When the application is
broken out of, if there is no other applications, i.e. any shell, that
the user can run there is less of a possibility for the attacker for
making any modifications to the system.

Specific information about running named in a chroot environment is
available at http://www.stahl.bau.tu-bs.de/~hildeb/bind/.  This
information was specifically written for running BIND-8 in a chroot jail
under HP-UX.  Although system specific information is presented, and it
does not address BIND-9, the information is extremely useful.  (Thanks
to Ralf Hildebrandt for publishing this information.  Readers of this
list should watch for his replies to posts, he has been extremely
helpful to this list.)

There is a possibility of an attacker also breaking out of a chroot
jail.  This issue is addressed at
http://www.bpfh.net/simes/computing/chroot-break.html.  There is an
implication that breaking out of a chroot jail can only occur if the
user is "root".  Again, the implication is that named should not be run
as root!

My conclusion to this is that a chroot jail cannot protect the DNS
server application itself.  Such a jail only protects the hosting system
from damage by a hostile attacker, not the application running in the
jail itself.  The protection provided by a chroot jail requires that the
running application NOT be run under the root UID, but as an
unprivileged user.  This chroot protection also requires that a
successful attacker be provided as few tools as possible under the
chroot jail.  Also, a simple mechanism to backup the files in the chroot
jail must be implemented to provide a simple mechanism to restore these
files in the event of a successful attack.  Finally, some mechanism is
necessary to identify that the application running in the chroot jail
must be monitored to identify when it is attacked such that the chroot
jail can be restored to a "pristine" environment.

Bill Larson (wllarso at swcp.com)

P.S.

This is an extremely useful thread that has developed from an originally
undesired thread.  To second a previous reply to the original thread, I
would wish that the posters on the original thread would move their
bickering to some other forum.

This list is "bind-users", or the news group is
"comp.protocols.dns.bind".  The charter of this list, as presented by
ISC (http://www.isc.org/services/public/lists/bind-lists.html), is for
the discussion of "problems you have setting up BIND, or getting it to
do what you want".  Minor discussion of alternatives to BIND is no
problem, but arguments as to "which is better" and "which is easier" is
(IMHO) not appropriate.

Simon Waters wrote:

> The server "worked", okay not a complete DNS system, but it
> proves that BIND 9.2 doesn't need much in a chroot jail to
> work. Now as to how much security it actually buys
> you.......