[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: