Re: chroot bind?
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
Reply to: