Solved - SELinux woes

[bgee11]

Hello everyone -

I have been fighting a problem with Nagios this morning. I can confirm that SELinux is causing the problem. For short term it is acceptable to set "Permissive" mode, but for long term we need to have SELinux running.

The problem started when I upgraded the Nagios host server from CentOS 7.2 to 7.3. That brought in a major new version of Nagios. My environment looks like this:

OS = CentOS 7 64-bit, kernel = 3.10.0-327.3.1
Nagios = version 4.0.8-1 installed from CentOS repository

The error message from /var/log/nagios/nagios.log:

Code: Select all

[1450277255] Nagios 4.0.8 starting... (PID=23335)
[1450277255] Local time is Wed Dec 16 08:47:35 CST 2015
[1450277255] LOG VERSION: 2.0
[1450277255] qh: Failed to init socket '/var/log/nagios/rw/nagios.qh'. unlink()
failed: Permission denied
[1450277255] Error: Failed to initialize query handler. Aborting

In the course of troubleshooting I found that the "rw" directory did not exist. I created the directory, assigned owner and group as nagios and gave it 0755 permissions. Restorecon does not know what to assign to the directory, so it will not change any of the SELinux contexts. I manually assigned the directory the same SELinux contexts as other directories around it.

Code: Select all

[root@itdata nagios]# ll -Z /var/log/nagios
drwxr-x---. nagios nagios system_u:object_r:nagios_log_t:s0 archives
-rw-r--r--. nagios nagios system_u:object_r:nagios_log_t:s0 nagios.log
-rw-r--r--. nagios nagios system_u:object_r:nagios_log_t:s0 objects.cache
-rw-------. nagios nagios system_u:object_r:nagios_log_t:s0 retention.dat
drwxr-xr-x. nagios nagios system_u:object_r:nagios_log_t:s0 rw
drwxr-x---. nagios nagios system_u:object_r:nagios_log_t:s0 spool
-rw-rw-r--. nagios nagios system_u:object_r:nagios_log_t:s0 status.dat

[root@itdata nagios]# ll -Z rw
srw-rw----. nagios nagios system_u:object_r:nagios_log_t:s0 nagios.qh

However - Even with this SELinux context setting - if I set SELinux to Enforcing then Nagios will not start.

What should the SELinux context and permissions be for the rw directory?

Thanks - Bill Gee

[tgriep]

Take a look at the link below, it has some instructions for enforcing SELinux. Let us know if this helps.
https://assets.nagios.com/downloads/nag ... edora.html

[bgee11]

Hi tgriep -

Thanks for the link. I don't think that is any help, for two reasons. First, it references a very old version of Fedora Core, and I am using the latest CentOS 7. Second, it only addresses SELinux settings in regard to the http CGI directories. I do not have a problem there. My problem is elsewhere in the file system.

Regards - Bill Gee

[jolson]

The directory issue is a known upgrade problem with the EPEL repository - like you stated, simply creating the directory is enough to resolve the problem when we're not dealing with SELinux.

What we need to do is ensure that the 'nagios' process has proper permissions to write to the /var/log/nagios/rw directory.

Everything already has the nagios_log_t type, but the 'rw' directory in particular may need a different context. What does your SELinux audit log say? Since you're running SELinux in permissive mode you should get some good error output:

Code: Select all

tail -n50 /var/log/audit/audit.log

For a more human-readable format, use the following:

Code: Select all

yum install setroubleshoot-server
sealert

Look for any relevant denials, as those will need to be addressed.

Typically the audit log contains instructions about how the context needs to be changed. Let us know what the content of that log file is. Thanks!

[bgee11]

Hi jolson -

Here are some relevant entries from audit.log.1:

Code: Select all

type=AVC msg=audit(1450275542.294:1058): avc:  denied  { connectto } for  pid=12279 comm="nagios" path="/var/log/nagios/rw/nagios.qh" scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=unix_stream_socket
type=AVC msg=audit(1450277296.579:1287): avc:  denied  { connectto } for  pid=23375 comm="nagios" path="/var/log/nagios/rw/nagios.qh" scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:system_r:nagios_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1450277296.579:1287): arch=c000003e syscall=42 success=yes exit=0 a0=3 a1=7ffed927e9f0 a2=1e a3=fffff000 items=0 ppid=23372 pid=23375 auid=4294967295 uid=996 gid=994 euid=996 suid=996 fsuid=996 egid=994 sgid=994 fsgid=994 tty=(none) ses=4294967295 comm="nagios" exe="/usr/sbin/nagios" subj=system_u:system_r:nagios_t:s0 key=(null)

When I run it through sealert, I get several items like this:

Code: Select all

SELinux is preventing /usr/sbin/nagios from create access on the sock_file nagios.qh.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that nagios should be allowed create access on the nagios.qh sock_file 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:
# grep nagios /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp


Additional Information:
Source Context                system_u:system_r:nagios_t:s0
Target Context                system_u:object_r:nagios_log_t:s0
Target Objects                nagios.qh [ sock_file ]
Source                        nagios
Source Path                   /usr/sbin/nagios
Port                          <Unknown>
Host                          <Unknown>
Source RPM Packages           nagios-4.0.8-1.el7.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.13.1-60.el7.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     itdata.kckpl.org
Platform                      Linux itdata.kckpl.org 3.10.0-327.3.1.el7.x86_64
                              #1 SMP Wed Dec 9 14:09:15 UTC 2015 x86_64 x86_64
Alert Count                   6
First Seen                    2015-12-16 07:48:18 CST
Last Seen                     2015-12-16 08:48:16 CST
Local ID                      6492c93f-9845-4f8c-82ed-2bbedd87bdc3

Raw Audit Messages
type=AVC msg=audit(1450277296.577:1286): avc:  denied  { create } for  pid=23372 comm="nagios" name="nagios.qh" scontext=system_u:system_r:nagios_t:s0 tcontext=system_u:object_r:nagios_log_t:s0 tclass=sock_file


type=SYSCALL msg=audit(1450277296.577:1286): arch=x86_64 syscall=bind success=yes exit=0 a0=4 a1=7ffe6b09a330 a2=1e a3=8 items=0 ppid=1 pid=23372 auid=4294967295 uid=996 gid=994 euid=996 suid=996 fsuid=996 egid=994 sgid=994 fsgid=994 tty=(none) ses=4294967295 comm=nagios exe=/usr/sbin/nagios subj=system_u:system_r:nagios_t:s0 key=(null)

Hash: nagios,nagios_t,nagios_log_t,sock_file,create

The most interesting thing I see here is the difference between the Source Context and the Target Context. Is that a problem?

I ran the suggested audit2allow command. It generated a .pp file, but being binary I could not tell much about what it is really doing. I did not apply the new policy.

Thanks - Bill Gee

[jolson]

You can view the .pp file, but it's a faily complicated process: http://serverfault.com/questions/321301 ... cy-package

If you need to view the contents of the file before applying the policy, please feel free to - otherwise I recommend applying the recommended policies and leaving the system in a permissive state. After that, restart Nagios and check to see if audit.log complains about anything else - if not, attempt to move to enforcing mode.

The most interesting thing I see here is the difference between the Source Context and the Target Context. Is that a problem?

While it's not necessarily a problem, it does allow the nagios process to access anything with the system_u:object_r:nagios_log_t:s0 context. I can't think of any security implications of doing so, I would have no problem moving forward with the procedure.

Let me know what you find out, thanks!

Jesse

[bgee11]

Hi Jesse -

I found that the audit2allow process also spit out a file called "mypol.te". Plain text, and it gives a reasonable description of the changes.

I went ahead and put in the policy, set SELinux to enforcing and then restarted Nagios. No errors in the nagios.log file, and the web page comes up as it should. I will keep an eye on it for a few days just to be sure, but this looks like a usable fix.

I agree the security implications of this change are pretty minor. The host machine is char-mode only (no GUI) and is never used for Internet browsing. Indeed, it is not even visible from the internet.

Thanks - Bill Gee

[hsmith]

Let us know if you come across anything else. Thanks!