Yesterday I warned everyone not to disable SELinux because the fix is almost always a quick one. But, what do you do if there is no selboolean that fixes your problem with a simple one liner?
After yesterday’s article, Tim Meusel shared a message he receives in his audit log when running nginx on his puppet master with SELinux in enforce mode:
type=AVC msg=audit(1415871389.171:787): avc: denied { name_connect }
for pid=2228 comm="nginx" dest=8080
scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket
type=SYSCALL msg=audit(1415871389.171:787): arch=c000003e syscall=42
success=no exit=-13 a0=19 a1=259e2b0 a2=10 a3=7fffdac559d0 items=0
ppid=2227 pid=2228 auid=4294967295 uid=996 gid=995 euid=996 suid=996
fsuid=996 egid=995 sgid=995 fsgid=995 tty=(none) ses=4294967295
comm="nginx" exe="/usr/sbin/nginx" subj=system_u:system_r:httpd_t:s0
key=(null)
That’s…. that’s ugly. The important parts have been highlighted. Nginx cannot talk to the tcp_socket at /var/run/puppet/puppetmaster_unicorn.sock. There doesn’t appear to be a selboolean that matches the issue. You could try flipping semi-relevant booleans for hours till you stumble upon some combination that may work, undoubtedly with side effects, and possibly never find the right combination. That could end up being a LOT of time wasted without any guarantee of success.
Instead, use audit2allow. By providing the tool with portions of an audit log, it will build an SELinux policy that will allow everything marked as “denied”. Here’s an example of generating a policy for review, then generating and applying that policy:
grep nginx /var/log/audit/audit.log | audit2allow > nginx.te more nginx.te grep nginx /var/log/audit/audit.log | audit2allow -M nginx semodule -i nginx.pp
You can find more detail on the tool on the web, particularly this article where another nginx user is struggling with SELinux. You may have to repeat this process a few times – nginx stopped running when it failed to attach to the socket, so there could be other SELinux permission issues it would encounter if it had not failed. You won’t see those in the audit.log until it gets past the socket. Keep at it until audit2allow is building the same policy file on consecutive runs, at which point there are no new failures to discover. Your application should be fully working now and encounter no more SELinux permission issues.
Update: Tim continued to struggle after he performed the above steps until he moved the unicorn socket out of /var/run (which is admittedly not the recommended location!) even though he wasn’t seeing any more failures in the audit log. This command forces SELinux to log all failure events and then the new failures showed up and were processed by audit2allow:
semodule --disable_dontaudit --build
See Tim’s blog for more info.
You can apply the policy via puppet using the selmodule type, plus a file resource to put the .pp file in the correct location.
While this takes a lot longer to resolve than touching some selbooleans, you should only have to do it once. This ensures you still have the protections of SELinux and a well defined policy state for your application. If, and only if, this doesn’t resolve your issue, should you even entertain the thought of disabling SELinux, as a temporary resolution until a permanent solution is found.
rnelson0 