1

I am running into an issue every time I attempt to start the puppetmasterd service, for which I receive the following error message:

root@service1 ~ # -> /etc/init.d/puppetmaster start
Starting puppetmaster: Could not prepare for execution: Got 1 failure(s) while initializing: change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /etc/puppet/ssl
                                                       [FAILED]

Apparently there was a known issue with this scenario as outlined in this bug report, however in the bug report it states the issue has been resolved in selinux-policy-3.9.16-29.fc15, but the latest CentOS default upstream version is 3.7.19-155.el6_3.4. So I am trying to figure out the best solution.

I can either create a local security policy to allow puppetmasterd the access it needs, or keep researching and install a newer version of selinux-policy outside of the default upstream channel. Anyone have any recommendations? Please don't recommend disabling SELinux...

----- Update -----

Here is the puppet.conf:

[main]
    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet

    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet

    # Where SSL certificates are kept.
    # The default value is '$confdir/ssl'.
    ssldir = $vardir/ssl

[master]
    certname=puppetmaster.ownij.lan
    dns_alt_names=puppetmaster.ownij.lan

[agent]
    # The file in which puppetd stores a list of the classes
    # associated with the retrieved configuratiion.  Can be loaded in
    # the separate ``puppet`` executable using the ``--loadclasses``
    # option.
    # The default value is '$confdir/classes.txt'.
    classfile = $vardir/classes.txt

    # Where puppetd caches the local configuration.  An
    # extension indicating the cache format is added automatically.
    # The default value is '$confdir/localconfig'.
    localconfig = $vardir/localconfig

    server=puppetmaster.ownij.lan

And here are the denials per the audit log:

type=AVC msg=audit(1349751364.985:666): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751364.985:666): arch=c000003e syscall=4 success=no exit=-13 a0=1391420 a1=7fffef09ed10 a2=7fffef09ed10 a3=120c500 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751365.302:667): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751365.302:667): arch=c000003e syscall=4 success=no exit=-13 a0=1d18530 a1=7fffef0d04d0 a2=7fffef0d04d0 a3=8 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751365.465:668): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751365.465:668): arch=c000003e syscall=4 success=no exit=-13 a0=1af3930 a1=7fffef0c5c70 a2=7fffef0c5c70 a3=8 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751365.467:669): avc:  denied  { search } for  pid=15093 comm="puppetmasterd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751365.467:669): arch=c000003e syscall=4 success=no exit=-13 a0=1b17aa0 a1=7fffef0c5c70 a2=7fffef0c5c70 a3=8 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)
type=AVC msg=audit(1349751366.401:670): avc:  denied  { write } for  pid=15093 comm="puppetmasterd" name="puppet" dev=dm-0 ino=132035 scontext=unconfined_u:system_r:puppetmaster_t:s0 tcontext=system_u:object_r:puppet_etc_t:s0 tclass=dir
type=SYSCALL msg=audit(1349751366.401:670): arch=c000003e syscall=83 success=no exit=-13 a0=2d7a400 a1=1f9 a2=2d7a40f a3=7fffef0a6df0 items=0 ppid=15092 pid=15093 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=13 comm="puppetmasterd" exe="/usr/bin/ruby" subj=unconfined_u:system_r:puppetmaster_t:s0 key=(null)

And the audit log if I pass through audit2allow:

root@service1 ~ # -> fgrep puppetmasterd /var/log/audit/audit.log | audit2allow -m puppetmasterd

module puppetmasterd 1.0;

require {
    type home_root_t;
    type puppetmaster_t;
    type puppet_etc_t;
    type puppet_var_run_t;
    type httpd_sys_content_t;
    class lnk_file { relabelfrom relabelto };
    class file { relabelfrom read getattr open };
    class dir { write read search getattr setattr };
}

#============= puppetmaster_t ==============
allow puppetmaster_t home_root_t:dir { search getattr };
allow puppetmaster_t httpd_sys_content_t:dir read;
allow puppetmaster_t httpd_sys_content_t:file { read getattr open };
#!!!! The source type 'puppetmaster_t' can write to a 'dir' of the following types:
# puppet_log_t, puppet_var_lib_t, puppet_var_run_t, puppetmaster_tmp_t

allow puppetmaster_t puppet_etc_t:dir { write setattr };
allow puppetmaster_t puppet_etc_t:lnk_file { relabelfrom relabelto };
allow puppetmaster_t puppet_var_run_t:file relabelfrom;
Mike Purcell
  • 1,688
  • 7
  • 30
  • 53
  • I do not have the time to write this up as a correct answer, but see my policy at http://sandcat.nl/~stijn/2012/01/20/selinux-passenger-and-puppet-oh-my/ – Stijn Hoop Oct 10 '12 at 11:48

1 Answers1

0

You're using the default location for $ssldir - what's your puppet.conf look like?

The default deployment of Puppet on RHEL derivatives has a puppet.conf with something like the following:

[main]
    ssldir = /var/lib/puppet/ssl

If you put this back in place, the SELinux policy shouldn't have a problem with the location of your SSL directory.

Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Yes, I believe it is in the default location as I didn't overwrite that setting in the puppet.conf. – Mike Purcell Oct 09 '12 at 03:10
  • @MikePurcell Right - I'm saying that `puppet.conf`'s default location of `$confdir/ssl` (which is what your config is using) is not the standard RHEL/CentOS location of `/var/lib/puppet/ssl` (or `$vardir/ssl`). Try using the normal CentOS location and I bet your issue will be resolved. By the way, what method did you use to install Puppet? – Shane Madden Oct 09 '12 at 03:13
  • Used `yum install puppet\* --enablerepo=epel` – Mike Purcell Oct 09 '12 at 04:10
  • What is the "normal centos location"? – Mike Purcell Oct 09 '12 at 04:18
  • "the standard RHEL/CentOS location of `/var/lib/puppet/ssl` (or `$vardir/ssl`)" – Dominic Cleal Oct 09 '12 at 05:49
  • @MikePurcell That's set fine; the `home_root_t` context is problematic. How was this drive setup configured? Try a relabel (see [here](http://serverfault.com/questions/432531/what-does-the-autorelabel-file-do-in-linux))? – Shane Madden Oct 09 '12 at 06:27
  • @ShaneMadden: Ok, I'll give it a shot. Im still pretty new to SELinux, chances are I may have messed it up when configuring some other stuff. – Mike Purcell Oct 09 '12 at 16:46
  • 1
    Ya, looks like I messed up some SELinux labels, after putting everything back to default, it worked. – Mike Purcell Oct 17 '12 at 22:25