From owner-freebsd-stable@FreeBSD.ORG Wed Dec 4 18:50:03 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 700614C5; Wed, 4 Dec 2013 18:50:03 +0000 (UTC) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26F9316DA; Wed, 4 Dec 2013 18:50:02 +0000 (UTC) Received: from badger.tharned.org (badger.tharned.org [10.10.10.23]) (authenticated bits=0) by roadkill.tharned.org (8.14.7/8.14.7) with ESMTP id rB4Io0UZ007296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 12:50:01 -0600 (CST) (envelope-from gcr+freebsd-stable@tharned.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tharned.org; s=2013; t=1386183001; bh=dNMK1dVonihlI2J28hk00Vv/4a8JMzksLWSRi7JRxfI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b91PSWSb0HRI/XtiVBzqE/opBNjwQaFEgAih6OIpkHg+xvWn6hr0lTa/zmGM3gU6m vFBxMId+kODRlprg+hg6nqWt9W78Y7kEfQOrgM5CBrCrMYZJlahYoclqyWvqvrKUxG Ix620G4C55VsE0a8oUOz2TSi7E+6P2c5AUib8xUI= Date: Wed, 4 Dec 2013 12:49:59 -0600 (CST) From: Greg Rivers To: Erwin Lansing Subject: Re: BIND chroot environment in 10-RELEASE...gone? In-Reply-To: <20131204095855.GY29825@droso.dk> Message-ID: References: <529D9CC5.8060709@rancid.berkeley.edu> <20131204095855.GY29825@droso.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (roadkill.tharned.org [75.145.12.185]); Wed, 04 Dec 2013 12:50:01 -0600 (CST) 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: Wed, 04 Dec 2013 18:50:03 -0000 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