Bug 734203

Summary: SELinux prevents nagios check_updates plugin from working
Product: [Fedora] Fedora Reporter: smuskiew
Component: nagios-plugins-check-updatesAssignee: Jose Pedro Oliveira <jose.p.oliveira.oss>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: dan, jose.p.oliveira.oss, Per.t.Sjoholm, therfert
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 17:15:58 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 smuskiew 2011-08-29 17:53:15 UTC
Description of problem:  In Fedora 15 when running with SELinux enabled, the Nagios check_updates plugin is denied access to the "rpm" command, causing it to give the error "Cannot list installed kernels: Permission denied".
This is apparently only when running within the context of Nagios automated checks that it fails, running the plugin from the command line appears to work properly. (But that isn't much as far as Nagios is concerned ;-)


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


How reproducible: Happens for each occurrence of nagios checks.


Steps to Reproduce:
1. Configure Nagios to use the check_updates plugin as a command, something like:
define command {
	command_name		check_updates
	command_line		$USER1$/check_updates -t 30 -w 5 -c 10
}

2. Create a service in the nagios config files to use the check_updates command, ie.
define service {
	use			daily-check-service
	service_description	OS up-to-date
	host_name		localhost
	check_command		check_updates
}

3. Start/restart nagios and ensure the check_updates service checks are running.

Actual results:
Observe the results in the web interface and/or email notifications.  check_updates always fails with "Cannot list installed kernels: Permission denied"

Expected results: check_updates should be able to report (via yum) if any packages are out of date.


Additional info: Here is the relevant info from /var/log/audit/audit.log when nagios attempts to run the check:

type=AVC msg=audit(1314640343.522:123): avc:  denied  { execute } for  pid=4911 comm="check_updates" name="rpm" dev=dm-1 ino=1981036 scontext=system_u:system_r:nagios_system_plugin_t:s0 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file
type=SYSCALL msg=audit(1314640343.522:123): arch=c000003e syscall=59 success=no exit=-13 a0=7fff1bb30059 a1=1d03e90 a2=17841f0 a3=3cc70811e0 items=0 ppid=4910 pid=4911 auid=4294967295 uid=493 gid=487 euid=493 suid=493 fsuid=493 egid=487 sgid=487 fsgid=487 tty=(none) ses=4294967295 comm="check_updates" exe="/usr/bin/perl" subj=system_u:system_r:nagios_system_plugin_t:s0 key=(null)


I checked the selinux context of /usr/lib64/nagios/plugins/check_updates with "ls -Z" and it was originally:
-rwxr-xr-x. root root   unconfined_u:object_r:bin_t:s0   check_updates

Tried fiddling around (but I'm not really sure what I'm doing when it comes to SELinux context) to match some of the other nagios plugin context.  These are the commands I tried (nagios restarted and the check_updates service check was rerun each time, but the result was the same):

chcon -t nagios_system_plugin_exec_t check_updates
chcon -t nagios_services_plugin_exec_t check_updates

RPM package info:

# rpm -qf /usr/lib64/nagios/plugins/check_updates
nagios-plugins-check-updates-1.4.11-2.fc15.x86_64

Let me know if I can provide any additional info or test anything else.

Comment 1 Tomas Herfert 2011-09-09 11:27:57 UTC
There is the same problem in RHEL6 - EPEL.

Comment 2 Tomas Herfert 2011-09-09 13:00:56 UTC
This works for me:

policy_module(nrpe-local,1.0)

	require {
		class file { read getattr open ioctl };
		type nrpe_t;
		type rpm_exec_t;
		type rpm_t;
		type usr_t;
	}

	domtrans_pattern(nrpe_t, rpm_exec_t, rpm_t)
	allow nrpe_t usr_t:file { read getattr open ioctl };

Comment 3 smuskiew 2011-09-16 15:53:59 UTC
Sorry if this is a dumb question or I missed something in the various SELinux docs (I'm still learning it), but are there some docs that detail how I can apply your policy below and test it?  I *think* I need to use semanage but I'm a little confused as to what I need to do.

Thanks!

(In reply to comment #2)
> This works for me:
> 
> policy_module(nrpe-local,1.0)
> 
>  require {
>   class file { read getattr open ioctl };
>   type nrpe_t;
>   type rpm_exec_t;
>   type rpm_t;
>   type usr_t;
>  }
> 
>  domtrans_pattern(nrpe_t, rpm_exec_t, rpm_t)
>  allow nrpe_t usr_t:file { read getattr open ioctl };

Comment 4 Daniel Scott 2011-11-11 21:56:09 UTC
Seems to be a problem in F16 too:

type=1400 audit(1321048470.473:145): avc:  denied  { execute } for  pid=1580 comm="check_updates" name="rpm" dev=dm-0 ino=138898 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:rpm_exec_t:s0 tclass=file

Comment 5 Jose Pedro Oliveira 2011-11-14 20:05:56 UTC
Module generated by audit2allow in a EPEL6 system where the yum cache was cleared with "yum clean all" before the invocation of the check_updates nagios plugin via NRPE:

1) PRE: clean yum cache and audit log
   yum clean all
   /etc/init.d/auditd stop; mv /var/log/audit.log /tmp; /etc/init.d/auditd start

2) Invoke check updates (v1.5.0)

3) Generate
   cat /var/log/audit/audit.log | audit2allow -m nrpecheckupdates
----------

module nrpecheckupdates 1.0;

require {
	type tmp_t;
	type usr_t;
	type nrpe_t;
	type rpm_exec_t;
	type rpm_var_lib_t;
	class lnk_file read;
	class dir { write search getattr read remove_name add_name };
	class file { execute read lock create getattr execute_no_trans write ioctl unlink open };
}

#============= nrpe_t ==============
allow nrpe_t rpm_exec_t:file { ioctl execute read open getattr execute_no_trans };
allow nrpe_t rpm_var_lib_t:dir { search getattr };
allow nrpe_t rpm_var_lib_t:file open;
#!!!! The source type 'nrpe_t' can write to a 'dir' of the following types:
# var_run_t, nrpe_var_run_t, root_t

allow nrpe_t tmp_t:dir { read write add_name remove_name };
#!!!! The source type 'nrpe_t' can write to a 'file' of the following types:
# nrpe_var_run_t, root_t

allow nrpe_t tmp_t:file { write getattr read lock create unlink open };
allow nrpe_t usr_t:file { read getattr open ioctl };
allow nrpe_t usr_t:lnk_file read;
----------

Comment 6 Fedora End Of Life 2012-08-07 19:53:25 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Fedora End Of Life 2013-07-04 05:56:57 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Fedora End Of Life 2013-08-01 17:16:02 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.