Re: managed-keys.bind's directory problem
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.
/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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
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/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
fujiw...@wide.ad.jp wrote: 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=revisionrevision=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. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
On Dec 14, 2009, at 6:28 PM, Doug Barton wrote:
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.
Chris Buxton
Professional Services
Men Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
On Fri, 11 Dec 2009, Mark Andrews wrote: In message 20091210.162242.460114267490885968.fujiw...@pyon.org, fujiw...@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/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
In message alpine.bsf.2.00.0912131720060.1...@qbhto.arg, Doug Barton writes: On Fri, 11 Dec 2009, Mark Andrews wrote: In message 20091210.162242.460114267490885968.fujiw...@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/ -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
In message 20091210.162242.460114267490885968.fujiw...@pyon.org, fujiw...@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-users@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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: managed-keys.bind's directory problem
From: Mark Andrews ma...@isc.org In message 20091210.162242.460114267490885968.fujiw...@pyon.org, fujiw...@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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
