puppet master fails to set selinux context on /etc/puppet/auth.conf

[Mike Schmidt]

I am running puppet 3.2.1, using the puppetlabs repos, on centos 6.4. I keep getting these messages in the log: (every 30 minutes)

Jun  3 11:24:55 yoda puppet-master[20292]: Failed to set SELinux context system_u:object_r:puppet_etc_t:s0 on /etc/puppet/auth.conf

Jun  3 11:24:55 yoda puppet-master[20292]: Failed to set SELinux context system_u:object_r:puppet_etc_t:s0 on /etc/puppet/manifests/site.pp

Jun  3 11:24:55 yoda puppet-master[20292]: Starting Puppet master version 3.2.1

Currently, selinux is running in permissive mode, and the actual selinux context for these files is: 

-rw-r--r--. root root unconfined_u:object_r:puppet_etc_t:s0 auth.conf

-rw-r--r--. root root system_u:object_r:puppet_etc_t:s0 auth.conf.rpmnew

-rw-r--r--. root root system_u:object_r:puppet_etc_t:s0 fileserver.conf

drwxr-xr-x. root root system_u:object_r:puppet_etc_t:s0 manifests

drwxr-xr-x. root root system_u:object_r:puppet_etc_t:s0 modules

-rw-r--r--. root root unconfined_u:object_r:puppet_etc_t:s0 puppet.conf

restorecon sets all files in the subdirectories to unconfined_u. puppet master runs as root, so it should be able to modify the file labels. 

Anyone have any idea why these messages keep popping up? and how to fix the problem? Admittedly, I can just change the file labels manually, but that doesn't solve the underlying problem. 

[jcbollinger]

On Monday, June 3, 2013 10:45:27 AM UTC-5, Mike Schmidt wrote:

I am running puppet 3.2.1, using the puppetlabs repos, on centos 6.4. I keep getting these messages in the log: (every 30 minutes)

Jun  3 11:24:55 yoda puppet-master[20292]: Failed to set SELinux context system_u:object_r:puppet_etc_t:s0 on /etc/puppet/auth.conf

Jun  3 11:24:55 yoda puppet-master[20292]: Failed to set SELinux context system_u:object_r:puppet_etc_t:s0 on /etc/puppet/manifests/site.pp

Jun  3 11:24:55 yoda puppet-master[20292]: Starting Puppet master version 3.2.1

Currently, selinux is running in permissive mode, and the actual selinux context for these files is: 

-rw-r--r--. root root unconfined_u:object_r:puppet_etc_t:s0 auth.conf

-rw-r--r--. root root system_u:object_r:puppet_etc_t:s0 auth.conf.rpmnew

-rw-r--r--. root root system_u:object_r:puppet_etc_t:s0 fileserver.conf

drwxr-xr-x. root root system_u:object_r:puppet_etc_t:s0 manifests

drwxr-xr-x. root root system_u:object_r:puppet_etc_t:s0 modules

-rw-r--r--. root root unconfined_u:object_r:puppet_etc_t:s0 puppet.conf

restorecon sets all files in the subdirectories to unconfined_u. puppet master runs as root, so it should be able to modify the file labels. 

It's not the cause of your problem, but the master should NOT run as root.  There is no reason why it should need special privilege to do its work, therefore good security practices dictate that it run without such privilege.

If restorecon sets the SELinux labels incorrectly, however, then you need to teach it what the correct labels ought to be.  It is a fundamental problem for restorecon to disagree with Puppet about what the labels should be.

I also find it a little strange that you see those messages repeatedly, and especially that you see them at 30-minute intervals.  Are you running the master standalone, or via apache/passenger (or some other rack server)?  If the latter, then the rack server may be starting new master instances periodically, and in that case they might not be running with the identity and privileges you think.
 

Anyone have any idea why these messages keep popping up? and how to fix the problem? Admittedly, I can just change the file labels manually, but that doesn't solve the underlying problem. 

You should try updating your selinux policy package to the latest available.  You may need to manually modify your policy, however, as there were puppet-related bugs in some of the policy packages at least as recently as Fedora 18, which doesn't bode well for CentOS / RHEL 6.4.  See, for example, https://bugzilla.redhat.com/show_bug.cgi?id=848939.


John

[Mike Schmidt]

On Tuesday, June 4, 2013 11:22:22 AM UTC-4, jcbollinger wrote:

It's not the cause of your problem, but the master should NOT run as root.  There is no reason why it should need special privilege to do its work, therefore good security practices dictate that it run without such privilege.

If restorecon sets the SELinux labels incorrectly, however, then you need to teach it what the correct labels ought to be.  It is a fundamental problem for restorecon to disagree with Puppet about what the labels should be.

I also find it a little strange that you see those messages repeatedly, and especially that you see them at 30-minute intervals.  Are you running the master standalone, or via apache/passenger (or some other rack server)?  If the latter, then the rack server may be starting new master instances periodically, and in that case they might not be running with the identity and privileges you think.
 

Anyone have any idea why these messages keep popping up? and how to fix the problem? Admittedly, I can just change the file labels manually, but that doesn't solve the underlying problem. 

You should try updating your selinux policy package to the latest available.  You may need to manually modify your policy, however, as there were puppet-related bugs in some of the policy packages at least as recently as Fedora 18, which doesn't bode well for CentOS / RHEL 6.4.  See, for example, https://bugzilla.redhat.com/show_bug.cgi?id=848939.


John

I am running puppet master using apache/passenger, and while some of the Passenger modules run as root, I realize that the puppet master is running as the user puppet. 

It does seem that each of the messages comes with a different pid, so I'll check to see whats going on. 

From what I understand of your reply, the selinux file contexts should be set to what puppet wants, so restorecon needs to be fixed. OK. I am running the latest everything in centos6.4, so the policies are up to date. However, in looking at selinux's file_contexts file, everything should have been set to system_u, just as puppet wanted. I guess the policy updates didn't make it to the files. I forced restorecon to relabel with restorecon -F, and that did the trick. 

Thank you very much. 

Mike

[Dan M]

Mike

Thank you for solution.
Perhaps it would be useful to people facing same issue - full instruction set for CentOS looks like:

1. sudo vim /etc/selinux/targeted/contexts/files/file_contexts

Make sure that following line is there:
/etc/puppet(/.*)?       system_u:object_r:puppet_etc_t:s0

2. sudo restorecon -F -e /etc/puppet/puppet.conf

3. Verify security context:
$> ls -l --context /etc/puppet/puppet.conf

Output should be something like
-rw-r--r--. root root system_u:object_r:puppet_etc_t:s0 /etc/puppet/puppet.conf

Dan