Bug 213926 - dhcpd startup denied -- accessing rndc.key
Summary: dhcpd startup denied -- accessing rndc.key
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: bind   
(Show other bugs)
Version: 6
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-11-03 19:47 UTC by Gene Czarcinski
Modified: 2013-04-30 23:34 UTC (History)
2 users (show)

Fixed In Version: 9.4.0-1.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-06 15:37:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rpm -qa | egrep 'bind|caching' (131 bytes, text/plain)
2006-11-10 16:14 UTC, Gene Czarcinski
no flags Details

Description Gene Czarcinski 2006-11-03 19:47:46 UTC
Description of problem:
I have named and dhcpd configured to allow automatic updating of system names in
DNS by dhcpd.  Under FC6, dhcpd startup fails because:

audit(1162562248.905:8): avc:  denied  { read } for  pid=3560 comm="dhcpd"
name="rndc.key" dev=hda8 ino=1064661 scontext=root:system_r:dhcpd_t:s0
tcontext=system_u:object_r:dnssec_t:s0 tclass=lnk_file

I used audit2allow to create:

module dhcpd 1.0;

require {
        class lnk_file read;
        type dhcpd_t;
        type dnssec_t;
        role system_r;
};

allow dhcpd_t dnssec_t:lnk_file read;

which when processed and loaded allowed dhcpd to start and function properly.

I believe this should be a built-in option ... should this be a bug report or an
RFE?



Version-Release number of selected component (if applicable):
FC6 plus updates as of 11/2/2006

How reproducible:
yes

Comment 1 Daniel Walsh 2006-11-03 21:15:20 UTC
This looks like a mislabeled link.  Should be etc_t.

restorecon /etc/rndc.key

I believe this is a bug in the bind package labeling the link file, when it
should only label the real file.

Comment 2 Martin Stransky 2006-11-10 14:08:42 UTC
Could you please attach an output of " #rpm -qa | egrep 'bind|caching' "?

Comment 3 Gene Czarcinski 2006-11-10 16:14:17 UTC
Created attachment 140902 [details]
rpm -qa | egrep 'bind|caching'

After I did the "restorecon /etc/rndc.key", I noi longer needed the local
selinux module and everything worked.

Attached is the requested info.

Comment 4 Martin Stransky 2006-11-10 16:30:43 UTC
I can reproduce it, thanks.

Comment 5 Martin Stransky 2006-11-22 12:52:00 UTC
Could you please attach an output from "#matchpathcon /etc/rndc.key"?

Comment 6 Gene Czarcinski 2006-11-22 15:15:11 UTC
Output from "matchpathcon /etc/rndc.key" (which is what I think you meant to say):

/etc/rndc.key   system_u:object_r:dnssec_t

Comment 7 Martin Stransky 2006-11-23 10:28:41 UTC
and what context do you have for this file? (ls -Z /etc/rndc.key)

Comment 8 Gene Czarcinski 2006-11-24 17:27:44 UTC
Per comment #3 above, I did the "restorecon /etc/rndc.key" and that seemed to
"fix" the problem.  The result of "ls -Z /etc/rndc.key" now is:

   lrwxrwxrwx  root named system_u:object_r:etc_t          /etc/rndc.key ->
/var/named/chroot//etc/rndc.key

Comment 9 Martin Stransky 2006-12-06 11:25:41 UTC
It's quite strange because:

matchpathcon /etc/rndc.key says system_u:object_r:dnssec_t

the default context for /etc/rndc.key is system_u:object_r:dnssec_t

but restorecon /etc/rndc.key sets it to system_u:object_r:etc_t?

I'm quite confused with it, but at least in policy is that /etc/rndc.key should
have system_u:object_r:dnssec_t, right?

Comment 10 Gene Czarcinski 2006-12-06 15:03:14 UTC
At this point, I am not sure what /etc/rndc.key was originally set to during the
install (it was a fresh install).  However, with that setting, dhcpd did not
work.  After running "restorecon /etc/rndc.key", is is set to
"system_u:object_r:etc_t" and dhcpd can update named dynamically.

Perhaps one of the selinux "experts" can shed some light on the differences
between matchpathcon and restorecon.

Comment 11 Daniel Walsh 2007-02-14 20:58:49 UTC
/etc/rndc.key the file is labeled dnssec_t
/etc/rndc.key the symbolic link is labeled etc_t.

Comment 12 Adam Tkac 2007-03-06 15:37:14 UTC
Could be fixed in bind-*9.4.0-1.fc7


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