From owner-freebsd-stable@FreeBSD.ORG Thu Dec 5 08:30:47 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A35D612 for ; Thu, 5 Dec 2013 08:30:47 +0000 (UTC) Received: from mail.droso.net (koala.droso.dk [IPv6:2a01:4f8:a0:7163::2]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0657178B for ; Thu, 5 Dec 2013 08:30:46 +0000 (UTC) Received: by mail.droso.net (Postfix, from userid 1001) id 47C1BA190; Thu, 5 Dec 2013 09:30:44 +0100 (CET) Date: Thu, 5 Dec 2013 09:30:44 +0100 From: Erwin Lansing To: Greg Rivers Subject: Re: BIND chroot environment in 10-RELEASE...gone? Message-ID: <20131205083044.GN29825@droso.dk> References: <529D9CC5.8060709@rancid.berkeley.edu> <20131204095855.GY29825@droso.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/amd64 9.1-RELEASE User-Agent: Mutt/1.5.21 (2010-09-15) Cc: stable@freebsd.org, Michael Sinatra 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: Thu, 05 Dec 2013 08:30:47 -0000 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@lansing.dk <____) (____>