On Mon, Apr 23, 2001 at 11:07:03AM +1200, Nicholas Lee wrote: > > 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: then please add: lists debian-devel@lists.debian.org to your ~/.muttrc so your Mail-Followup-To header will be properly setup. > Ethan Benson <erbenson@alaska.net> mentioned: > > 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. fine, no disagreement here, what im pointing out is that with at least bind 8 (someone mentioned bind 9 works differently) its not open to debate, you either have bind binaries in the chroot jail or bind doesn't work. the initscript should still copy /etc/localtime over but that isn't an executable binary so its beside the point. > 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. so long as your chroot jail isn't setup wrong (ie chown -R named.named) i don't really see any risk here. > 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. well if its that big a deal compare md5sums, if they differ update it, if not leave it. since the binary is small its really not a big deal to replace it every time. > Might be nice to have it as the default for bind. ;) read the README.Debian that goes with bind, its not going to happen, its also never going to run non-root by default. i happen to disagree with that stance but the maintainer has spoken. > Which brings up an interesting point. Doesn't seem to be provision in > secure-bind for syslog. only way to do that is editing the sysklogd initscript to add the -a /var/named/dev/log switch. editing this script opens a whole new can of policy worms unfortunatly. > 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. it already does. > ii) install /dev/log in /var/secure-bind/dev/log and get syslogd to add > the following flag: '-a /var/secure-bind/dev/log'. yup, thats what you have to do, though i remember reading there are other ways to do it, i think the extra /dev/log socket is simplest. > 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? sort of: # Options for start/restart the daemons # For remote UDP logging use SYSLOGD="-r" # SYSLOGD="" change that to: SYSLOGD="-a /var/named/dev/log" as a sidenote i think this /var/secure-bind name is lame, it doesn't follow any conventions and frankly its naive to think that just because bind is chrooted and running as root that its now fully secure. more secure yes, a panacea no. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpjOOYeJezVI.pgp
Description: PGP signature