Gentoo SELinux permission denied error when starting dhcpd

hda7 · 11-27-2014, 09:11 PM

I have recently set up a Gentoo server to serve as a network router. Though it will serve on a semi-trusted network, I have nevertheless attempted to put together a secure server. Accordingly, I installed gentoo-hardened and have installed and configured SELinux. This is only my second time playing with SELinux and my first time getting it to work (for the most part). While for the most part everything seems to work fine, I have discovered that, when in SELinux enforcing mode, I cannot start dhcpd without errors:

Code:

root@server# run_init /etc/init.d/dhcpd start
Authenticating root.
Password:
 * /var/lib/dhcp: creating directory
sed: can't read /etc/dhcp/dhcpd.conf: Permission denied
 * /var/lib/dhcp/dhcpd.leases: creating file
 * checkpath: open: Permission denied
sed: can't read /etc/dhcp/dhcpd.conf: Permission denied
 * Starting dhcpd ... * start-stop-daemon: did not create a valid pid in `//var/run/dhcp/dhcpd.pid'
 [ !! ]
 * ERROR: dhcpd failed to start

I am running this from the following context:

Code:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),26(tape),27(video) context=staff_u:sysadm_r:sysadm_t

Permissions on the requisite files/directories are thus:

Code:

root@server# ls -lZ /etc/dhcp
total 8
-rw-r--r--. 1 root root system_u:object_r:dhcp_etc_t  914 Nov 25 15:57 dhclient.conf
-rw-r--r--. 1 root root system_u:object_r:dhcp_etc_t 3305 Nov 26 15:27 dhcpd.conf

root@server# ls -ldZ /var/lib/dhcp
drwxr-xr-x. 2 dhcp dhcp system_u:object_r:dhcp_state_t 4096 Nov 27 20:15 /var/lib/dhcp

And the dhcpd process spawned looks like this:

Code:

LABEL                           UID        PID  PPID  C    SZ   RSS PSR STIME TTY          TIME CMD
system_u:system_r:dhcpd_t       dhcp     11114     1  0  2597  5716   0 20:36 ?        00:00:00 /usr/sbin/dhcpd -cf /etc/dhcp/dhcpd.conf -q -pf /var/run/dhcp/dhcpd.pid -lf /var/lib/dhcp/dhcpd.leases -user dhcp -group dhcp

As far as I can tell, the files and directories are labeled correctly, and for good measure I ran "rlpkg dhcp" with no change. I also tried reemerging the selinux-dhcp policy to no avail. Can anyone enlighten me on this behavior? Does this indicate a bug in the policy? A mistake in my configuration? Or am I simply not running the init.d script properly? As I said, I am fairly new to SELinux and anything that can shed light on its inner workings would be appreciated.

edit: To clarify, dhcpd starts normally if SELinux is set to permissive.

unSpawn · 11-29-2014, 06:40 AM

Hmm. First thing I'd do is run 'grep dhc /var/log/audit/audit.log|audit2allow;' and see if there's any clues.

hda7 · 11-29-2014, 08:52 PM

Quote:

Originally Posted by unSpawn

Hmm. First thing I'd do is run 'grep dhc /var/log/audit/audit.log|audit2allow;' and see if there's any clues.

Even after attempting to start dhcpd, audit.log appears to be empty. I even ran "semodule -DB" in an attempt to have more verbose logging with the same result. Does SELinux's logging need configuring/enabling?

unSpawn · 11-30-2014, 03:18 AM

Quote:

Originally Posted by hda7

Does SELinux's logging need configuring/enabling?

Check if the audit service (auditd) is running. If it isn't then AVC messages should appear in /var/log/messages or equivalent. The configuration requirements for the audit service are minimal and AFAIK it should work with a minimal conf (prolly has sane defaults) right out of the box.

hda7 · 11-30-2014, 09:22 AM

Quote:

Originally Posted by unSpawn

Check if the audit service (auditd) is running.

Well, it wasn't. It was already installed though, with a nearly-sane default config (there was a line for 64-bit systems even though this is a 32-bit machine/install). Auditd now added to default runlevel.

Quote:

Originally Posted by unSpawn

Hmm. First thing I'd do is run 'grep dhc /var/log/audit/audit.log|audit2allow;' and see if there's any clues.

Now that auditd is running, that gives

Code:

#============= dhcpd_t ==============
allow dhcpd_t tmpfs_t:file { read write };

#============= initrc_t ==============
allow initrc_t dhcp_etc_t:file read;
allow initrc_t dhcpd_t:process { siginh rlimitinh noatsecure };
allow initrc_t tmpfs_t:file { read unlink };

The thing which grabs my attention is "noatsecure." Does this mean that starting dhcpd is only allowed from one of the "secure terminals" listed in /etc/securetty? Currently I'm running inside a screen session over ssh.

hda7 · 11-30-2014, 02:58 PM

Quote:

Originally Posted by hda7

The thing which grabs my attention is "noatsecure." Does this mean that starting dhcpd is only allowed from one of the "secure terminals" listed in /etc/securetty? Currently I'm running inside a screen session over ssh.

Apparently not. Logging in via the serial port (ttyS0, which is in "/etc/securetty") and trying to start dhcpd still fails. I did, however, catch this additional audit section:

Code:

#============= tmpfiles_t ==============

#!!!! This avc can be allowed using the boolean 'tmpfiles_manage_all_non_security'
allow tmpfiles_t dhcp_state_t:dir { getattr search };

unSpawn · 11-30-2014, 02:59 PM

Quote:

Originally Posted by hda7

The thing which grabs my attention is "noatsecure." Does this mean that starting dhcpd is only allowed from one of the "secure terminals" listed in /etc/securetty?

No, it's Something Completely Different: noatsecure disables environment sanitation. See AT_SECURE in 'man getauxval' or other Glibc documentation.

hda7 · 11-30-2014, 04:18 PM

OK, this is what I've gathered so far from the audit log:

1) The SELinux boolean "tmpfiles_manage_all_non_security" probably ought to be tripped on
2) /etc/init.d/dhcpd itself attempts to read the configuration file (apparently to find the lease file name), but it runs in the system_u:system_r:initrc_t context, which is not permitted access.

It seems to me, then, that allowing initrc_t read access to dhcp_etc_t files would be the most straightforward solution. Time to learn how to add policy rules...

unSpawn · 11-30-2014, 04:33 PM

Quote:

Originally Posted by hda7

It seems to me, then, that allowing initrc_t read access to dhcp_etc_t files would be the most straightforward solution.

Yes, that's quite common for transitions from the calling init domain to another one on runlevel change.