Hide Forgot
Description of problem: On an CentOS 6.2 + EPEL out of the box install with SELinux enabled, I cannot run the check_icmp nagios plugin. Version-Release number of selected component (if applicable): $ rpm -q nagios-plugins-icmp nagios-plugins-icmp-1.4.15-2.el6.x86_64 Actual results: Dec 23 09:00:53 pluto kernel: type=1400 audit(1324627253.257:85105): avc: denie d { create } for pid=23520 comm="check_icmp" scontext=unconfined_u:system_r:na gios_services_plugin_t:s0 tcontext=unconfined_u:system_r:nagios_services_plugin_ t:s0 tclass=rawip_socket Dec 23 09:00:53 pluto kernel: type=1400 audit(1324627253.257:85106): avc: denie d { setuid } for pid=23520 comm="check_icmp" capability=7 scontext=unconfined _u:system_r:nagios_services_plugin_t:s0 tcontext=unconfined_u:system_r:nagios_se rvices_plugin_t:s0 tclass=capability Additional info: I fixed it by adding the following policy: module localnagios 1.0; require { type nagios_services_plugin_t; class capability setuid; class rawip_socket { read write create setopt }; } #============= nagios_services_plugin_t ============== allow nagios_services_plugin_t self:capability setuid; allow nagios_services_plugin_t self:rawip_socket { read write create setopt };
Any movement on this? It seems like it "should be" a simple change in SELinux policy, but who knows. -Erinn
Seems like we need a new policy for check_icmp.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Fixed in selinux-policy-3.7.19-156.el6
This looks like either the protection on /var/run/nrpe is too tight to root to see or nrpe is not running as the nrpe user but running as root.
Michal, does the test recreate this directory? Could you add your output of # ls -dZ /var/run/nrpe an tell us under which user is nrpe running.
# ls -dZ /var/run/nrpe drwxrwxr-x. nrpe nrpe system_u:object_r:var_run_t:s0 /var/run/nrpe The test doesn't manipulate with this directory at all. At least not directly.
Ok, so we have nrpe nrpe system_u:object_r:var_run_t:s0 /var/run/nrpe but nrpe is running as root.
grep -e nrpe_user -e nrpe_group /etc/nagios/nrpe.cfg nrpe_user=nrpe nrpe_group=nrpe
type=SYSCALL msg=audit(1353589934.759:131): arch=c000003e syscall=2 success=no exit=-13 a0=1687380 a1=41 a2=1a4 a3=4000 items=1 ppid=1 pid=5162 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=7 comm="nrpe" exe="/usr/sbin/nrpe" subj=unconfined_u:system_r:nrpe_t:s0 key=(null) type=AVC msg=audit(1353589934.759:131): avc: denied { dac_override } for pid=5162 comm="nrpe" capability=1 scontext=unconfined_u:system_r:nrpe_t:s0 tcontext=unconfined_u:system_r:nrpe_t:s0 tclass=capability => "uid=0" Michal, how does your config look?
But the AVC is about PID file, which is created by init script, which is intended to be run by root.
Comment from /etc/nagios/nrpe.cfg: # PID FILE # The name of the file in which the NRPE daemon should write it's process ID # number. The file is only written if the NRPE daemon is started by the root # user and is running in standalone mode.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0314.html