managed-keys.bind's directory problem
fuji...@wide.ad.jp
The named tried to write "managed-keys.bind" file into the named's
working directory.
The current BIND 9 requires the working directory is writable by named
(From ARM). But I think the working directory should not be writable
by named and some OSs' default configuration set the working directory
not writable.
It is usable to avoid named's unknown BUG which may break the working
directory.
For example, FreeBSD changes the working directory's
owner/group/permission configured by /etc/mtree/BIND.chroot.dist and
it sets the working directory not writable by named.
I changed /etc/mtree/BIND.chroot.dist in my FreeBSD box, but I don't
like this solution.
I'm very happy if I can change the managed-keys.bind path.
------------------------------------------------------------------------------
>From BIND 9.7.0b3 ARM:
In the current implementation, the managed keys database is stored
as a master-format zone file called managed-keys.bind. When the key
database is changed, the zone is updated. As with any other dynamic
zone, changes will be written into a journal file,
managed-keys.bind.jnl. They are committed to the master file as soon
as possible afterward; in the case of the managed key database, this
will usually occur within 30 seconds. So, whenever named is using
automatic key maintenace, those two files can be expected to exist
in the working directory. (For this reason among others, the working
directory should be always be writable by named.)
If the dnssec-lookaside option is set to auto, named will
automatically initialize a managed key for the zone dlv.isc.org. The
key that is used to initialize the key maintenance process is built
into named, and can be overridden from bindkeys-file.
---------------------------------------------------------------------------
--
Kazunori Fujiwara, JPRS
Mark Andrews
In message <20091210.162242.46011...@pyon.org>, fujiwara@wid
e.ad.jp writes:
> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
>
> The named tried to write "managed-keys.bind" file into the named's
> working directory.
>
> The current BIND 9 requires the working directory is writable by named
> (From ARM). But I think the working directory should not be writable
> by named and some OSs' default configuration set the working directory
> not writable.
Then those OS's are misconfiguring named. This has been a requirement
since the BIND 4 days. It's just named has not complained and there
has been loss of functionality as a result. On some OS's this is the
only way to get a core file for debugging as there is no way to specify
anything other than the current working directory.
Note there is no requirement for named's config files to be below the
working directory.
../master-files/ or /master-files/ or /var/named/master-files could
all be used instead of ./master-files
The working directory does not have to be /var/named.
> It is usable to avoid named's unknown BUG which may break the working
> directory.
>
> For example, FreeBSD changes the working directory's
> owner/group/permission configured by /etc/mtree/BIND.chroot.dist and
> it sets the working directory not writable by named.
>
> I changed /etc/mtree/BIND.chroot.dist in my FreeBSD box, but I don't
> like this solution.
>
> I'm very happy if I can change the managed-keys.bind path.
We will look into that.
> -----------------------------------------------------------------------------
> -
> >From BIND 9.7.0b3 ARM:
>
> In the current implementation, the managed keys database is stored
> as a master-format zone file called managed-keys.bind. When the key
> database is changed, the zone is updated. As with any other dynamic
> zone, changes will be written into a journal file,
> managed-keys.bind.jnl. They are committed to the master file as soon
> as possible afterward; in the case of the managed key database, this
> will usually occur within 30 seconds. So, whenever named is using
> automatic key maintenace, those two files can be expected to exist
> in the working directory. (For this reason among others, the working
> directory should be always be writable by named.)
>
> If the dnssec-lookaside option is set to auto, named will
> automatically initialize a managed key for the zone dlv.isc.org. The
> key that is used to initialize the key maintenance process is built
> into named, and can be overridden from bindkeys-file.
>
> ---------------------------------------------------------------------------
>
> --
> Kazunori Fujiwara, JPRS
>
> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
fuji...@wide.ad.jp
> In message <20091210.162242.46011...@pyon.org>, fujiwara@wid
> e.ad.jp writes:
>> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
>>
>> The named tried to write "managed-keys.bind" file into the named's
>> working directory.
>>
>> The current BIND 9 requires the working directory is writable by named
>> (From ARM). But I think the working directory should not be writable
>> by named and some OSs' default configuration set the working directory
>> not writable.
>
> Then those OS's are misconfiguring named. This has been a requirement
> since the BIND 4 days. It's just named has not complained and there
> has been loss of functionality as a result. On some OS's this is the
> only way to get a core file for debugging as there is no way to specify
> anything other than the current working directory.
>
> Note there is no requirement for named's config files to be below the
> working directory.
>
> ../master-files/ or /master-files/ or /var/named/master-files could
> all be used instead of ./master-files
>
> The working directory does not have to be /var/named.
Thank you. I understand where I misunderstood.
Now, I changed the work directory as "/etc/namedb/var" and prepended "../"
to all relative path on my FreeBSD Box.
(and added " var uname=bind" into /etc/mtree/BIND.chroot.dist.)
It works well.
>> I'm very happy if I can change the managed-keys.bind path.
>
> We will look into that.
Regards,
--
Kazunori Fujiwara, JPRS
Doug Barton
> In message <20091210.162242.46011...@pyon.org>, fujiwara@wid
> e.ad.jp writes:
>> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
>>
>> The named tried to write "managed-keys.bind" file into the named's
>> working directory.
>>
>> The current BIND 9 requires the working directory is writable by named
>> (From ARM). But I think the working directory should not be writable
>> by named and some OSs' default configuration set the working directory
>> not writable.
>
> Then those OS's are misconfiguring named.
Or, named is acting in an unsafe way. :) For example, see
https://lists.isc.org/pipermail/bind-users/2008-August/071912.html for my
proposal to separate the idea of "working directory" from "configuration
directory," and some of the reasons why.
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.
> This has been a requirement since the BIND 4 days. It's just named has
> not complained
Actually it does complain:
named[970]: the working directory is not writable
> and there has been loss of functionality as a result.
I would argue that this really hasn't been the case for FreeBSD, up till
this point there has been a workaround for all of the functionality that
users have asked for.
> On some OS's this is the only way to get a core file for debugging as
> there is no way to specify anything other than the current working
> directory.
Once again, I assert that this is a design flaw in named. Processes should
not be dumping random stuff into the same directory where their
configuration files go. It may have been acceptable back in the BIND 4
days, but it's time to move on.
> Note there is no requirement for named's config files to be below the
> working directory.
This is something that I'll explore. I still prefer the solution to
separate the idea of config and working directories. Imagine a scenario
where the configuration stuff is on a read-only partition for example.
> The working directory does not have to be /var/named.
In FreeBSD (as in other OSs that I looked at for examples) that's the root
of the chroot directory structure.
>> I'm very happy if I can change the managed-keys.bind path.
>
> We will look into that.
That would be good. I would argue that for any new feature configurability
for its file location(s) should be a requirement.
Doug
--
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
Mark Andrews
In message <alpine.BSF.2.00.0...@qbhto.arg>, Doug Barton writes:
> On Fri, 11 Dec 2009, Mark Andrews wrote:
> > In message <20091210.162242.46011...@pyon.org>, fujiwara
> @wid
> > e.ad.jp writes:
> >> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
> >>
> >> The named tried to write "managed-keys.bind" file into the named's
> >> working directory.
> >>
> >> The current BIND 9 requires the working directory is writable by named
> >> (From ARM). But I think the working directory should not be writable
> >> by named and some OSs' default configuration set the working directory
> >> not writable.
> >
> > Then those OS's are misconfiguring named.
>
> Or, named is acting in an unsafe way. :) For example, see
> https://lists.isc.org/pipermail/bind-users/2008-August/071912.html for my
> proposal to separate the idea of "working directory" from "configuration
> directory," and some of the reasons why.
>
> 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.
"directory" has *always* specified the working directory.
> > This has been a requirement since the BIND 4 days. It's just named has
> > not complained
>
> Actually it does complain:
> named[970]: the working directory is not writable
>
> > and there has been loss of functionality as a result.
>
> I would argue that this really hasn't been the case for FreeBSD, up till
> this point there has been a workaround for all of the functionality that
> users have asked for.
>
> > On some OS's this is the only way to get a core file for debugging as
> > there is no way to specify anything other than the current working
> > directory.
>
> Once again, I assert that this is a design flaw in named. Processes should
> not be dumping random stuff into the same directory where their
> configuration files go. It may have been acceptable back in the BIND 4
> days, but it's time to move on.
>
> > Note there is no requirement for named's config files to be below the
> > working directory.
>
> This is something that I'll explore. I still prefer the solution to
> separate the idea of config and working directories. Imagine a scenario
> where the configuration stuff is on a read-only partition for example.
Or OS maintainers shouldn't have put configuration files in the
working directory. They were originally seperate. OS maintainers
could have kept them seperate.
> > The working directory does not have to be /var/named.
>
> In FreeBSD (as in other OSs that I looked at for examples) that's the root
> of the chroot directory structure.
>
> >> I'm very happy if I can change the managed-keys.bind path.
> >
> > We will look into that.
>
> That would be good. I would argue that for any new feature configurability
> for its file location(s) should be a requirement.
>
>
> Doug
>
> --
>
> Improve the effectiveness of your Internet presence with
> a domain name makeover! http://SupersetSolutions.com/
>
Chris Buxton
> On Fri, 11 Dec 2009, Mark Andrews wrote:
So don't put named.conf inside the working directory. Put it in /etc, or something like that.
/etc/
named.conf
rndc.conf
/var/named/
(working directory)
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.
Of course, the paths above can be prefixed with a chroot directory path.
>> On some OS's this is the only way to get a core file for debugging as there is no way to specify anything other than the current working directory.
>
> Once again, I assert that this is a design flaw in named. Processes should not be dumping random stuff into the same directory where their configuration files go. It may have been acceptable back in the BIND 4 days, but it's time to move on.
Yes, it's time for you to move on. Don't put anything that should not be writable in or under the working directory. Start using absolute paths instead of just filenames.
The options { directory ""; }; statement specifies named's working directory (its 'cwd'), not the location of the configuration directory.
Chris Buxton
Professional Services
Men & Mice
Doug Barton
> 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 Barton
> I'm using BIND 9.7.0b3 an DLV (dns-lookaside auto;).
FYI I recently committed the port for 9.7.0rc1. Hopefully this will
make it easier for you to continue testing. Please try the port and
let me know if you have any problems with it.
> The named tried to write "managed-keys.bind" file into the named's
> working directory.
I just committed the update I described in my previous message. If
you're not running -current and you'd like to experiment with it you
can grab the files from
http://svn.freebsd.org/viewvc/base?view=revision&revision=200563. Put
the BIND.chroot.dist file in /etc/mtree and the new named.conf file in
/etc/namedb/. What I suggest to users (and do myself) is that they use
the default named.conf file and include customizations via the
"include" directive. That way you can easily pick up changes when the
default is updated. If you choose not to do that, no problem, the 2
key changes are 'directory "/etc/namedb/working";' and the need to
fully qualify all file and path names in named.conf.
Once your files are updated you can do '/etc/rc.d/named restart' and
the new working directory will be created for you with proper
permissions (assuming you don't have any of the chroot options
disabled in rc.conf).
I tested this configuration several different ways, including the use
of 'dnssec-lookaside auto;' and it worked fine. The managed-keys.bind
file was created and used as expected in /etc/namedb/working.
If you have any questions or problems please let me know. I will MFC
this change before the 7.3-RELEASE, but I will likely give it some
time to settle in -current before I do.
Thanks for bringing this issue to our attention.
Chris Buxton
> Chris Buxton wrote:
>
>> 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.
Long custom on FreeBSD might say that, but the example I gave of putting config files in /etc and zone files in /var/named is actually quite well established. That has generally been the default setup that I've seen on Linux, Solaris, and Mac OS X, going back to the mid-90's.
Things have gotten more complicated recently as chroot jails become more common, and as security becomes more of a concern. Debian Linux (and Ubuntu by inheritance), for example, specifically suggests putting nothing but slave/stub zone files into the working directory, /var/cache/bind. Master zone data (and any other data that must be writable by named) is intended to go into /var/lib/bind, while config data (including default zone data) goes into /etc/bind. The documentation makes specific mention of using full paths as needed.
I can't speak to what the code says. I'm not fluent at reading source code.