Bug 538565
| Summary: | New 'nrpe' policy prevents most NRPE checks from working | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ben Webb <benmwebb> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | dwalsh, mgrepl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.6.32-120.fc12 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-12-07 22:46:33 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: | |||
The access required is allow nrpe_t fixed_disk_device_t:blk_file read; allow nrpe_t fs_t:filesystem getattr; allow nrpe_t init_t:dir getattr; allow nrpe_t kernel_t:dir getattr; Everything is ok to add except the first one which would give nrpe the ability to read everything on the box. allow nrpe_t fixed_disk_device_t:blk_file read; I guess the question is whether this access is really necessary. The rest will be Fixed in selinux-policy-3.6.32-47.fc12.noarch Well, the Fedora-packaged check_ide_smart plugin needs access to the disk device to check the SMART status. This is why it is setuid: # ls -l /usr/lib64/nagios/plugins/check_ide_smart -rwsr-x---. 1 root nrpe 31280 2009-08-21 08:01 /usr/lib64/nagios/plugins/check_ide_smart Presumably standard Unix permissions on the nrpe user/group prevent non-setuid plugins from doing anything nefarious with that SELinux access. But the setuid plugins would appear to need it. Is there a finer-grained SELinux permission that can be added to allow checking the SMART status without allowing access to the whole disk? Or is the plugin perhaps asking for more privileges than it needs (in which case, I can certainly open a bug against that package)? For reference, the (largely unrelated) check_ide_smart bug I refer to is bug 469530. I think we need a policy type for check_ide_smart and only give it the permission to read the fixed_disk. Fixed in selinux-policy-3.6.32-48.fc12.noarch selinux-policy-3.6.32-52.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-52.fc12 selinux-policy-3.6.32-52.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12549 selinux-policy-3.6.32-55.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-55.fc12 selinux-policy-3.6.32-55.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12650 selinux-policy-3.6.32-55.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. selinux-policy-3.6.32-120.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-120.fc12 selinux-policy-3.6.32-120.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: In Fedora 12, the nrpe daemon appears to have been confined and policy defined for it. This prevents most of our checks from working (they all worked fine with no custom policy required in Fedora 11). NRPE can be expected to do pretty much everything that Nagios might do, so probably its policy should be similar to that for Nagios. Version-Release number of selected component (if applicable): selinux-policy-3.6.32-41.fc12.noarch nrpe-2.12-11.fc12.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install the nrpe, nagios-plugins-nrpe, nagios-plugins-disk, nagios-plugins-procs, nagios-plugins-ide_smart packages. 2. Note that you may have to change /usr/lib64/nagios/plugins/check_ide_smart to be chmod u+s, owned by root:nrpe (this is a separate bug, with an open Bugzilla report, not relevant to this problem). 3. Add some suitable command definitions to /etc/nagios/nrpe.cfg, such as command[check_sysdisks]=/usr/lib64/nagios/plugins/check_disk -E -w 10% -c 5% -p / -p /usr -p /var command[check_zombie_procs]=/usr/lib64/nagios/plugins/check_procs -w 5 -c 10 -s Z command[check_smart_sda]=/usr/lib64/nagios/plugins/check_ide_smart -n -d /dev/sda 4. Start the nrpe daemon. 5. Connect to the daemon (as any non-root user) and have it run the check_disk plugin: $ /usr/lib64/nagios/plugins/check_nrpe -H localhost -c check_sysdisks Actual results: SELinux prevents NRPE from accessing the filesystem: Nov 18 11:47:38 clarinet kernel: type=1400 audit(1258573658.945:31312): avc: denied { getattr } for pid=20217 comm="check_disk" name="/" dev=sda1 ino=2 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem Nov 18 11:47:38 clarinet kernel: type=1400 audit(1258573658.945:31313): avc: denied { getattr } for pid=20217 comm="check_disk" name="/" dev=sda2 ino=2 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem Nov 18 11:47:38 clarinet kernel: type=1400 audit(1258573658.945:31314): avc: denied { getattr } for pid=20217 comm="check_disk" name="/" dev=sda3 ino=2 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem Consequently, the check returns all zeroes, which is not correct: DISK CRITICAL - free space: / 0 MB (0% inode=0%); /usr 0 MB (0% inode=0%); /var 0 MB (0% inode=0%);| /=0MB;0;0;0;0 /usr=0MB;0;0;0;0 /var=0MB;0;0;0;0 Expected results: No avcs, and output from check_nrpe of the form: DISK OK - free space: / 2946 MB (78% inode=91%); /usr 8127 MB (62% inode=79%); /var 3224 MB (86% inode=95%);| /=791MB;3543;3740;0;3937 /usr=4954MB;12402;13091;0;13781 /var=513MB;3543;3740;0;3937 Additional info: Similar problems occur with the other checks: $ /usr/lib64/nagios/plugins/check_nrpe -H localhost -c check_zombie_procs gives Nov 18 11:59:42 clarinet kernel: type=1400 audit(1258574382.264:31560): avc: denied { getattr } for pid=20280 comm="ps" path="/proc/1" dev=proc ino=5101 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=dir Nov 18 11:59:42 clarinet kernel: type=1400 audit(1258574382.264:31561): avc: denied { getattr } for pid=20280 comm="ps" path="/proc/2" dev=proc ino=5102 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir Nov 18 11:59:42 clarinet kernel: type=1400 audit(1258574382.264:31562): avc: denied { getattr } for pid=20280 comm="ps" path="/proc/3" dev=proc ino=5103 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir Nov 18 11:59:42 clarinet kernel: type=1400 audit(1258574382.264:31563): avc: denied { getattr } for pid=20280 comm="ps" path="/proc/4" dev=proc ino=5104 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=dir (and so on for every process on the system) $ /usr/lib64/nagios/plugins/check_nrpe -H localhost -c check_smart_sda gives Nov 18 12:00:49 clarinet kernel: type=1400 audit(1258574449.388:31805): avc: denied { read } for pid=20289 comm="check_ide_smart" name="sda" dev=tmpfs ino=3461 scontext=system_u:system_r:nrpe_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file I have a set of custom Nagios plugins too which are similarly affected (e.g. ones that check for package updates no longer work because they can't read the RPM database). I can certainly add custom policy for these, but it seems odd that the standard Fedora-packaged Nagios plugins no longer work with NRPE.