Ask Your Question

puppet master / passenger / apache with SELinux enabled, possible?

asked 2014-08-21 10:58:11 -0600

Mojo gravatar image

I'm beginning to think it's hopeless to run a puppet master with SELinux set to Enforcing. I'm trying it on a RHEL 7 server, with passenger 4.0.48, and Apache 2.4.6.

My manifest is currently empty, only an empty node default { } defined. With SELinux set to Permissive, a remote agent can run quietly. In Enforcing, passenger fails to launch puppet with these errors recorded:

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

I've made multiple passes in permissive mode and built se modules using audit2allow. I learned about the "dontaudit" flag and disabled it to get additional audit entries.

The strange thing about these errors is that my puppet.conf specifies:

ssldir = $vardir/ssl
logdir = /var/log/puppet

... and the /etc/puppet/manifests directory clearly exists. None of those failures should be relevant. (Typical SELinux failure.)

Here's a directory with context for /etc/puppet:

[root@puppet002 puppet]# ls -Z /etc/puppet
-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
drwxr-xr-x. apache apache unconfined_u:object_r:puppet_etc_t:s0 ssl

And /var/lib/puppet:

[root@puppet002 puppet]# ls -lZ /var/lib/puppet
drwxr-x---. apache apache system_u:object_r:puppet_var_lib_t:s0 bucket
drwxr-xr-x. apache apache system_u:object_r:puppet_var_lib_t:s0 facts.d
drwxr-xr-x. apache apache system_u:object_r:puppet_var_lib_t:s0 lib
drwxr-xr-x. apache apache unconfined_u:object_r:puppet_var_lib_t:s0 log
drwxr-x---. apache apache system_u:object_r:puppet_var_lib_t:s0 reports
drwxr-x---. apache apache system_u:object_r:puppet_var_lib_t:s0 rrd
drwxr-xr-x. apache apache system_u:object_r:puppet_var_lib_t:s0 run
drwxr-x---. apache apache system_u:object_r:puppet_var_lib_t:s0 server_data
drwxrwx--x. apache apache system_u:object_r:puppet_var_lib_t:s0 ssl
drwxr-xr-t. apache apache system_u:object_r:puppet_var_lib_t:s0 state
drwxr-x---. apache apache system_u:object_r:puppet_var_lib_t:s0 yaml

The whole thing is complicated when running under passenger since the activer user is apache and not puppet.

Next I'll try tearing down the machine and starting over. :/

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2014-08-21 12:29:54 -0600

Mojo gravatar image

I dug a little deeper using sealert to process the audit log, with Enforce in place. It was able to discover this bit:

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

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

If you believe that ruby should be allowed relabelfrom 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.
allow this access for now by executing:
# grep ruby /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

I think the problem left unsolved is that this isn't caught by the audit process with SELinux is set Permissive. Maybe that's the last step. I can imagine a pathway through the code that doesn't trigger this access in Permissive mode.


edit flag offensive delete link more

answered 2014-08-21 12:35:06 -0600

ramindk gravatar image

I see a few problems. Passenger run the application as the owner of your should be owned by puppet. If I were you I'd at least get the directories sorted by doing.

  1. start from scratch.
  2. Install puppet, run puppetmasterd, let it generate certs. stop it.
  3. Install Passenger, add vhosts, etc etc. Start Apache

At this point /var/lib/puppet should be owned mostly by puppet. If everything works at that point I'd try running the agent against the server. That will cause some files to be owned by root:root, but shouldn't break anything. You may have continuing selinux problems, but at least you'll know they are selinux problems.

edit flag offensive delete link more


Wow, "Passenger run the application as the owner of your" -- there's a valuable bit of information. Even with the answer I posted elsewhere, I may give it another go from scratch and see what happens. I'll follow-up.

Mojo gravatar imageMojo ( 2014-08-21 12:59:01 -0600 )edit

I've been working on a how to run Passenger question because the fact that ownership matters tends not to be documented well. There might be other stuff in there you find useful,

ramindk gravatar imageramindk ( 2014-08-21 14:10:39 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2014-08-21 10:58:11 -0600

Seen: 1,669 times

Last updated: Aug 21 '14