Page 1 of 1
Solved - SELinux woes
Posted: Wed Dec 16, 2015 11:44 am
by 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
Re: SELinux woes
Posted: Wed Dec 16, 2015 5:47 pm
by 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
Re: SELinux woes
Posted: Thu Dec 17, 2015 8:51 am
by 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
Re: SELinux woes
Posted: Thu Dec 17, 2015 5:41 pm
by 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!
Re: SELinux woes
Posted: Fri Dec 18, 2015 1:19 pm
by 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
Re: SELinux woes
Posted: Fri Dec 18, 2015 1:33 pm
by 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
Re: SELinux woes
Posted: Fri Dec 18, 2015 4:52 pm
by 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
Re: Solved - SELinux woes
Posted: Mon Dec 21, 2015 10:18 am
by hsmith
Let us know if you come across anything else. Thanks!