Bug 1674258 - Nagios will not start due to SELinux denials
Summary: Nagios will not start due to SELinux denials
Keywords:
Status: ON_QA
Alias: None
Product: Fedora
Classification: Fedora
Component: nagios
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Stephen John Smoogen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-10 15:10 UTC by Russell Odom
Modified: 2019-02-26 05:19 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
File requested by comment #5 (185 bytes, text/plain)
2019-02-22 14:36 UTC, Edgar Hoch
no flags Details

Description Russell Odom 2019-02-10 15:10:01 UTC
Description of problem:
Nagios will not start with SELinux enabled.

Version-Release number of selected component (if applicable):
nagios-4.4.3-1.fc29.x86_64
selinux-policy-3.14.2-48.fc29.noarch

How reproducible:
Every time.

Steps to Reproduce:
1. `systemctl start nagios`

Actual results:
[root@host ~]# systemctl start nagios
Job for nagios.service failed because the control process exited with error code.
See "systemctl status nagios.service" and "journalctl -xe" for details.
[root@host ~]# systemctl status nagios
● nagios.service - Nagios Core 4.4.3
   Loaded: loaded (/usr/lib/systemd/system/nagios.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2019-02-10 14:44:33 GMT; 6s ago
     Docs: https://www.nagios.org/documentation
  Process: 6827 ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd (code=exited, status=0/SUCCESS)
  Process: 6826 ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg (code=exited, status=254)
  Process: 6825 ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg (code=exited, status=0/SUCCESS)

Feb 10 14:44:33 host.example.com nagios[6825]:         Checked 6 timeperiods
Feb 10 14:44:33 host.example.com nagios[6825]: Checking global event handlers...
Feb 10 14:44:33 host.example.com nagios[6825]: Checking obsessive compulsive processor commands...
Feb 10 14:44:33 host.example.com nagios[6825]: Checking misc settings...
Feb 10 14:44:33 host.example.com nagios[6825]: Total Warnings: 0
Feb 10 14:44:33 host.example.com nagios[6825]: Total Errors:   0
Feb 10 14:44:33 host.example.com nagios[6825]: Things look okay - No serious problems were detected during the pre-flight check
Feb 10 14:44:33 host.example.com systemd[1]: nagios.service: Control process exited, code=exited status=254
Feb 10 14:44:33 host.example.com systemd[1]: nagios.service: Failed with result 'exit-code'.
Feb 10 14:44:33 host.example.com systemd[1]: Failed to start Nagios Core 4.4.3.


Expected results:
Nagios starts OK, as it used to do (last time I rebooted this machine was 6 Jan, and it started then). Both nagios and selinux-policy have been updated since I last booted.

Additional info:
If I `setenforce 0` it starts OK (and if I subsequently `setenforce 1` it continues to run without problems). These lines are in the journal:

Feb 10 14:50:05 host.example.com kernel: audit: type=1400 audit(1549810205.473:1097): avc:  denied  { dac_override } for  pid=10633 comm="nagios" capability=1  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1
Feb 10 14:50:05 host.example.com kernel: audit: type=1300 audit(1549810205.473:1097): arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=558acca75c30 a2=20442 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null)
Feb 10 14:50:05 host.example.com kernel: audit: type=1400 audit(1549810205.474:1098): avc:  denied  { chown } for  pid=10633 comm="nagios" capability=0  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1
Feb 10 14:50:05 host.example.com kernel: audit: type=1300 audit(1549810205.474:1098): arch=c000003e syscall=93 success=yes exit=0 a0=3 a1=1e3 a2=1d3 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null)
Feb 10 14:50:05 host.example.com audit[10633]: AVC avc:  denied  { dac_override } for  pid=10633 comm="nagios" capability=1  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1
Feb 10 14:50:05 host.example.com audit[10633]: SYSCALL arch=c000003e syscall=257 success=yes exit=3 a0=ffffff9c a1=558acca75c30 a2=20442 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null)
Feb 10 14:50:05 host.example.com audit[10633]: AVC avc:  denied  { chown } for  pid=10633 comm="nagios" capability=0  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=1
Feb 10 14:50:05 host.example.com audit[10633]: SYSCALL arch=c000003e syscall=93 success=yes exit=0 a0=3 a1=1e3 a2=1d3 a3=1a4 items=0 ppid=1 pid=10633 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null)

Comment 1 Russell Odom 2019-02-10 15:20:20 UTC
Just looking deeper into the logs, I noticed this:
Feb 10 14:34:41 host.example.com nagios[1774]: Warning: Cannot open log file '/var/log/nagios/nagios.log' for writing
I assume that's what the SELinux errors relate to.

Comment 2 Kenyon Ralph 2019-02-12 02:28:59 UTC
Same on RHEL 7 with nagios-4.4.3-1.el7.x86_64 and nagios-selinux-4.4.3-1.el7.x86_64.

Comment 3 Stephen John Smoogen 2019-02-22 13:21:59 UTC
I didn't seem to get these emails til today. I am trying to figure out why my test systems didn't catch this. Can you do the following for me on yours:

ls -lZ /var/log/nagios/ /var/spool/nagios/ /var/run/nagios/

also does 

restorecon -n -r -v /var/log/nagios /var/spool/nagios /var/run/nagios

show any files that would be changed?

Comment 4 Edgar Hoch 2019-02-22 13:33:20 UTC
To comment #3:

# ls -lZ /var/log/nagios/ /var/spool/nagios/ /var/run/nagios/
/var/log/nagios/:
insgesamt 900
drwxr-x---. 2 nagios nagios system_u:object_r:nagios_log_t:s0  12288 22. Feb 00:00 archives
-rw-r--r--. 1 nagios nagios system_u:object_r:nagios_log_t:s0  97002 22. Feb 01:29 nagios.log
-rw-------. 1 nagios nagios system_u:object_r:nagios_log_t:s0 808216 22. Feb 01:29 retention.dat

/var/run/nagios/:
insgesamt 0

/var/spool/nagios/:
insgesamt 476
drwxrwx---. 2 nagios nagios system_u:object_r:nagios_spool_t:s0   4096 22. Feb 02:33 checkresults
drwxrwsr-x. 2 nagios nagios system_u:object_r:nagios_spool_t:s0   4096 22. Feb 01:29 cmd
-rw-r--r--. 1 nagios nagios system_u:object_r:nagios_spool_t:s0 477918 11. Feb 13:06 objects.cache
# restorecon -n -r -v /var/log/nagios /var/spool/nagios /var/run/nagios
# systemctl restart nagios
Job for nagios.service failed because the control process exited with error code.
See "systemctl status nagios.service" and "journalctl -xe" for details.
# systemctl status nagios
● nagios.service - Nagios Core 4.4.3
   Loaded: loaded (/usr/lib/systemd/system/nagios.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Fri 2019-02-22 14:28:21 CET; 1min 53s ago
     Docs: https://www.nagios.org/documentation
  Process: 6303 ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd (code=exited, status=0/SUCCESS)
  Process: 6302 ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg (code=exited, status=254)
  Process: 6301 ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg (code=exited, status=0/SUCCESS)


Feb 22 14:28:21 myhost.example.com nagios[6301]: Checking obsessive compulsive processor commands...
Feb 22 14:28:21 myhost.example.com nagios[6301]: Checking misc settings...
Feb 22 14:28:21 myhost.example.com nagios[6301]: Total Warnings: 0
Feb 22 14:28:21 myhost.example.com nagios[6301]: Total Errors:   0
Feb 22 14:28:21 myhost.example.com nagios[6301]: Things look okay - No serious problems were detected during the pre-flight check
Feb 22 14:28:21 myhost.example.com nagios[6302]: Failed to obtain lock on file /var/run/nagios/nagios.pid: Permission denied
Feb 22 14:28:21 myhost.example.com nagios[6302]: Bailing out due to errors encountered while attempting to daemonize... (PID=6302)
Feb 22 14:28:21 myhost.example.com systemd[1]: nagios.service: Control process exited, code=exited status=254
Feb 22 14:28:21 myhost.example.com systemd[1]: nagios.service: Failed with result 'exit-code'.
Feb 22 14:28:21 myhost.example.com systemd[1]: Failed to start Nagios Core 4.4.3.


From journalctl:

Feb 22 14:28:21 audit[6302]: AVC avc:  denied  { dac_override } for  pid=6302 comm="nagios" capability=1  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=0
Feb 22 14:28:21 nagios[6302]: Failed to obtain lock on file /var/run/nagios/nagios.pid: Permission denied
Feb 22 14:28:21 audit[6302]: AVC avc:  denied  { dac_override } for  pid=6302 comm="nagios" capability=1  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=0
Feb 22 14:28:21 audit[6302]: AVC avc:  denied  { dac_override } for  pid=6302 comm="nagios" capability=1  scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=capability permissive=0
Feb 22 14:28:21 nagios[6302]: Bailing out due to errors encountered while attempting to daemonize... (PID=6302)
Feb 22 14:28:21 systemd[1]: nagios.service: Control process exited, code=exited status=254
Feb 22 14:28:21 systemd[1]: nagios.service: Failed with result 'exit-code'.
Feb 22 14:28:21 systemd[1]: Failed to start Nagios Core 4.4.3.
Feb 22 14:28:21 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nagios comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
Feb 22 14:28:24 dbus-daemon[1178]: [system] Activating service name='org.fedoraproject.Setroubleshootd' requested by ':1.5' (uid=0 pid=1091 comm="/usr/sbin/sedispatch " label="system_u:system_r:auditd_t:s0") (using servicehelper)
Feb 22 14:28:25 dbus-daemon[1178]: [system] Successfully activated service 'org.fedoraproject.Setroubleshootd'
Feb 22 14:28:25 setroubleshoot[6306]: SELinux is preventing nagios from using the dac_override capability. For complete SELinux messages run: sealert -l 7bf4f44b-fb5d-40c9-a8fd-de15858bf598
Feb 22 14:28:25 python3[6306]: SELinux is preventing nagios from using the dac_override capability.
                               
                               *****  Plugin dac_override (91.4 confidence) suggests   **********************
                               
                               If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
                               Then turn on full auditing to get path information about the offending file and generate the error again.
                               Do
                               
                               Turn on full auditing
                               # auditctl -w /etc/shadow -p w
                               Try to recreate AVC. Then execute
                               # ausearch -m avc -ts recent
                               If you see PATH record check ownership/permissions on file, and fix it,
                               otherwise report as a bugzilla.
                               
                               *****  Plugin catchall (9.59 confidence) suggests   **************************
                               
                               If you believe that nagios should have the dac_override capability by default.
                               Then you should report this as a bug.
                               You can generate a local policy module to allow this access.
                               Do
                               allow this access for now by executing:
                               # ausearch -c 'nagios' --raw | audit2allow -M my-nagios
                               # semodule -X 300 -i my-nagios.pp
                               
Feb 22 14:28:25 setroubleshoot[6306]: SELinux is preventing nagios from using the dac_override capability. For complete SELinux messages run: sealert -l 7bf4f44b-fb5d-40c9-a8fd-de15858bf598
Feb 22 14:28:25 python3[6306]: SELinux is preventing nagios from using the dac_override capability.
                               
                               *****  Plugin dac_override (91.4 confidence) suggests   **********************
                               
                               If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system
                               Then turn on full auditing to get path information about the offending file and generate the error again.
                               Do
                               
                               Turn on full auditing
                               # auditctl -w /etc/shadow -p w
                               Try to recreate AVC. Then execute
                               # ausearch -m avc -ts recent
                               If you see PATH record check ownership/permissions on file, and fix it,
                               otherwise report as a bugzilla.
                               
                               *****  Plugin catchall (9.59 confidence) suggests   **************************
                               
                               If you believe that nagios should have the dac_override capability by default.
                               Then you should report this as a bug.
                               You can generate a local policy module to allow this access.
                               Do
                               allow this access for now by executing:
                               # ausearch -c 'nagios' --raw | audit2allow -M my-nagios
                               # semodule -X 300 -i my-nagios.pp

Comment 5 Stephen John Smoogen 2019-02-22 14:28:31 UTC
OK those perms match my system.. so something must be wrong on my side (aka either i or something else added a perm I missed). Could I ask one more step

ausearch -c 'nagios' --raw | audit2allow -M smooge-missed-a-big-thing

and attach the .te file? I would not install the semodule as hopefully I will push an update which will fix this.

Comment 6 Edgar Hoch 2019-02-22 14:36:29 UTC
Created attachment 1537581 [details]
File requested by comment #5

Comment 7 Stephen John Smoogen 2019-02-22 15:06:38 UTC
Thanks. That is saying that selinux is not letting this run because the process permissions aren't right somewhere. Adding the dac_override would be an atomic bomb which would cover up the real problem. [Basically if it is allowed dac_override it over rides all permissions and would make everything 7777 to nagios.]

The basic discretionary access controls on the file look all correct 640 and user/group nagios. So we need to see what it thinks it is running at. Could I ask for one more? This is what I have on the working box

[root@noc01 ~][PROD]# systemctl cat nagios.service
# /usr/lib/systemd/system/nagios.service
[Unit]
Description=Nagios Network Monitoring
After=network.target
Documentation=https://www.nagios.org/documentation/

[Service]
Type=forking
User=nagios
Group=nagios
PIDFile=/var/run/nagios/nagios.pid
# Verify Nagios config before start as upstream suggested
ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg
ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg
ExecStop=/bin/kill -TERM ${MAINPID}
ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd
ExecReload=/bin/kill -HUP ${MAINPID}

[Install]
WantedBy=multi-user.target

[root@noc01 ~][PROD]# ls -l /usr/lib/systemd/system/nagios*
-rw-r--r--. 1 root root 542 Nov 20  2017 /usr/lib/systemd/system/nagios.service

Comment 8 Edgar Hoch 2019-02-22 15:16:48 UTC
Thanks, Stephen. Of course, if it helps to solve the problem, I will try to help if I can.

# systemctl cat nagios.service
# /usr/lib/systemd/system/nagios.service
[Unit]
Description=Nagios Core 4.4.3
Documentation=https://www.nagios.org/documentation
After=network.target local-fs.target

[Service]
Type=forking
ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg
ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg
ExecStop=/usr/bin/kill -s TERM ${MAINPID}
ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd
ExecReload=/usr/bin/kill -s HUP ${MAINPID}

[Install]
WantedBy=multi-user.target
# ls -l /usr/lib/systemd/system/nagios*
-rw-r--r--. 1 root root 442 17. Jan 01:32 /usr/lib/systemd/system/nagios.service

Comment 9 Stephen John Smoogen 2019-02-22 15:34:05 UTC
Oh for the love of ... ok so the problem is that we lost the 

User=nagios
Group=nagios

and my test roll out replaced that file with one that had it.. so I had a working box and everyone else didn't.. I don't know what the testers who said it worked for them had..

I will roll out an update to updates-testing shortly.

Comment 10 Stephen John Smoogen 2019-02-22 16:01:23 UTC
I checked with the testers and they do not have the User= , have selinux running and are not seeing the issue. Could I ask one more thing while I try to figure this out on your box so I make sure I am fixing the right thing:

1. DO the following:

[root@noc01 ~][PROD]# ps axo euser,fuser,group,fgroup,command | grep sbin/nagios
root     root     root     root     grep --color=auto sbin/nagios
nagios   nagios   nagios   nagios   /usr/sbin/nagios -d /etc/nagios/nagios.cfg
nagios   nagios   nagios   nagios   /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh
nagios   nagios   nagios   nagios   /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh
nagios   nagios   nagios   nagios   /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh
nagios   nagios   nagios   nagios   /usr/sbin/nagios --worker /var/spool/nagios/cmd/nagios.qh
nagios   nagios   nagios   nagios   /usr/sbin/nagios -d /etc/nagios/nagios.cfg


2. Test if doing the following fixes the problem on your box

cp -av /usr/lib/systemd/system/nagios.service /usr/lib/systemd/system/nagios.service.temp
edit /usr/lib/systemd/system/nagios.service and add the User and Group


# /usr/lib/systemd/system/nagios.service
[Unit]
Description=Nagios Core 4.4.3
Documentation=https://www.nagios.org/documentation
After=network.target local-fs.target

[Service]
Type=forking
User=nagios
Group=nagios
ExecStartPre=/usr/sbin/nagios -v /etc/nagios/nagios.cfg
ExecStart=/usr/sbin/nagios -d /etc/nagios/nagios.cfg
ExecStop=/usr/bin/kill -s TERM ${MAINPID}
ExecStopPost=/usr/bin/rm -f /var/spool/nagios/cmd/nagios.cmd
ExecReload=/usr/bin/kill -s HUP ${MAINPID}

[Install]
WantedBy=multi-user.target

# systemctl daemon-reload
# systemctl restart nagios

If that gets it working again then I can be sure my fix will work. You can put back the original file afterwords as needed.

Comment 11 Edgar Hoch 2019-02-22 16:16:32 UTC
There is no nagios process running, because it didn't start previously.

After adding User and Group options to nagios.service, nagios starts again. I don't find SELinux error logs about nagios in the logs.

So I think this solves the problem.

Thanks!

Comment 12 Stephen John Smoogen 2019-02-22 16:28:38 UTC
Oh sorry I thought that you had one running from a setenforce 0 and then starting it.

Comment 13 Kenyon Ralph 2019-02-22 17:31:33 UTC
Stephen, can't you easily reproduce this on a fresh Fedora or RHEL install?

Comment 14 Fedora Update System 2019-02-22 17:36:00 UTC
nagios-4.4.3-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-431b7a7aa8

Comment 15 Stephen John Smoogen 2019-02-22 17:45:01 UTC
I probably could but it would be next week before I had time to set up said environments. Asking questions while dealing with the other fires seemed at the time useful.. but I can see where everyone else getting yet another update would get tired of it. Packages should be in EPEL and F2x testing in the next 48 hours. Please test and if you have a Fedora Account give karma so it doesn't sit for 2-3 weeks before it gets pushed.

Comment 16 Kenyon Ralph 2019-02-22 17:56:34 UTC
It's not tiring, just seems like it would be easier if you reproduce the problems and test the changes yourself rather than guessing. Just a quick default Fedora install using GNOME Boxes or "virt-install --name fedora --memory 8192 --disk size=10 --cdrom ~/Downloads/Fedora-Server-netinst-x86_64-29-1.2.iso --virt-type kvm --os-variant fedora26 --network bridge=br0" would do it.

Comment 17 Fedora Update System 2019-02-22 17:59:33 UTC
nagios-4.4.3-4.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d3112aae3

Comment 18 Fedora Update System 2019-02-22 18:11:21 UTC
nagios-4.4.3-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb

Comment 19 Fedora Update System 2019-02-23 00:10:24 UTC
nagios-4.4.3-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb

Comment 20 Fedora Update System 2019-02-23 02:04:09 UTC
nagios-4.4.3-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-431b7a7aa8

Comment 21 Fedora Update System 2019-02-23 02:45:12 UTC
nagios-4.4.3-4.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-6d3112aae3

Comment 22 Kenyon Ralph 2019-02-26 04:09:39 UTC
As mentioned at https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-900273 now there are new SELinux denials with nagios-4.4.3-4.el7, possibly related to Bug #1592594:

SELinux is preventing /usr/sbin/httpd from getattr access on the file /var/spool/nagios/status.dat.
type=AVC msg=audit(1551152845.860:270): avc:  denied  { getattr } for  pid=2176 comm="httpd" path="/var/spool/nagios/status.dat" dev="dm-3" ino=2114580 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nagios_spool_t:s0 tclass=file

SELinux is preventing /usr/sbin/httpd from read access on the file /var/spool/nagios/status.dat.
type=AVC msg=audit(1551152845.861:271): avc:  denied  { read } for  pid=2176 comm="httpd" name="status.dat" dev="dm-3" ino=2114580 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nagios_spool_t:s0 tclass=file

SELinux is preventing /usr/lib64/nagios/cgi-bin/statusjson.cgi from read access on the file /var/spool/nagios/objects.cache.
type=AVC msg=audit(1551152846.15:272): avc:  denied  { read } for  pid=2391 comm="statusjson.cgi" name="objects.cache" dev="dm-3" ino=2114578 scontext=system_u:system_r:nagios_script_t:s0 tcontext=system_u:object_r:nagios_spool_t:s0 tclass=file

Comment 23 Kenyon Ralph 2019-02-26 04:33:12 UTC
Correction to my previous comment: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-900327

These "new" SELinux denials happened for me because in my testing of nagios-4.4.3-4.el7, I didn't include updated selinux-policy packages.

Comment 24 Kenyon Ralph 2019-02-26 05:19:08 UTC
(In reply to Kenyon Ralph from comment #23)
> Correction to my previous comment:
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-
> 900327
> 
> These "new" SELinux denials happened for me because in my testing of
> nagios-4.4.3-4.el7, I didn't include updated selinux-policy packages.

Correction again. Even using the selinux-policy packages from RHEL 7.5, still getting denials with nagios-4.4.3-4.el7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9bad34efbb#comment-900328

So my testing environment for nagios-4.4.3-4.el7 is exactly the same as my environment where nagios-4.3.4-5.el7 works fine. So something is still wrong about the SELinux policy coming from nagios-4.4.3-4.el7.


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