Date: 30 Jan 2001 14:20:13 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Kris Kennaway <kris@obsecurity.org> Cc: security@FreeBSD.ORG Subject: BIND 8.2.3 upgrade instructions for RELENG_3 and older systems Message-ID: <xzpn1c96usy.fsf@flood.ping.uio.no> In-Reply-To: Kris Kennaway's message of "Mon, 29 Jan 2001 14:33:00 -0800" References: <20010129143300.A38419@xor.obsecurity.org>
index | next in thread | previous in thread | raw e-mail
Kris Kennaway <kris@obsecurity.org> writes:
> Okay, BIND 8.2.3 is now in 4.2-STABLE (3.5-STABLE will probably be
> updated tomorrow). Some of the cvsup mirrors may take a little while
> to receive the update though, so be warned. They should all have it in
> an hour or so.
RELENG_3 has been fixed, please follow the procedure below if you're
running 2.2.x or 3.x (tested on 3.5-STABLE, should work on 2.2.x but
no guarantees):
1) start by updating the following directories to the latest RELENG_3,
either using cvsup or using 'cvs update -Pd -rRELENG_3' if you have
access to a CVS repository.
src/contrib/bind
src/lib/libbind
src/lib/libisc
src/libexec/named-xfer
src/usr.sbin/named
src/usr.sbin/named.reload
src/usr.sbin/named.restart
src/usr.sbin/ndc
make sure you have src/contrib/bind/port/freebsd/include/port_after.h
revision 1.3.2.3 if you're running a pre-IPv6 version of FreeBSD
(2.2.x or 3.x).
2) (OPTIONAL) if you are planning to run BIND in a sandbox, apply the
following patch to src/libexec/named-xfer/Makefile:
@@ -23,4 +23,6 @@
MAN8= named-xfer.8
+NOSHARED= YES
+
.include <bsd.prog.mk>
# END OF PATCH
3) in each if the directories listed above *except src/contrib/bind*
and *in the order listed*, run the following command:
make cleandir && make obj && make depend && make && make install
4) restart your name server.
!!!WARNING!!!
If you are running BIND with particular options (e.g. to run it in
a chroot or jail) DO NOT USE 'ndc restart' UNLESS YOU ALSO PROVIDE
THOSE OPTIONS ON THE NDC COMMAND LINE - e.g. 'ndc restart -t /foo'
Assuming rc.conf has the right information (which it must have if
BIND is to start correctly after a reboot), you can use the
following script to restart BIND:
#!/bin/sh
if [ -f /etc/defaults/rc.conf ] ; then
. /etc/defaults/rc.conf
fi
if [ -n "${source_rc_confs_defined}" ] ; then
source_rc_confs
elif [ -f /etc/rc.conf ] ; then
. /etc/rc.conf
else
echo "Where's your configuration?"
exit 1
fi
killall -KILL named
${named_program:-named} ${named_flags}
# END OF SCRIPT
5) Instructions for running BIND in a chroot sandbox
a) Make sure your system has a 'bind' user like this:
bind:*:53:53::0:0:Bind Sandbox:/home/bind:/sbin/nologin
b) Make sure your system has a 'bind' group like this:
bind:*:53:
c) Pick a location for your sandbox; /home/bind is as good a
place as any.
d) Create all necessary directories
mkdir -p /home/bind/etc/namedb
mkdir -p /home/bind/usr/libexec
mkdir -p /home/bind/var/run
mkdir -p /home/bind/var/tmp
e) Copy named-xfer into the sandbox
cp /usr/libexec/named-xfer /home/bind/usr/libexec
This assumes you built a statically linked named-xfer (see
above).
f) Copy your config files etc. into /home/bind/etc/namedb. If
you like to have your master and/or slave zone files in
separate subdirectories of etc/namedb, create those; I like
to put master zones in etc/namedb/master, slave zones in
etc/namedb/slave, and dumps in etc/namedb/db.
You shouldn't need any sandbox-specific magic in your
named.conf - the stock config should be fine, though I would
recommend specifying a listen address and a query-source. The
options section for a simple config, assuming your server's
IP address is 192.168.0.1, would look like this:
options {
directory "/etc/namedb";
forwarders {
// the usual stuff - your ISP's name servers,
// those of a few other large ISPs in your country,
// or whatever you like to forward queries to
};
listen-on port 53 {
192.168.0.1;
};
query-source address 192.168.0.1 port 53;
}
You don't need to listen on 127.0.0.1; just make sure your
/etc/resolv.conf points to 192.168.0.1 instead of 127.0.0.1.
g) Fix permissions:
chown -R bind:bind /home/bind
chmod -R o-rwx /home/bind
h) Set up an extra log socket inside the sandbox so BIND can access
syslogd: add "-l /home/bind/var/run/log" to your syslogd_flags
in your /etc/rc.conf, and restart syslogds with the correct
flags, like this:
(. /etc/rc.conf ; syslogd "${syslogd_flags}")
Verify that /home/bind/var/run/log exists and is a socket after
restarting syslogd.
i) Set up a symlink to the real ndc socket so ndc will still work:
ln -fs /home/bind/var/run/ndc /var/run
You may want to do the same for the named.pid file, though
there's no real need to.
j) Add the right options to named_flags in your /etc/rc.conf - if
you followed these instructions to the letter, the right options
would be "-ubind -gbind -t/home/bind"
k) Use the restart script above to start named. Verify that it
works. If it doesn't, check /var/log/messages and fix whatever
errors it reports.
6) Instructions for running BIND in a jail sandbox
There are two possibilities here: use the jail(8) command, or patch
BIND so it can jail itself. Note that this only works on RELENG_4
and newer, since older FreeBSD versions don't have jail support.
a) using jail(8): follow the instructions in 5) above, except that
your sandbox should contain a statically linked copy of named(8)
in usr/sbin, and instead of step j) you should just set
named_program in /etc/rc.conf to the following:
"/usr/sbin/jail /home/bind ns.domain.com 192.168.0.1 /usr/sbin/bind"
you can also set named_flags to "-ubind -gbind", but in that
case you need password and group files in your sandbox's etc
directory so BIND can figure out which user and group to use.
b) patching BIND: get the BIND patch from my software page:
<URL:http://people.freebsd.org/~des/software/>;
apply the patch, and follow the instructions provided earlier in
this document for rebuilding BIND (you only need to rebuild
src/usr.sbin/named). Next, follow the instructions for running
BIND in a chroot sandbox, except that in step j) you should use
the following options:
"-ubind -gbind -hns1.domain.com -i192.168.0.1 -j/home/bind"
There is no need to place a named binary in the sandbox.
That's it, folks!
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpn1c96usy.fsf>