Bug 565220 - SELinux is preventing /usr/sbin/nrpe "dac_override" access .
Summary: SELinux is preventing /usr/sbin/nrpe "dac_override" access .
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nrpe
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:f729ac280db...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-02-13 20:21 UTC by gregor
Modified: 2010-11-09 18:02 UTC (History)
10 users (show)

Fixed In Version: nrpe-2.12-16.el4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-04 23:29:19 UTC


Attachments (Terms of Use)

Description gregor 2010-02-13 20:21:00 UTC
Zusammenfassung:

SELinux is preventing /usr/sbin/nrpe "dac_override" access .

Detaillierte Beschreibung:

SELinux denied access requested by nrpe. It is not expected that this access is
required by nrpe and this access may signal an intrusion attempt. It is also
possible that the specific version or configuration of the application is
causing it to require additional access.

Zugriff erlauben:

You can generate a local policy module to allow this access - see FAQ
(http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug
report.

Zusätzliche Informationen:

Quellkontext                  unconfined_u:system_r:nrpe_t:s0
Zielkontext                   unconfined_u:system_r:nrpe_t:s0
Zielobjekte                   None [ capability ]
Quelle                        nrpe
Quellen-Pfad                  /usr/sbin/nrpe
Port                          <Unbekannt>
Host                          (removed)
Quellen-RPM-Pakete            nrpe-2.12-12.fc12
Ziel-RPM-Pakete               
RPM-Richtlinie                selinux-policy-3.6.32-84.fc12
SELinux aktiviert             True
Richtlinienversion            targeted
Enforcing-Modus               Enforcing
Plugin-Name                   catchall
Hostname                      (removed)
Plattform                     Linux (removed) 2.6.31.12-174.2.3.fc12.x86_64 #1 SMP
                              Mon Jan 18 19:52:07 UTC 2010 x86_64 x86_64
Anzahl der Alarme             2
Zuerst gesehen                Sa 13 Feb 2010 21:20:03 CET
Zuletzt gesehen               Sa 13 Feb 2010 21:20:03 CET
Lokale ID                     109e8262-9002-4554-9554-e9343d1b0ad2
Zeilennummern                 

Raw-Audit-Meldungen           

node=(removed) type=AVC msg=audit(1266092403.666:136): avc:  denied  { dac_override } for  pid=3956 comm="nrpe" capability=1 scontext=unconfined_u:system_r:nrpe_t:s0 tcontext=unconfined_u:system_r:nrpe_t:s0 tclass=capability

node=(removed) type=AVC msg=audit(1266092403.666:136): avc:  denied  { dac_read_search } for  pid=3956 comm="nrpe" capability=2 scontext=unconfined_u:system_r:nrpe_t:s0 tcontext=unconfined_u:system_r:nrpe_t:s0 tclass=capability

node=(removed) type=SYSCALL msg=audit(1266092403.666:136): arch=c000003e syscall=2 success=no exit=-13 a0=609600 a1=0 a2=1b6 a3=0 items=0 ppid=3955 pid=3956 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="nrpe" exe="/usr/sbin/nrpe" subj=unconfined_u:system_r:nrpe_t:s0 key=(null)



Hash String generated from  catchall,nrpe,nrpe_t,nrpe_t,capability,dac_override
audit2allow suggests:

#============= nrpe_t ==============
allow nrpe_t self:capability { dac_read_search dac_override };

Comment 1 Anthony Messina 2010-07-27 19:26:44 UTC
I see this on Fedora 13 x86_64 as well with selinux-policy-targeted-3.7.19-39.fc13.noarch

Comment 2 Daniel Walsh 2010-07-27 20:37:39 UTC
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

Comment 3 Anthony Messina 2010-07-27 20:50:59 UTC
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.

Comment 4 Daniel Walsh 2010-07-28 15:30:45 UTC
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

Comment 5 Anthony Messina 2010-07-28 16:21:18 UTC
[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

Comment 6 Daniel Walsh 2010-07-28 16:50:57 UTC
Any ideas guys?

Comment 7 Anthony Messina 2010-07-28 17:43:22 UTC
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.

Comment 8 Anthony Messina 2010-07-28 17:51:56 UTC
(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.

Comment 9 Daniel Walsh 2010-07-28 17:56:53 UTC
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.

Comment 10 Anthony Messina 2010-07-28 18:08:20 UTC
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 ;)

Comment 11 Daniel Walsh 2010-07-28 18:43:58 UTC
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.

Comment 12 Anthony Messina 2010-07-28 19:52:04 UTC
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.

Comment 13 Fedora Update System 2010-09-12 05:59:49 UTC
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

Comment 14 Fedora Update System 2010-09-12 05:59:56 UTC
nrpe-2.12-14.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nrpe-2.12-14.fc14

Comment 15 Fedora Update System 2010-09-12 06:00:03 UTC
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

Comment 16 Fedora Update System 2010-09-12 06:00:09 UTC
nrpe-2.12-14.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/nrpe-2.12-14.fc13

Comment 17 Fedora Update System 2010-09-12 06:00:15 UTC
nrpe-2.12-14.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/nrpe-2.12-14.fc12

Comment 18 Fedora Update System 2010-09-12 18:24:33 UTC
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

Comment 19 Fedora Update System 2010-09-12 18:24:38 UTC
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

Comment 20 Fedora Update System 2010-09-23 12:31:42 UTC
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.

Comment 21 Fedora Update System 2010-09-24 20:34:38 UTC
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.

Comment 22 Fedora Update System 2010-09-24 20:45:26 UTC
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.

Comment 23 Fedora Update System 2010-09-27 16:59:13 UTC
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.

Comment 24 Fedora Update System 2010-09-27 16:59:32 UTC
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.

Comment 25 James Ralston 2010-10-22 18:31:52 UTC
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.)

Comment 26 Peter Lemenkov 2010-10-25 11:29:48 UTC
Confirmed - I'll fix it shortly.

Comment 27 Fedora Update System 2010-10-25 11:57:36 UTC
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

Comment 28 Fedora Update System 2010-10-25 11:57:46 UTC
nrpe-2.12-16.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/nrpe-2.12-16.fc13

Comment 29 Fedora Update System 2010-10-25 11:57:55 UTC
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

Comment 30 Fedora Update System 2010-10-25 11:58:02 UTC
nrpe-2.12-16.fc12 has been submitted as an update for Fedora 12.
https://admin.fedoraproject.org/updates/nrpe-2.12-16.fc12

Comment 31 Fedora Update System 2010-10-25 11:58:10 UTC
nrpe-2.12-16.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/nrpe-2.12-16.fc14

Comment 32 Fedora Update System 2010-10-25 16:37:26 UTC
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

Comment 33 Bug Zapper 2010-11-03 22:10:38 UTC
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

Comment 34 Fedora Update System 2010-11-04 23:29:13 UTC
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.

Comment 35 Fedora Update System 2010-11-04 23:47:21 UTC
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.

Comment 36 Fedora Update System 2010-11-04 23:48:51 UTC
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.

Comment 37 Fedora Update System 2010-11-09 18:01:59 UTC
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.

Comment 38 Fedora Update System 2010-11-09 18:02:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.