dhcpd wont start due to rndc.key permissions

[Rob_Leo]

Binary package hint: dhcp3-server

System information:
#lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04
#apt-cache policy dhcp3-server
dhcp3-server:
  Installed: 3.0.6.dfsg-1ubuntu9
  Candidate: 3.0.6.dfsg-1ubuntu9
  Version table:
 *** 3.0.6.dfsg-1ubuntu9 0
        500 http://nl.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
#apt-cache policy bind9
bind9:
  Installed: 1:9.4.2.dfsg.P2-2ubuntu0.1
  Candidate: 1:9.4.2.dfsg.P2-2ubuntu0.1
  Version table:
 *** 1:9.4.2.dfsg.P2-2ubuntu0.1 0
        500 http://nl.archive.ubuntu.com hardy-updates/main Packages
        500 http://security.ubuntu.com hardy-security/main Packages
        100 /var/lib/dpkg/status
     1:9.4.2-10 0
        500 http://nl.archive.ubuntu.com hardy/main Packages

Problem:
dhcpd wont start - "/etc/bind/rndc.key: Permission denied"
Workaround found but is a potential security issue ("/etc/bind/rndc.conf" world readable)

Brief:
Trying to get dhcp3-server and bind9 to work together nicely.
The "/etc/bind/rndc.key" file is owned by bind:bind w. 640 perms by default and dhcpd3 process runs under user "dhcpd". Adding user "dhcpd" to group "bind" does not seem to work. Permissions of "/etc/bind/rndc.key" need to be changed to 644 for dhcp3-server to start (I could find no other solution - after a few hours of google and 30 minutes of play, at least ;-)

Steps:
- Install & configure bind9 (configuration tested and working)
- Install & configure dhcp3-server
- sudo /etc/init.d/dhcp3-server start

Expected result:
dhcpd starts

Actual result:
#/etc/init.d/dhcp3-server start
dhcpd self-test failed. Please fix the config file.
The error was:
Can't open /etc/bind/rndc.key: Permission denied
#ls -l `which dhcpd3`
-rwxr-xr-x 1 root root 516164 2008-04-02 15:38 /usr/sbin/dhcpd3
#ls -l /etc/bind/rndc.key
-rw-r----- 1 bind bind 77 2009-03-12 14:30 /etc/bind/rndc.key
#id -a dhcpd
uid=111(dhcpd) gid=122(dhcpd) groups=122(dhcpd),121(bind)

Workaround:
- Change permissions of /etc/bind/rndc.key to world readable (from 640 -> 644)
  note: adding 'dhcpd' user to 'bind' group does not work for some reason
- Start dhcpd:
#chmod 644 /etc/bind/rndc.key
#/etc/init.d/dhcp3-server start
 * Starting DHCP server dhcpd3 [ OK ]
#ps -ef | grep dhcpd
dhcpd 3292 1 0 17:11 ? 00:00:00 /usr/sbin/dhcpd3 -q -pf /var/run/dhcp3-server/dhcpd.pid -cf /etc/dhcp3/dhcpd.conf eth0
root 3298 3090 0 17:11 pts/0 00:00:00 grep dhcpd

[Chuck Short (zulcss)]

Thanks for the bug report, I dont think there is a fix for this due to the nature of the beast.

Regards
chuck

[Martin Bergman (martin-devsed)]

Hi guys, this kindof solves the "bug"

http://www.debianadmin.com/howto-setup-dhcp-server-and-dynamic-dns-with-bind-in-debian.html#comment-3326

/Misse

[ben thielsen (btb-bitrate)]

i'd like to bump this entry a bit - if nothing else, to understand better why exactly this doesn't work.

as the user dhcpd runs as (dhcpd), i can read the key file (by way of a symlink, in my case):

>whoami
dhcpd

>id dhcpd
uid=105(dhcpd) gid=113(dhcpd) groups=113(dhcpd),999(ddns)

>ls -Alh
total 20K
lrwxrwxrwx 1 root root 29 2010-03-07 16:12 ddns-key-1.key -> /etc/bind/keys/ddns-key-1.key
-rw-r----- 1 root dhcpd 148 2009-12-01 20:14 ddns-key-1.key.old
drwxr-xr-x 2 root root 4.0K 2010-02-15 20:29 dhclient-enter-hooks.d
drwxr-xr-x 2 root root 4.0K 2009-12-16 12:17 dhclient-exit-hooks.d
-rw-r----- 1 root dhcpd 4.1K 2009-12-01 20:17 dhcpd.conf

>ls -alh /etc/bind/keys/ddns-key-1.key
-rw-r----- 1 root ddns 148 2009-12-01 15:24 /etc/bind/keys/ddns-key-1.key

>cat ddns-key-1.key
key ddns-key-1 {
        algorithm hmac-md5;
 secret "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";
};

yet (as in the initial report) when started via it's init script, /usr/sbin/dhcpd can not:

>/etc/init.d/dhcp3-server start
dhcpd self-test failed. Please fix the config file.
The error was:
Internet Systems Consortium DHCP Server V3.1.2
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Can't open /etc/dhcp3/ddns-key-1.key: Permission denied

why doesn't this work? what is different when dhcpd is started via it's init script and privs are dropped to the user named dhcpd? i've adjusted the apparmor settings for dhcpd, and there are no audit entries for apparmor being logged - what is preventing this file from being read?

[Stephen Gildea (stepheng+launchpad)]

I'm seeing the same thing in 10.04.

The problem is the profile in /etc/apparmor.d/usr.sbin.dhcpd3, which doesn't allow reading any files in /etc/bind.

Could we have a one-file exception added to this profile, please, to share a key between bind and dhcpd?
The original poster used rndc.key, but I prefer that every use of a key use a unique key, so I think a name such as ddns-key-1.key or (what I use) dhcp.key would be preferable.

[Jamie Strandboge (jdstrand)]

As Chuck said, this doesn't seem like something that can be fixed safely for everyone. People can always add the key they want to use to /etc/apparmor.d/usr.sbin.dhcpd and then reload the profile.

Is there a common practice location that we can consider? I think rndc.key is probably out of the question, but does the official upstream or Ubuntu documentation give a standard location? We could consider adding it to the AppArmor profile then.

[Thomas Schweikle (tps)]

The standard location for rndc.key is, since it belongs to "bind"-Tools: /etc/bind/rndc.key
It should be sufficient to add this whole directory to both: named and dhcpd in apparmor.d

BTW: it would be nice if named used /etc/named for its configuration files! Named and bind-tools are two things one shall not mix up!

[Thomas Schweikle (tps)]

I've tested again:

group bind has users: dhcpd
group dhcpd has users: bind

apparmor.d/usr.sbin.named
apparmor.d/usr.sbin.dhcpd3
both have a line:
/etc/bind/** r, -> apparmor allows them to read the file.

/etc/bind is owned by bind:bind, rwxrwx---
/etc/bind/rndc.key is owned by bind:bind, rw-r----- -> named fails to read the file, dhcpd fails to read the file!!!!

/etc/bind/rndc.key is owned by bind:bind, rw-r--r-- -> (bad idea but: named can read the file, dhcpd can read the file).

I'd say: at the point in time named, dhcpd try to read the file they are running user bind (named), user dhcpd (dhcpd3) but not the required group!
Or: named and dhcpd try to open the file rw, failing because only reading is allowed.

[Lorin Soura (gr8can8dian)]

After some extensive tinkering, I came up with this solution to the rndc.key permissions issue:
As the root user (or sudo) do the following:

cp /etc/bind/rndc.key /etc/dhcp3/
chown dhcp:dhcp /etc/dhcp3/rndc.key
chmod 640 /etc/dhcp3/rndc.key

In "/etc/dhcp3/dhcpd.conf" add this line:
include "/etc/dhcp3/rndc.key";

chown root:bind /etc/bind/rndc.key
chmod 640 /etc/bind/rndc.key

In /etc/bind/named.conf add this line to the top of the file:
include "/etc/bind/rndc.key";

In /etc/bind/named.conf add this line to the bottom of the file:

controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};

[Juha Erkkilä (juha-erkkila)]

It seems this bug is a symptom of this bug: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/727837

[Carl Karsten (carlfk)]

I agree, side effect of https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/727837 "https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/727837"

Here is a demo of the bug, and a work around: add user root to the bind group. attached is the script, here is it being run:

juser@kasp:~$ sudo ./ddns.sh
[sudo] password for juser:
+ apt-get --assume-yes install dhcp3-server bind9
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  bind9utils isc-dhcp-server
Suggested packages:
  bind9-doc resolvconf isc-dhcp-server-ldap
The following NEW packages will be installed:
  bind9 bind9utils dhcp3-server isc-dhcp-server
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 866 kB of archives.
After this operation, 2,568 kB of additional disk space will be used.
Get:1 http://us.archive.ubuntu.com/ubuntu/ oneiric/main bind9utils amd64 1:9.7.3.dfsg-1ubuntu4 [104 kB]
Get:2 http://us.archive.ubuntu.com/ubuntu/ oneiric/main bind9 amd64 1:9.7.3.dfsg-1ubuntu4 [331 kB]
Get:3 http://us.archive.ubuntu.com/ubuntu/ oneiric/main isc-dhcp-server amd64 4.1.1-P1-17ubuntu10 [427 kB]
Get:4 http://us.archive.ubuntu.com/ubuntu/ oneiric/main dhcp3-server all 4.1.1-P1-17ubuntu10 [3,296 B]
Fetched 866 kB in 1s (737 kB/s)
Preconfiguring packages ...
Selecting previously deselected package bind9utils.
(Reading database ... 94476 files and directories currently installed.)
Unpacking bind9utils (from .../bind9utils_1%3a9.7.3.dfsg-1ubuntu4_amd64.deb) ...
Selecting previously deselected package bind9.
Unpacking bind9 (from .../bind9_1%3a9.7.3.dfsg-1ubuntu4_amd64.deb) ...
Selecting previously deselected package isc-dhcp-server.
Unpacking isc-dhcp-server (from .../isc-dhcp-server_4.1.1-P1-17ubuntu10_amd64.deb) ...
Selecting previously deselected package dhcp3-server.
Unpacking dhcp3-server (from .../dhcp3-server_4.1.1-P1-17ubuntu10_all.deb) ...
Processing triggers for man-db ...
Processing triggers for ufw ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up bind9utils (1:9.7.3.dfsg-1ubuntu4) ...
Setting up bind9 (1:9.7.3.dfsg-1ubuntu4) ...
Adding group `bind' (GID 113) ...
Done.
Adding system user `bind' (UID 107) ...
Adding new user `bind' (UID 107) with group `bind' ...
Not creating home directory `/var/cache/bind'.
wrote key file "/etc/bind/rndc.key"
#
 * Starting domain name service... bind9 [ OK ]
Setting up isc-dhcp-server (4.1.1-P1-17ubuntu10) ...
Generating /etc/default/isc-dhcp-server...
 * Starting ISC DHCP server dhcpd * check syslog for diagnostics.
                                                                         [fail]
invoke-rc.d: initscript isc-dhcp-server, action "start" failed.
Setting up dhcp3-server (4.1.1-P1-17ubuntu10) ...
+ adduser dhcpd bind
Adding user `dhcpd' to group `bind' ...
Adding user dhcpd to group bind
Done.
+ cat
+ cat
+ service apparmor restart
 * Reloading AppArmor profiles [ OK ]
+ sudo service isc-dhcp-server start
dhcpd self-test failed. Pl...

[Carl Karsten (carlfk)]

install finished and rebooted.. I need to get back into the installer shell and see if I can run apt-avahi-discover

[Carl Karsten (carlfk)]

opps, ignore that. meant for other bug.

[Stéphane Graber (stgraber)]

Subscribing ubuntu-security for a go/no-go on adding rdnc.key to the apparmor profile so that users can simply add dhcpd to the bind group, thereby allowing access to the key.

[Stéphane Graber (stgraber)]

Marking Incomplete to reflect the fact that I'm blocked on feedback from the security team.

[Marc Deslauriers (mdeslaur)]

I do believe having the dhcp server setup with dynamic dns is a recommended setup, so I think adding read access to /etc/bind/rndc.key to the dhcp server apparmor profile is a reasonable thing to do. (bug 727837 probably needs to be fixed also for this to ultimately work).

[Jamie Strandboge (jdstrand)]

This seems reasonable to me as well. There is no reason to prevent the server from reading rndc.key as it is strictly required by the server when its setup to use rndc. Since we (finally) determined that /etc/bind/rndc.key is the documented place for the file, it makes sense to me to add it to the profile. In reading the various manpages, we should also be including /etc/bind/rndc.conf as well (man rndc.conf).

[Jamie Strandboge (jdstrand)]

Actually, strike that-- I was thinking about the bind9 server needing these permissions. isc-dhcp should *not* have read access to /etc/bind/rndc.conf, please disregard that request.

[Jamie Strandboge (jdstrand)]

So, in thinking about and discussing this more, I would like to justify my position somewhat: while I am not super happy about the added permission given to dhcpd, I do think that people who install both dhcpd and bind9 on the same system will tend to use dynamic updates, and at least some of those people are disabling AppArmor to work around this bug, resulting in a decrease in security for these users. For dhcpd servers that don't have bind9 installed (I would imagine most), this change does nothing because rndc.key doesn't exist.

[Marc Deslauriers (mdeslaur)]

OK, now that I've thought about this some more, we should _not_ be allowing the dhcp server to read the rndc.key.

The rndc.key key isn't for dynamic updates, it's for use by the rndc utility for server management. It would typically be used by sysadmins inside the "controls" statement in the config file.

Reusing this same key for dynamic updates is a security issue, as it may allow more permissions than what is intended. Dynamic updates should be using other keys, not that particular one.

Perhaps we should define a standard location for dynamic update keys that could be used by both bind9 and dhcp, and we could add that to the apparmor profile...perhaps a "keys" subdirectory?

[Jamie Strandboge (jdstrand)]

I like this idea much better. Whether packaging creates a special dynamic dns updates key or uses a keys directory, these keys are actually specifically designed for use with dynamic updates and totally appropriate to add to the apparmor profile. Unrelated to this bug, if packaging is being adjusted to make adding dynamic dns work easier, it should probably default to 'off' (which is a secure default) but with a preseedable debconf option to enable it (but this should probably be discussed elsewhere).

[Marc Deslauriers (mdeslaur)]

Most of the example dynamic dns configs and howtos that are available on the internet aren't secure, as they use the rndc.key and require the dhcpd user to the bind group, both of which compromise security.

A new key should be generated for dynamic dns updates, as described in the dhcpd.conf man page. The key can then be directly included in the config files without requiring apparmor changes.

[Stéphane Graber (stgraber)]

After some more discussion, what will be allowed is:
 /etc/dhcp/ddns-keys/** r,

That directory will be created at install time, owned by root:dhcpd and mode 750. The apparmor rule comment and the changelog will both encourage people to generate separate keys and copy them into that directory.

[Launchpad Janitor (janitor)]

This bug was fixed in the package isc-dhcp - 4.2.4-1ubuntu1

---------------
isc-dhcp (4.2.4-1ubuntu1) quantal; urgency=low

  * Merge from Debian. Remaining changes:
    (LP: #768171, LP: #841182, LP: #881558, LP: #872929, LP: #616809)
    - Use upstart jobs for isc-dhcp-server and isc-dhcp-relay.
    - Add IPv6 support to udeb dhclient-script (forwarded as Debian #635897).
    - Add an apport hook to isc-dhcp-client and isc-dhcp-server.
    - Add an apparmor profile to isc-dhcp-client and isc-dhcp-server.
    - Update default dhclient.conf to ask for IPv6 configuration.
    - Patches:
      + dhclient-fix-backoff
      + dhclient-more-debug
      + dhclient-onetry-call-clientscript
      + dhclient-safer-timeout
      + dhcpd.conf-subnet-examples
      + multi-ip-addr-per-if
      + onetry_retry_after_initial_success
      + revert-next-server
  * Set fqdn.fqdn to the result of gethostname(); (LP: #991360)
  * Replace old droppriv and deroot patches by use of --enable-paranoia
    and matching -user and -group parameters to dhcpd. (LP: #727837)
  * Allow read access to /etc/dhcp/ddns-keys/* for ddns. (LP: #341817)
    It's expected that people generate one key per zone and have it stored
    in both /etc/bind9 and /etc/dhcp/ddns-keys/ for security reason.
  * Fix apport hook to work with python3.

isc-dhcp (4.2.4-1) unstable; urgency=low

  * New upstream release
  * debian/control: reformatted Uploaders so that dch doesn't think I'm making
    NMUs
  * debian/rules: do a clean between the LDAP-enabled build and the
    non-LDAP-enabled one, so that no LDAP-related artefacts are accidently
    incorporated into the non-LDAP build
  * debian/dhclient-script.*: conditionalise the chown/chmod of the new
    resolv.conf on the existence of the old one (closes: #595400)
  * debian/dhclient-script.linux: comply with RFC 3442 and ignore
    the routers option if the rfc3442-classless-static-routes option is present
    (closes: #592735)
  * debian/dhclient-script.kfreebsd: fix subnet mask handling (closes: #677985)

isc-dhcp (4.2.2.dfsg.1-5) unstable; urgency=medium

  [ Andrew Pollock ]
  * debian/dhclient.conf: send the hostname (closes: #151820)

  [ Michael Gilbert ]
  * Fix cve-2011-4868: error in DDNS handling with IPv6 (closes: #655746)
  * Fix cve-2011-4539: error in regular expression handling
    (closes: #652259)
  * Make dependencies diff-able
  * Add myself to uploaders
  * Remove all automatically generated files in clean rule
  * Medium urgency for security updates

isc-dhcp (4.2.2.dfsg.1-4) unstable; urgency=low

  * The "Zoe woke up at 4am and I couldn't get back to sleep so I had some
    extra time to work on this" release
  * patch the Makefile for the embedded BIND libraries so that autoconf is run
    so that the modification to configure.in to fix the FTBFS on kFreeBSD
    actually does something useful (closes: #643569)

isc-dhcp (4.2.2.dfsg.1-3) unstable; urgency=low

  * debian/control: remove transitional packages
  * debian/rules: apply the intent of Pierre Chifflier's patch to enable
    hardening options (closes: #644413)
  * debian/control: also add inetutils-ping to the dependencies for
    isc-dhcp-client on hurd (...

[no!chance (ralf-fehlau)]

I wonder, noone provides a real solution for this bug ... AFTER MORE THAN 3 YEARS.

It is not a bug! But it looks like nobody documented the changes.
Simply chown the rndc.key-File to root:root. Start the dhcp server! That's it!

$ sudo chown dhcpd: rndc.key
$ sudo service isc-dhcp-server start
start: Job failed to start
$ sudo chown root: rndc.key
$ sudo service isc-dhcp-server start
isc-dhcp-server start/running, process 19126