Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 31 Jan 2001 15:15:31 -0800
From:      Alfred Perlstein <bright@wintelcom.net>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Brian Behlendorf <brian@collab.net>, Roman Shterenzon <roman@xpert.com>, freebsd-security@FreeBSD.ORG
Subject:   Re: FreeBSD Security Advisory: FreeBSD-SA-01:18.bind
Message-ID:  <20010131151531.I26076@fw.wintelcom.net>
In-Reply-To: <200101312305.f0VN5vJ19469@earth.backplane.com>; from dillon@earth.backplane.com on Wed, Jan 31, 2001 at 03:05:57PM -0800
References:  <20010131140447.E26076@fw.wintelcom.net> <Pine.BSF.4.31.0101311447150.729-100000@localhost> <20010131145423.H26076@fw.wintelcom.net> <200101312305.f0VN5vJ19469@earth.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010131151531.I26076>