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

[Greg Rivers]

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