Security issue
David Forrest
drf at maplepark.com
Wed Oct 29 17:59:54 UTC 2008
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
More information about the bind-users
mailing list