Re: chroot bind?
Note: I'm not subscribed to -devel at the moment, and probably not for a
while since its unlikely I have time to read the volume. Please CC:
Ethan Benson <erbenson@alaska.net> mentioned:
> you have to have at least named-xfer.
Of course, but.
> yes there is.
Only named-xfer.
> the way i do it is the initscript replaces the binaries in the chroot
> jail before starting them, this way the mainline bind package can
> get upgraded to fix a security hole and the chroot is upgraded
> automatically. the binaries in the chroot jail are only writable by
> root, and of course named does not run as root. (chrooted named
> running as root is completely pointless).
See I disagree here, I think whatever the case less binaries should
be in a chroot rather than more.
Why depend on a known potential problem (chrooting binary in its own
chroot enviroment) when you can just have it outside. Of course this
risk is quite small I'd say, but better safe than sorry.
In fact named-xfer only gets updated when bind gets updated, so there is
only a need to copy it across when that happens. Of course just a
matter of figuring out how to do that.
> it certainly would be useful to have some standard setup for this kind
> of thing.
Might be nice to have it as the default for bind. ;)
Yotam Rubin <yotam@makif.omer.k12.il> wrote:
> I disagree. A lot of the vulnerability scanners out there determine whether
> a host is susceptible to a certain bug by looking at its version.bind record
I agree here, but this might be a better way of de-versioning bind.
// Don't reveal BIND version
version "";
As for debug, this should be sufficent for any local admin. (From
/var/log/daemon)
Apr 23 10:30:42 woodcut named[18186]: starting (/etc/bind/named.conf). named 8.2.3-REL-NOESW Sat Jan 27 01:46:37 MST 2001 ^Ibdale@winfree:/home/bdale/debian/bind-8.2.3/src/bin/named
Which brings up an interesting point. Doesn't seem to be provision in
secure-bind for syslog.
In fact a quick test of the binary deb should its not loggin properly.
I guess there might be two ways to fixing this:
i) get secure-bind to log to syslog via a network socket.
ii) install /dev/log in /var/secure-bind/dev/log and get syslogd to add
the following flag: '-a /var/secure-bind/dev/log'.
Which leds to a futher question, is there a generic mechanism in
debian's default syslog (sysklogd) to tell it to listen on other
log devices?
Nicholas
Reply to: