BIND chroot environment in 10-RELEASE...gone?

[Erwin Lansing]

On Wed, Dec 04, 2013 at 12:49:59PM -0600, Greg Rivers wrote:
> 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.  :-)
> 

Thanks Greg, and thanks for the feedback.  I did make sure that the
chroot still is supported on existing 8 and 9 systems, so the move will
be another part in the upgrade procedure to a new major release and
lessen the pain a bit.  Let me have another look into reintroducing the
chroot bits in a less complicated way.  It may not be exactly the same
as before but hopefully can be done in a backwards compatible way.

Erwin
-- 
Erwin Lansing                       (o_ _o)        http://droso.dk
                                 \\\_\   /_///
erwin at lansing.dk                 <____) (____>