Bug 527384

Summary: SELinux policy missing for /etc/init.d/named
Product: Red Hat Enterprise Linux 5 Reporter: Ruben Saar <rsaar>
Component: selinux-policy-targetedAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact: BaseOS QE <qe-baseos-auto>
Severity: low Docs Contact:
Priority: low    
Version: 5.4CC: dwalsh, mykleb, rsaar
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-10-07 17:06:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ruben Saar 2009-10-06 07:39:53 UTC
Description of problem:
If SELinux is in enforcing mode, the start of named fails if named is started using:
$ sudo /etc/init.d/named start
Starting named: named: chroot(): Permission denied
                                                           [FAILED]
This error does NOT occur if named is started directly using:
$ sudo /usr/sbin/named -u named -t /var/named/chroot
Therefore I assume, the error is caused by the script /etc/init.d/named

Version-Release number of selected component (if applicable):
RHEL 5.4   2.6.18-164.2.1.el5  x86_64
libselinux-1.33.4-5.5.el5
libselinux-utils-1.33.4-5.5.el5
selinux-policy-2.4.6-255.el5
selinux-policy-targeted-2.4.6-255.el5

Steps to Reproduce:
1. sudo setenforce Enforcing
2. sudo /etc/init.d/named start

Actual results:
the error message above

Expected results:
named running

Additional info:
Policy can be created and installed manually:
$ sudo /etc/init.d/named start
$ sudo grep avc /var/log/audit/audit.log | grep dac_read_search | tail -1 | audit2allow -M mynamed
$ sudo semodule -i mynamed.pp
$ cat mynamed.te

module mynamed 1.0;

require {
        type named_t;
        class capability dac_read_search;
}

#============= named_t ==============
allow named_t self:capability dac_read_search;

Comment 1 Daniel Walsh 2009-10-06 14:09:46 UTC
Is the ownership correct in the /var/chroot directory.

dac_read_search means that root is trying to read files that it does not have read access to.

Comment 2 Jan-Frode Myklebust 2009-10-07 00:36:15 UTC
I'm wondering if it might be the difference between running "/etc/init.d/named start" and "service named start". I've asked Ruben to try if the service command works, as that should execute the script with a sane environment (from "/" as working directory, instead of wherever $cwd was when he ran the script).

Comment 3 Jan-Frode Myklebust 2009-10-07 01:16:04 UTC
BTW: these are the ownerships dwalsh asked for:

[janfrode@ns1ext ~]$ sudo ls -ldZ /var/named
drwxr-x---  named hostmaster system_u:object_r:named_zone_t   /var/named
[janfrode@ns1ext ~]$ sudo ls -ldZ /var/named/chroot
drwxr-x---  named hostmaster system_u:object_r:named_conf_t   /var/named/chroot


Group "hostmaster" is a local modification, so not what standard RHEL5 would use for these. I think the default is group "named".

Comment 4 Ruben Saar 2009-10-07 07:52:36 UTC
Answer to comment#2:
With "sudo service named start" the same error occurs.

Comment 5 Jan-Frode Myklebust 2009-10-07 13:58:03 UTC
BTW: /var/named/chroot is a separate volume/fs:

[janfrode@ns1ext ~]$ df -h /var/named/chroot
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/rootvg-chrootlv
                      6.9G  518M  6.1G   8% /var/named/chroot


that might be relevant...

Comment 6 Daniel Walsh 2009-10-07 17:06:25 UTC
Since you changed the ownership of the directories from root to named you need to add this additional access.

Comment 7 Jan-Frode Myklebust 2009-10-08 01:26:36 UTC
Great, thanks!

I have no idea why we've changed this permission, so we should probably change it back to the default. Especially since the bind-chroot package quite often will reset permissions on upgrades anyway..