Audit says nothing to do, yet puppet won’t run with SELinux enforcing

phusion-passengerpuppetmasterrhel7selinux

I'm determined to get my puppet master running with SELinux set to enforcing. If I make it permissive, it runs fine.

I'm on RHEL 7, with systemd, apache2, passenger 4, and puppet 3.

I've gone through a couple of passes using the audit log, and audit2allow, to make semodules that cover the audit log. (And it's a big mess, with passenger running from an apache module, as the apache user, executing the puppet master code.)

This is an all-new configuration, so the puppet manifest is a default empty node, with nothing to do.

If I run "puppet agent -t" on a remote machine, it succeeds with setenforce 0. The audit log is pretty empty. (audit2allow reports "nothing to do.")

But if I turn setenforce 1, I get these:

Aug 20 23:14:28 puppet002 puppet-master[1544]: Permission denied - /etc/puppet/auth.conf
Aug 20 23:14:29 puppet002 puppet-master[1544]: Permission denied - /etc/puppet/manifests/site.pp on node agentserver.example.com

I've tried changing ownerships on /etc/puppet/*, and the se context looks fine:

[root@puppet002 log]# cd /etc/puppet
[root@puppet002 puppet]# ls -lZ
-rw-r--r--. apache apache system_u:object_r:puppet_etc_t:s0 auth.conf
-rw-r--r--. apache apache system_u:object_r:puppet_etc_t:s0 fileserver.conf
drwxr-xr-x. apache apache system_u:object_r:puppet_etc_t:s0 manifests
drwxr-xr-x. apache apache system_u:object_r:puppet_etc_t:s0 modules
-rw-r--r--. apache apache system_u:object_r:puppet_etc_t:s0 puppet.conf

Any troubleshooting suggestions?

[Edit]: Additional information, following the suggestion to turn off "dontaudit" and repeat the exercise, the error messages changed. My $ssldir is /var/lib/puppet/ssl and $logdir is /var/log/puppet, which makes these errors interesting:

puppet-master[3210]: Permission denied – /etc/puppet/ssl

puppet-master[3210]: (/File[/etc/puppet/ssl]/ensure) change from absent to directory failed: Could not set 'directory' on ensure: Permission denied – /etc/puppet/ssl

puppet-master[3210]: Could not prepare for execution: Got 3 failure(s) while initializing: File[/etc/puppet/ssl]: change from absent to directory failed: Could not set 'directory' on ensure: Permission denied – /etc/puppet/ssl; File[/etc/puppet/manifests]: change from absent to directory failed: Could not set 'directory' on ensure: Permission denied – /etc/puppet/manifests; File[/var/lib/puppet/log]: change from 0755 to 0750 failed: failed to set mode 755 on /var/lib/puppet/log: Permission denied – /var/lib/puppet/log

All works of course in Permissive. 🙁

Best Answer

To get deeper into the problem, I installed the setroubleshoot-server package on my puppet master. Rather than put the machine into Permissive mode, I left it in Enforcing. Then I piped my audit log into sealert, and got this gem:

found 3 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing /usr/bin/ruby from search access on the directory .

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

If you believe that ruby should be allowed search access on the  directory 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 ruby /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

And indeed that allows a puppet master run to succeed in Enforcing mode.

My theory is that in Enforcing mode the Puppet master is tripped into a different code path that triggers the additional access alerts, not discovered in Permissive mode.

Related Topic