Puppet Files Denied By SELinux

Home » CentOS » Puppet Files Denied By SELinux
CentOS 4 Comments

Hey folks,

Ok so I’m having another issue with SELinux. However I think I’m pretty close to a solution and just need a nudge in the right directtion.

I wrote a puppet module that gets systems into bacula backups. Part of the formula is to distribute key/cert pairs with permissions that allow bacula to read them so that bacula can talk to the host over TLS. It’s pretty slick, I must say!

However on adding some new hosts to bacula backups via puppet, I noticed that I was getting permission denied errors on the keypairs on the client hosts.

In my audit logs I found this entry:

type=AVC msg=audit(1434769414.956:562): avc: denied { open } for pid558 comm=”ruby”
path=”/etc/puppet/environments/production/modules/bacula/files/monitor1/monitor1.mydomain.com.crt”
dev=”vda1″ ino42005 scontext=system_u:system_r:passenger_t:s0
tcontext=system_u:object_r:nfs_t:s0 tclass=file

And audit2allow told me this:

#grep puppet /var/log/audit/audit.log | audit2allow -M puppet
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i puppet.pp

But in installing the module I get an error I’ve never seen before:

#semodule -i puppet.pp libsepol.print_missing_requirements: foreman’s global requirements were not met: type/attribute puppet_var_lib_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed!

I will say that I’m getting much better at working through SELinux issues. I’ve come a long way from when I was taught by a senior admin I was working with to ‘always disable selinux’ to now making an effort to work through the issues.

So I was hoping to get some advice on how to get over this hurdle!

Thanks, Tim

4 thoughts on - Puppet Files Denied By SELinux

  • dev=”vda1″ ino42005 scontext=system_u:system_r:passenger_t:s0

    Hi,

    Can you give details about your puppetmasterd setup ? it seems that you’re using Foreman as puppet ENC. Foreman works fine with selinux enabled : that’s what we use for the CentOS.org infra :-)
    Which version of puppet/foreman are you using ? Note that foreman has the foreman-selinux package that is used to automatically tune contexts and booleans needed for this. You can still reapply those settings with
    /usr/sbin/foreman-selinux-{disable,enable,relabel}
    There is no need to recompile a custom selinux policy for foreman/puppet those days

    –

  • Knowing nothing of your scenario, look at the source and target context.

    Looks like you copied a crt from an nfs location and you don’t have a file context defined to transition labels, maybe something like:

    semanage fcontext -a -t passenger_t “/etc/puppet/environments(/.*)?”

    However, I know nothing of puppets selinux infrastructure, you may need a more applicable type.

    In these cases, audit2allow can’t possibly guess the right thing and will certainly produce a rule that is either unsafe or simply wrong.

    jlc

  • I have no idea of the current dependency problem. I think your original problem was caused by mv’ing files from an nfs share to /etc which maintained the context. And SELinux prevented puppet from accessing nfs_t type. If you had just run restorecon on the object it would have set it back to the correct/default context.

    You might want to setup an alias mv “mv -Z”

    This changes the way mv works to set the context after mv rather then maintaining the source context.

  • Thanks! That’s probably a good suggestion. However I did try doing a restorecon -R -v on the entire puppet directory. No luck in resolving that error. And it’s really bugging me that SELinux has to stay off in order for puppet to do it’s thing.

    However I was at least smart enough to keep my entire puppet directory, as well as my puppetdb directory in SVN. So in case of a need to rebuild, I
    can ease the process a bit. I’m heavily leaning to a rebuild at this point to resolve this. Sucks, but what can ya do!

    And if I do actually take that step I hope that the rebuild resolves it. And that I haven’t checked anything into SVN that would muff up SELinux on the rebuilt host.