From owner-freebsd-stable@FreeBSD.ORG Wed Dec 4 09:59:05 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 445A2FE for ; Wed, 4 Dec 2013 09:59:05 +0000 (UTC) Received: from mail.droso.net (koala.droso.dk [213.239.220.246]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 068DF12C3 for ; Wed, 4 Dec 2013 09:59:04 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id E448D6A41; Wed, 4 Dec 2013 10:58:55 +0100 (CET) Date: Wed, 4 Dec 2013 10:58:55 +0100 From: Erwin Lansing To: Michael Sinatra Subject: Re: BIND chroot environment in 10-RELEASE...gone? Message-ID: <20131204095855.GY29825@droso.dk> References: <529D9CC5.8060709@rancid.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <529D9CC5.8060709@rancid.berkeley.edu> X-Operating-System: FreeBSD/amd64 9.1-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 09:59:05 -0000 On Tue, Dec 03, 2013 at 12:56:37AM -0800, Michael Sinatra wrote: > I am aware of the fact that unbound has "replaced" BIND in the base > system, starting with 10.0-RELEASE. What surprised me was recent > commits to ports/dns/bind99 (and presumably other versions) that appears > to take away the supported chroot capabilities. OTOH, it appears that > unbound has been given these capabilities. > > I have no issues with removing BIND from base, but taking away the very > robust chroot support that FreeBSD had for BIND is something I would > oppose. I like the idea of leveling the playing field for users of > other systems, but the way things have been implemented thus far--taking > away functionality from BIND while preferring unbound--seems > counter-productive. It doesn't really level the playing field, it just > turns it the other way. > > It seems like it would be pretty easy to preserve the /etc/rc.d/named > startup script and BIND.chroot.dist from 9.x and add them to the BIND > ports, so that people who need to run a full-blown BIND installation can > "just install the port" as was advised back in 2012 when the > BIND/unbound change was first being discussed on -hackers. What are the > obstacles to doing something like this? > It's not as simple as you describe, trust me I tried :-) 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. 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. Hope this explains some of the reasoning for not readding chroot support. Cheers, Erwin -- Erwin Lansing http://droso.dk erwin@FreeBSD.org http:// www.FreeBSD.org