From owner-freebsd-security Wed Jan 31 15:16: 4 2001 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 7303637B491 for ; Wed, 31 Jan 2001 15:15:42 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id f0VNFWF22771; Wed, 31 Jan 2001 15:15:32 -0800 (PST) Date: Wed, 31 Jan 2001 15:15:31 -0800 From: Alfred Perlstein To: Matt Dillon Cc: Brian Behlendorf , Roman Shterenzon , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-01:18.bind Message-ID: <20010131151531.I26076@fw.wintelcom.net> References: <20010131140447.E26076@fw.wintelcom.net> <20010131145423.H26076@fw.wintelcom.net> <200101312305.f0VN5vJ19469@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200101312305.f0VN5vJ19469@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Jan 31, 2001 at 03:05:57PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matt Dillon [010131 15:06] wrote: > :> [yez] 2:47pm ~ > fgrep -i named_flag /etc/defaults/rc.conf > :> named_flags="" # Flags for named > :> #named_flags="-u bind -g bind" # Flags for named > : > :Since named supports a command line option for chroot as well > :as user flags (-t) it would be trivial to have it the defaultt. > : > :It's pretty much a toss-up between usability and security. > : > :I guess this is the final blow for me, and I think we should > :run bind in a sandbox at this point, I'm just worried about > :confusing newbies who wish to set it up. > : > :If anyone has a proposal on doing it by default that doesn't > :impact ease of use (or if already doesn't impact it) then I'm > :for it. > : > :What I'm worrying about specifically is ndc and other utilities > :basically are unix domain sockets not in the expected place all of > :sudden? > : > :-- > :-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] > :"I have the heart of a child; I keep it in a jar on my desk." > > Quite a few people have been using the sandbox options in the > last year without any ill effects (I was the original author of > the feature). The only issue is that you cannot HUP named (it will > not be able to rebind its sockets), you can only restart it, and > you have to supply the proper options to ndc when restarting it > (-u bind -g bind). I usually restart it anyway (I don't trust the > named HUP code). > > I think we can easily make it the default. If it breaks HUP, then not really. :) I'm not sure how bind handles restarts, but even if it exec(2)s over itself it can track the fd open for its socket and shouldn't have to rebind it. > By the way, I seem to recall someone posting some chown's/chmod's > for /etc/namedb to run it in a sandbox that were wrong. *ALL* > files in /etc/namedb except the 's/' subdirectory should be root.wheel, > modes 644. The 's/' subdirectory should be user bind, group bind, > modes 775. The only directory named needs to write to is > /etc/namedb/s (for secondaries) and /var/run (for the pid file). Makes sense, it almost makes sense to make /var/run/named.pid a symlink into /etc/named/named.pid. > Using named's chrooting option is a more drastic approach, but also > doable as a default IFF we compile named and named-xfer statically > by default. Neither this mode of operation nor the jail mode has > been widely tested. The sandbox options have been tested widely. A shell script could copy the required shared libs into the chroot tree. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message