In freebsd-questions Digest, Vol 207, Issue 18, Message: 6
On Fri, 21 Mar 2008 08:54:36 -0500
Martin McCormick <[EMAIL PROTECTED]> wrote:
> I think I fixed it but I am not sure I would have
> figured it out quickly without the help from the list.
>
> It seems that FreeBSD defaults to a chroot of bind with
> the tree owned by root. You can run bind in a sandbox as the
> documentation says and have it chroot but if you do, and heres's
> the confusion, you had better disable FreeBSD's attempt to make
> sure the /var/named tree is always owned by root which would be
> fine if named ran as root.
I'm sorry, but you seem a tad confused about how named operates in
sandbox mode. A thorough study of /etc/rc.d/named might help .. at
least, that's how I figured out how the whole chroot setup works.
As Chuck Swiger pointed out, quoted below, it's only necessary (and for
security, desirable) for the =subdirectories= of /var/named/var to be
owned bind:wheel, not /var/named, nor /var/named/etc with the exception
of a couple of directories. All this is setup (on each /etc/rc.d/named
start) by:
mtree -deU -f /etc/mtree/BIND.chroot.dist -p ${named_chrootdir}
where /etc/mtree/BIND.chroot.dist is, on my 5.5-STABLE(ish) system:
# $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.5.2.2 2004/11/11 04:08:16
gshapiro Exp $
[..]
/set type=dir uname=root gname=wheel mode=0755
.
dev mode=0555
..
etc
namedb
dynamic uname=bind
..
master
..
slave uname=bind
..
..
..
/set type=dir uname=bind gname=wheel mode=0755
var uname=root
dump
..
log
..
run
named
..
..
stats
..
..
..
> When you run it in a sandbox with a lower-priority UID,
> you must make sure that at least one more little line appears in
> rc.conf.local.
>
> named_chrootdir="" # Chroot directory (or "" not to auto-chroot it)
No, that STOPS named running in a chroot sandbox. Which is fine if you
want to run it the old (considered insecure) way; is that what you want?
> That's the key right there. If you use lines from rc.conf.local
> from an older system such as pre-FreeBSD5, you don't need that
> line and things work fine. If you don't have it on a FreeBSD5 or
> newer system,
> /etc/defaults/rc.conf supplies the default version of that line
> which reads:
>
> named_chrootdir="/var/named" # Chroot directory (or "" not to auto-chroot it)
That's right, and what you need to run it in the sandbox.
> and one is seriously messed up from there on during the booting
> process.
how 'messed up'? That's how it's supposed to work. You're supposed to
do bind configuration (/var/named/etc/namedb/named.conf etc) as root.
Ah, you might still have /etc/namedb as a directory, rather than a
symlink, if you'd done a source upgrade from 4.X to 5 or later? If so,
(save and) delete it and let /etc/rc.d/named make the symlink for you,
then move your config to /var/named/etc/namedb
> I was confused and thought this would all help me keep
> ownership of /var/named belonging to bind when, in fact, it does
> just the opposite.
The whole point of the sandbox is to keep named, running as user bind,
from messing with anything out of its chroot environment if it were to
be compromised. The actual chroot is performed in run_rc_command() in
/etc/rc.subr if you want to see the gorier details.
> Martin McCormick WB5AGZ Stillwater, OK
> Systems Engineer
> OSU Information Technology Department Network Operations Group
>
> Chuck Swiger writes:
> >/var/named is owned by root on all of my newer (5.x and later)
> >systems; I found an old 4.11 box with it owned by bind, though. If
> >you're using named chroot'ed (as recommended), it will want /var/named/
> >var/{dump/log/run/stats} writable by bind.
Yep, which is exactly what the mtree above does for you, every startup,
plus the dynamic and slave directories in (chrooted) /etc/namedb
The only problem I've struck with the chroot setup is a permission error
when trying to get debug (named.run) logging going, as named by default
wants to create the named.run file in the default directory (/etc/namedb
-> /var/named/etc/namedb) which is of course owned by root, but I'm sure
I just need to spend a bit more time with the reference manual:
http://127.0.0.1/bind9ref/Bv9ARM.html
(where /usr/local/www/data/bind9ref -> /usr/local/share/doc/bind9/arm/)
to find out how to get this log made in /var/log ie /var/named/var/log
- but I'll wait till I've upgraded to 6.3 before trying that again.
cheers, Ian
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
