Bug 565220
| Summary: | SELinux is preventing /usr/sbin/nrpe "dac_override" access . | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | gregor <gregor.binder> |
| Component: | nrpe | Assignee: | Peter Lemenkov <lemenkov> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | amessina, dwalsh, eparis, jmorris, jose.p.oliveira.oss, lemenkov, mgrepl, ondrejj, ralston, sebastian.gosenheimer |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:f729ac280dbe5d8e4066909d2356e0870f683f7e44a9b4d95eb97f19e1e00b12 | ||
| Fixed In Version: | nrpe-2.12-16.el4 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-04 23:29:19 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
gregor
2010-02-13 20:21:00 UTC
I see this on Fedora 13 x86_64 as well with selinux-policy-targeted-3.7.19-39.fc13.noarch Some file that nrpe is trying to access is not allowed to read by root. Can you add this command auditctl -w /etc/shadow -p w And see if you can generate the error again. Then you should get a path with the next avc message. Please attach the message node=mythtv-fe1.chicago.messinet.com type=AVC msg=audit(1280263762.66:23157): avc: denied { dac_override } for pid=6166 comm="nrpe" capability=1 scontext=unconfined_u:system_r:nrpe_t:s0 tcontext=unconfined_u:system_r:nrpe_t:s0 tclass=capability
node=mythtv-fe1.chicago.messinet.com type=SYSCALL msg=audit(1280263762.66:23157): arch=c000003e syscall=2 success=no exit=-13 a0=173f380 a1=41 a2=1a4 a3=4000 items=1 ppid=1 pid=6166 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nrpe" exe="/usr/sbin/nrpe" subj=unconfined_u:system_r:nrpe_t:s0 key=(null)
node=mythtv-fe1.chicago.messinet.com type=CWD msg=audit(1280263762.66:23157): cwd="/"
node=mythtv-fe1.chicago.messinet.com type=PATH msg=audit(1280263762.66:23157): item=0 name="/var/run/nrpe/nrpe.pid" inode=1048782 dev=08:03 mode=040755 ouid=495 ogid=485 rdev=00:00 obj=system_u:object_r:var_run_t:s0
Also, should I "turn off" the auditctl? If so, how? I haven't used that before.
Next time you reboot it will shut off. Or if you are not overly concerned about CPU performance, add that line to /etc/audit/audit.rules. cat "-w /etc/shadow -p w" >> /etc/audit/audit.rules This turns on full auditing, so you will always get the full path. I run with auditing turned on all the time. I never notice the performance hit on my laptop. Any ways it looks like /var/run/nrpe/nrpe.pid has permissions that root can not access. ls -l /var/run/nrpe/nrpe.pid [root@mythtv-fe1 ~]# ls -l /var/run/nrpe/nrpe.pid -rw-r--r--. 1 root root 5 Jul 28 11:15 /var/run/nrpe/nrpe.pid [root@mythtv-fe1 ~]# ls -lZ /var/run/nrpe/nrpe.pid -rw-r--r--. root root unconfined_u:object_r:nrpe_var_run_t:s0 /var/run/nrpe/nrpe.pid [root@mythtv-fe1 ~]# ls -lZ /var/run/nrpe -rw-r--r--. root root unconfined_u:object_r:nrpe_var_run_t:s0 nrpe.pid Any ideas guys? What does "dac_override" mean anyway? That might help me debug on my end. I'm guessing "Discretionary Access Control (permission) Override", meaning that regardless of file permissions, if something can dac_override, it will proceed (if root)? If so, I think I have it, though I don't know why. In /etc/nagios/nrpe.cfg, the config option lists: pid_file=/var/run/nrpe/nrpe.pid In /var/run, the 'nrpe' directory is owned 0755 by nrpe:nrpe If I change the ownership from nrpe:nrpe to root:nrpe, it works without error AND the pid file actually gets created. I'm not sure why root wouldn't be able to access that dir if the ownership is set to nrpe:nrpe. (In reply to comment #7) > In /var/run, the 'nrpe' directory is owned 0755 by nrpe:nrpe > > If I change the ownership from nrpe:nrpe to root:nrpe, it works without error > AND the pid file actually gets created. It looks like this pid file gets created by the daemon itself, not the init script. Ownership begins as root:root, then the nrpe daemon switches to the nrpe user. Upon /etc/init.d/nrpe stop, the nrpe user has no way to remove the pid file, since it's owned by root. This looks to me to be a problem partially with nrpe itself or the initscript, not just SELinux. If you add root to the nrpe group it would probably fix the problem. Or change the permission to 775 root:nrpe DAC_OVERRIDE is the capability UID=0 user uses to look at files, that it does not have permission to look at. Thanks for the explanation. With the following (nrpe started in permissive mode): [root@linux-ws1 run]# ls -al nrpe total 12 drwxr-xr-x. 2 nrpe nrpe 4096 Jul 28 13:02 . drwxr-xr-x. 32 root root 4096 Jul 28 11:20 .. -rw-r--r--. 1 root root 5 Jul 28 13:02 nrpe.pid Shouldn't root be able to access this file without dac_override? It seems strange to have root be a part of a lesser-privileged group. Your suggesion regarding permissions in comment #9 works to start nrpe, but the nrpe daemon switches to the nrpe user and can't remove the nrpe.pid file on stop. To me it seems like this is a case of SELinux exposing some programming issues in another program rather than a problem with SELinux itself ;) Root's privs are broken down into a series of capabilities, documented in /usr/include/sys/capability Root process can drop capabilities and then root looses its power. If the root process does not have DAC_OVERRIDE or DAC_READ_SEARCH it becomes like any other UID. If the 0 is not allowed access via the owner, group or other access, then it is denied. Since SELinux denies all capabilities by default, we expose when root tries to take advantage of its powers. What about labeling the directory 775 O:nrpe G:root Then it should work. Thanks Dan. The following works: [root@linux-ws1 run]# ls -al |grep nrpe drwxrwxr-x. 2 root nrpe 4096 Jul 28 14:46 nrpe I guess this should go over to the nrpe folks to update the nrpe.spec file: http://cvs.fedoraproject.org/viewvc/rpms/nrpe/F-13/nrpe.spec?revision=1.18&view=markup Line 125: %dir %attr(775, root, nrpe) %{_localstatedir}/run/nrpe Then it works on both start and stop. nrpe-2.12-14.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/nrpe-2.12-14.el5 nrpe-2.12-14.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nrpe-2.12-14.fc14 nrpe-2.12-14.el4 has been submitted as an update for Fedora EPEL 4. https://admin.fedoraproject.org/updates/nrpe-2.12-14.el4 nrpe-2.12-14.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/nrpe-2.12-14.fc13 nrpe-2.12-14.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/nrpe-2.12-14.fc12 nrpe-2.12-14.el5 has been pushed to the Fedora EPEL 5 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 nrpe'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nrpe-2.12-14.el5 nrpe-2.12-14.el4 has been pushed to the Fedora EPEL 4 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 nrpe'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nrpe-2.12-14.el4 nrpe-2.12-14.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-14.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-14.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-14.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-14.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report. Alas, this was not fixed properly. The spec file now has this line in the %files section:
%dir %attr(755, root, nrpe) %{_localstatedir}/run/nrpe
^
But that needs to be:
%dir %attr(775, root, nrpe) %{_localstatedir}/run/nrpe
^
As a result, nrpe still can't remove its pid file when it shuts down.
(I checked EPEL5, F14, and rawhide, so I'm guessing this is wrong in all repositories.)
Confirmed - I'll fix it shortly. nrpe-2.12-16.el5 has been submitted as an update for Fedora EPEL 5. https://admin.fedoraproject.org/updates/nrpe-2.12-16.el5 nrpe-2.12-16.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/nrpe-2.12-16.fc13 nrpe-2.12-16.el4 has been submitted as an update for Fedora EPEL 4. https://admin.fedoraproject.org/updates/nrpe-2.12-16.el4 nrpe-2.12-16.fc12 has been submitted as an update for Fedora 12. https://admin.fedoraproject.org/updates/nrpe-2.12-16.fc12 nrpe-2.12-16.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/nrpe-2.12-16.fc14 nrpe-2.12-16.el5 has been pushed to the Fedora EPEL 5 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 nrpe'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/nrpe-2.12-16.el5 This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 nrpe-2.12-16.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-16.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-16.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-16.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. nrpe-2.12-16.el4 has been pushed to the Fedora EPEL 4 stable repository. If problems still persist, please make note of it in this bug report. |