Bug 146844 - dhcpd won't start with ddns enabled
dhcpd won't start with ddns enabled
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-02-01 19:48 EST by Tim Fenn
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2005-251
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-09 09:06:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:251 low SHIPPED_LIVE selinux-policy-targeted bug fix update 2005-06-09 00:00:00 EDT

  None (edit)
Description Tim Fenn 2005-02-01 19:48:59 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
dhcpd refuses to start in an environment using /etc/rndc.key as the
authentication key (e.g. in a situation using DDNS), which is entered
 in /etc/selinux/targeted/contexts/files/file_contexts as:

/etc/rndc.*             --      system_u:object_r:named_conf_t

and therefore cannot be touched by dhcpd (from dmesg):

audit(1107297176.619:0): avc:  denied  { search } for  pid=8099
exe=/usr/sbin/dhcpd name=named dev=sda1 ino=1295119
scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:named_zone_t


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.service dhcpd restart

Actual Results:  dhcpd: Internet Systems Consortium DHCP Server V3.0.1
dhcpd: Copyright 2004 Internet Systems Consortium.
dhcpd: All rights reserved.
dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
audit(1107297176.619:0): avc:  denied  { search }
for  pid=8099 exe=/usr/sbin/dhcpd name=named dev=sda1 ino=1295119
scontext=root:system_r:dhcpd_t tcontext=system_u:object_r:named_zone_t
dhcpd: Can't open /etc/rndc.key: Permission denied
dhcpd: If you did not get this software from ftp.isc.org,
dhcpd: get the latest from ftp.isc.org and install that before
requesting help.
dhcpd: If you did get this software from ftp.isc.org and have not
dhcpd: yet read the README, please read it before requesting help.
dhcpd: If you intend to request help from the dhcp-server@isc.org
dhcpd: mailing list, please read the section on the README
dhcpd: submitting bug reports and requests for help.
dhcpd: Please do not under any circumstances send requests for
dhcpd: help directly to the authors of this software - please
dhcpd: send them to the appropriate mailing list as described in
dhcpd: the README file.
dhcpd: exiting.

Expected Results:  dhcpd should be able to read /etc/rndc.key and
start properly.

Additional info:
Comment 1 Tim Fenn 2005-02-02 00:26:30 EST
I should also mention I was able to "fix" the problem by creating a
hard link from /etc/rndc.key to /var/named/chroot/etc/rndc.key,
commenting out the above pattern in file_contexts, running restorecon
/etc/rndc.*, then restart dhcpd.
Comment 3 Jason Vas Dias 2005-02-02 10:27:49 EST
I'm assuming that the user is trying to setup DDNS with dhcpd.conf
entries like:
  ddns-update-style interim;
  include "/var/named/chroot/etc/rndc.key";
  zone "my.ddns.zone" {
       key     rndckey;
In this instance, yes, dhcpd fails to start with the error message:
Feb  2 10:19:41 jvdspc kernel: audit(1107357581.075:0): avc:  denied 
{ search } for  pid=5843 exe=/usr/sbin/dhcpd name=named dev=hda2
ino=341807 scontext=root:system_r:dhcpd_t
tcontext=system_u:object_r:named_zone_t tclass=dir
Feb  2 10:19:41 jvdspc dhcpd: Can't open
/var/named/chroot/etc/rndc.key: Permission denied

You can workaround this by NOT using the include mechanism: just
copying the 'key "rndckey" { ... }' statement into dhcpd.conf; or by
creating a new key in a new file (eg. by using '/usr/sbin/dns-keygen'
) and then including it in both named.conf and dhcpd.conf.

Comment 4 Daniel Walsh 2005-02-02 10:30:26 EST
Does adding
allow dhcpd_t named_zone_t:dir search;

Fix the problems or do we need more policy?
Comment 5 Jason Vas Dias 2005-02-02 10:43:10 EST
I think dhcpd would then get an error for 'named_zone_t:file read' .

Perhaps we should consider a new 'dnssec_t' file context - dhcpd
only needs to read named key files. 

In the DNS documentation, users are advised to make key files with 
mode '400', and to put key files containing the 'secret' half of a 
public key in separate directories with mode '500' - ie. to increase
file system protection for them - SELinux could do a better job of
protecting DNS key files - the /usr/sbin/dnssec-* tools would then
need modifying to apply this 'dnssec_t' context to these files -
I think that would make sense . We could then give named and dhcpd
read access to 'dnssec_t' and only the /usr/sbin/dnssec* tools 
write access to 'dnssec_t' .
Comment 6 Tim Fenn 2005-02-02 13:51:43 EST
sorry, I should have made it clear - yes, dhcpd.conf contains:

include "/etc/rndc.key";

zone foo.bar. {
        key rndckey;

zone 1.168.192.in-addr.arpa. {
        key rndckey;
Comment 7 Daniel Walsh 2005-02-04 15:34:08 EST
Fixed in selinux-policy-targeted-1.17.30-2.77
Comment 8 Gene Czarcinski 2005-04-26 17:38:10 EDT
If I had this problem on RHEL 4 would it be OK to apply this update there also?
Comment 9 Daniel Walsh 2005-04-27 07:55:39 EDT
U1 policy is selinux-policy-targeted-1.17.30-2.88 so it should have this fix.

Preview is available in 

Comment 10 Tim Powers 2005-06-09 09:06:16 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.