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