On Wed, 29 Oct 2008, Justin T Pryzby wrote: > On Wed, Oct 29, 2008 at 08:58:32AM -0500, David Forrest wrote: >> I am running a small system with dynamic dhcpd updates to bind for local >> hosts and encountered the following error when trying to hide my update >> keys: >> >> Oct 29 08:36:17 maplepark named[14767]: starting BIND 9.5.0-P2 -u named >> Oct 29 08:36:17 maplepark named[14767]: found 1 CPU, using 1 worker thread >> Oct 29 08:36:17 maplepark named[14767]: loading configuration from >> '/etc/named.conf' >> Oct 29 08:36:17 maplepark named[14767]: /etc/named.conf:14: open: >> /etc/update-keys: permission denied >> Oct 29 08:36:17 maplepark named[14767]: loading configuration: permission >> denied >> Oct 29 08:36:17 maplepark named[14767]: exiting (due to fatal error) >> >> In order to correct the error, I made /etc/update-keys owned by named, but >> am concerned that a breach of bind would allow an intruder to read the >> secrets from the keyfile. This kind of defeats a reason for running >> bind as user named. As I only update my "internal" view, is this a valid >> concern as my "external" view only has pubic dns information and is not >> dynamically updated?
> Hi David, > > Does update-keys just include a single key? Yes > How does named.conf reference it, by "include" statement? Yes > How does dhcpd get the key? include "/etc/update-keys"; > Is the key only used for interaction between bind and dhcp? Yes > Are your dynamic updates only accepted for a dedicated zone > (.dhcp.example.com)? Yes (and only only within view internal) > I suggest to have one copy of the key root:named, and a 2nd copy > root:dhcp, both mode 00640. Alternately use a single copy with group > "dnsdhcp", of which users bind and dhcp are the only members. > Justin Hi Justin, thanks for responding, Currently /etc/update-keys has mode 600, which, because dhcpd runs as root appears to do the same as using a common group. I am just considering what havoc could result from a hacked named by allowing the rogue user named to read the secret and poison an internal view zone file. I do not use nsupdate on my external view zones as they haven't changed in years and I can put up with the [rndc freeze; vi <zone>; rndc thaw] procedure. I'm thinking the hacker could not do much as user named with nsupdate anyway but just asking, "Is it wise?" TIA, Dave David Forrest e-mail: drf @ maplepark.com Maple Park Development Corporation http://www.maplepark.com St. Louis, Missouri