managed-keys.bind's directory problem

[Doug Barton]

Chris Buxton wrote:
> On Dec 13, 2009, at 5:40 PM, Doug Barton wrote:
>> On Fri, 11 Dec 2009, Mark Andrews wrote: To repeat my primary
>> objection, if the named user can write to the configuration
>> directory it can change the contents of named.conf. That's a
>> security problem.\
> 
> So don't put named.conf inside the working directory. Put it in
> /etc, or something like that.

The actual solution I'm currently testing (and will likely commit to
-current soon) is to place the working directory "under" the
configuration directory. In FreeBSD currently the configuration is in
/etc/namedb, which is also what's listed as "directory" in named.conf.
I've added a directory /etc/namedb/working that is writable by the
bind user and is now listed as "directory" instead. By default the
named process chroots into /var/named, so /etc/namedb is actually a
symlink to /var/named/etc/namedb.

> /etc/ named.conf rndc.conf /var/named/ (working directory)

Two problems with this idea. The first is that the default
configuration has to work whether or not the user chooses the chroot
option (which is on by default). I obviously could create
/var/named/var/named, but that's just silly.

The other (and in my mind more serious) problem is that in named.conf
all unqualified paths are considered relative to the working
directory. To me that indicates that there is still a pretty strong
connection between "the configuration directory" and "the working
directory" and certainly leads to users making bad decisions about
what to put where. It also means that if I want to make a clean
separation between the two I either have to fully qualify every path
name in named.conf (not exactly rocket science of course, just
inconvenient and goes against 15 years of experience) or I have to use
funky solutions like 'file "../foo/barfile"' which is (arguably) ugly,
and definitely liable to lead to confusion.

> You are not bound to put anything into the working directory. Just
> make sure it's writable by named. However, this is a convenient
> place to put zone files, as long as you don't mind giving named
> permission to rewrite/overwrite them.

Well obviously if you're slaving zones or using dynamic updates you
have to have at least one directory somewhere that named can write to.
IMO it's also nice to have a path for master zones that the named user
cannot write to, but maybe I'm just paranoid.

> The options { directory ""; }; statement specifies named's working
> directory (its 'cwd'), not the location of the configuration
> directory.

I continue to assert that both the code and long custom say that it
specifies both, and further continue to assert that this is a mistake.
However it's clear at this point that there is no consensus that this
behavior should be changed, so I'll make the changes on my end.


Doug

-- 

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/