On Wed, 29 Oct 2008, Chris Buxton wrote:

> On Oct 29, 2008, at 10:59 AM, David Forrest wrote:
>> 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 ;
>> rndc thaw] procedure. I'm thinking the hacker could not do much as user
>> named with nsupdate anyway but just asking, "Is it wise?"

> Your name server needs to be able to read the keys. Period. You can't
> avoid this, other than not using keys (not recommended).
> It's true that an attacker who broke in through the named process
> could then read the keys and perform mischief thereafter with your
> zone data. The only thing you can do to mitigate this beyond running a
> current version of named is to try to stop someone from breaking in
> through named. That means using hardening tools such as an intrusion
> prevention system (IPS), a mandatory access control system (MAC), and
> hardening compiler tools when building named (including enabling PIC
> in the ./configure step).
> However, named itself is pretty secure, and there haven't been many
> code-execution exploits in recent years. That isn't to say one won't
> be discovered and exploited before you have a chance to update, only
> that it isn't a common occurrence.
> Chris Buxton
> Professional Services
> Men & Mice

I understand. I went to using the update-keys file to avoid putting
the key in plaintext in named.conf. I thought bind read the conf file
before it dropped root privileges and changed to the user with the -u
option. It seems that reading it after becoming an unprivileged user
negates some of the advantages of keeping the key secret. I did have the
key in the conf file and, while it may seem more private in a key file, it
turns out to not be the case. I will have to live with it though.

Thanks for the comment,

David Forrest e-mail: drf @ maplepark.com
Maple Park Development Corporation http://www.maplepark.com
St. Louis, Missouri