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.
There is the same problem in RHEL6 - EPEL.
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 };
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 };
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
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; ----------
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
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.
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.