Date: Wed, 4 Dec 2013 12:49:59 -0600 (CST) From: Greg Rivers <gcr+freebsd-stable@tharned.org> To: Erwin Lansing <erwin@FreeBSD.org> Cc: stable@freebsd.org, Michael Sinatra <michael@rancid.berkeley.edu> Subject: Re: BIND chroot environment in 10-RELEASE...gone? Message-ID: <alpine.BSF.2.00.1312041212000.2022@badger.tharned.org> In-Reply-To: <20131204095855.GY29825@droso.dk> References: <529D9CC5.8060709@rancid.berkeley.edu> <20131204095855.GY29825@droso.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Dec 2013, Erwin Lansing wrote: > It's not as simple as you describe, trust me I tried :-) > I don't mean to second guess you, but the chroot code was working fine before it was removed. > The one point people in this thread seem to be missing is why BIND > should be treated differently than all the other DNS severs? BIND may > have a bad security reputation back from the 4 and 8 days, but do you > really think that BIND9 is so much more insecure than say NSD or Knot > that it needs special treatment in ports? Or what about Apache for that > matter? If you really think that, a chroot really isn't going to help > you much and what you really want is a jail(8). What should be done is > to create an easy to do so, but for any port, not just one single port. > I think we have all the tools available, so it is probably just a matter > of writing some good documentation to add to the porters handbook, > though to make it really easy might require some additions to the ports > framework. > It's not a matter of BIND being more or less secure than other software, it's a matter of POLA and the huge duplicated efforts required by everyone going forward to either maintain their own chroot or migrate to the non-chroot installation. I think you underestimate the utility of chroot in limiting potential damage. As far as I'm aware, chroot is still a best practice for BIND. Other OSs (e.g. CentOS/RedHat) install BIND chrooted out of the box too. You could very well be right that a new jail framework would be better, but the chroot should not be removed until such a framework is available and integrated into the port. > The way the BIND ports are now is actually in line with all the other > ports in how they start and where the configuration files are. The > chroot code was a relic of history and the slight security benefit it > may have today is far outweighed by the increased complexity and > decreased consistency with the rest of the ports tree, both from a ports > maintainance perspective and from the user perspective. I will be happy > to look into general frameworks to jail any daemon installed from ports, > but will not make exceptions to a handful of ports. > What about net/isc-dhcp42-server, for example? That port's rc script sets up a chroot for dhcpd. Should we expect that functionality to be removed next? > Hope this explains some of the reasoning for not readding chroot > support. > I'm willing to change my mind, but I haven't heard a convincing argument yet. I'd be very interested in hearing opinions from the FreeBSD Security team and ISC on this topic. I appreciate wanting a uniform policy for this, and I concede that your reasoning is not without merit, but I still don't think removing the chroot functionality is warranted given the impact it's going to have. I also appreciate your wading into this controversy in the first place by picking up these ports. :-) -- Greg Rivers
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1312041212000.2022>