On Sun, Apr 22, 2001 at 04:54:42PM -0800, Ethan Benson wrote: > > 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.
No, only named-xfer. With ndc you just go say: /usr/sbin/ncd -c /var/named/var/run/ndc > so long as your chroot jail isn't setup wrong (ie chown -R > named.named) i don't really see any risk here. Maybe, but if there is no need for binaries to be in the chroot, why put them there. > 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. Hmm, I agree with you. The only point I could make is that in a caching/forwarder situation with dynamical interfaces doesn't sound much like a server. Given that 127.0.0.1 seems like the only useful and secure interface for a machine in that situation. > 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. Yeah thats why I asked if there was a generic mechanism. One package is not allow to touch another packages files. > > it already does. True, but its not the default and the local syslog might not even be listening. > > 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" Yeah, but is secure-bind (or bind-chroot) allowed to reach and change this variable? Plus can it be sure that sysklogd doesn't reach out and change it? > 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. I'd have to agree here. Nicholas