[CentOS] puppet files denied by SELinux

Tim Dunphy

bluethundr at gmail.com
Sun Jul 12 01:40:22 UTC 2015


>
> 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.

On Mon, Jun 29, 2015 at 6:15 AM, Daniel J Walsh <dwalsh at redhat.com> wrote:

> 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.
>
> On 06/21/2015 02:05 PM, Tim Dunphy wrote:
> > Hey guys,
> >
> >  Quick update. I grepped through the output of getsebool -a to see that
> > related to puppet. And I found this setting:
> puppetagent_manage_all_files.
> >
> >  So I tried running this command: setsebool -P
> puppetagent_manage_all_files
> > 0
> >
> >  And did a restorecon on my modules directory: restorecon -R -v
> > environments/production/moudles
> >
> >  So there's good news and bad news to report! It seems that now puppet on
> > the client isn't complaining about not having access to the cert and key
> > files anymore! That's the good news. The bad news is, when I do puppet
> runs
> > on all the hosts now, I get the following errors:
> >
> > Notice: /File[/var/lib/puppet/lib/facter/concat_basedir.rb]: Dependency
> > File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/facter/concat_basedir.rb]: Skipping
> > because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/facter/ssldir.rb]: Dependency
> > File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/facter/ssldir.rb]: Skipping because of
> > failed dependencies
> > Notice:
> > /File[/var/lib/puppet/lib/puppet/parser/functions/ensure_resource.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> > /File[/var/lib/puppet/lib/puppet/parser/functions/ensure_resource.rb]:
> > Skipping because of failed dependencies
> > Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/validate_re.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/validate_re.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/reports/datadog_reports.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/reports/datadog_reports.rb]:
> > Skipping because of failed dependencies
> > Notice:
> >
> /File[/var/lib/puppet/lib/puppet/parser/functions/is_function_available.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> >
> /File[/var/lib/puppet/lib/puppet/parser/functions/is_function_available.rb]:
> > Skipping because of failed dependencies
> > Notice:
> > /File[/var/lib/puppet/lib/puppet/parser/functions/str2saltedsha512.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> > /File[/var/lib/puppet/lib/puppet/parser/functions/str2saltedsha512.rb]:
> > Skipping because of failed dependencies
> > Notice:
> >
> /File[/var/lib/puppet/lib/puppet/parser/functions/delete_undef_values.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> >
> /File[/var/lib/puppet/lib/puppet/parser/functions/delete_undef_values.rb]:
> > Skipping because of failed dependencies
> > Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/fqdn_rotate.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/fqdn_rotate.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/facter/gemhome.rb]: Dependency
> > File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/facter/gemhome.rb]: Skipping because
> of
> > failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/values_at.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/values_at.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/getvar.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/getvar.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/provider/vcsrepo/cvs.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/provider/vcsrepo/cvs.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/strftime.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/strftime.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/chop.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/chop.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/util/firewall.rb]: Dependency
> > File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/util/firewall.rb]: Skipping
> > because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/is_float.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/is_float.rb]:
> > Skipping because of failed dependencies
> > Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/parsejson.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/parsejson.rb]:
> > Skipping because of failed dependencies
> > Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/validate_cmd.rb]:
> > Dependency File[/var/lib/puppet/lib] has failures: true
> > Warning:
> > /File[/var/lib/puppet/lib/puppet/parser/functions/validate_cmd.rb]:
> > Skipping because of failed dependencies
> >
> > It's actually a long list of errors that's too long to reproduce here.
> It'd
> > go on for a couple pages at least.
> >
> > However if I turn off SELinux on the puppet master, everything returns to
> > normal. Goes from utter chaos to complete order in an instant!
> >
> > So I guess I've muffed up my SELinux config on this puppet host. I just
> > hope it's repairable at this point! I'd hate to leave it off just so that
> > puppet will be able to do it's job. And of all the hosts that would need
> > SELinux protection I would think that a puppet host would be one of the
> > most important if not 'the' most important to protect!
> >
> > I'm definitely open to suggestions at this point!
> >
> > Thanks,
> > Tim
> >
> > On Sun, Jun 21, 2015 at 11:11 AM, Tim Dunphy <bluethundr at gmail.com>
> wrote:
> >
> >> Hi all,
> >>
> >> Thanks for all your suggestions. Here's where I'm at with this.
> >>
> >> Can you give details about your puppetmasterd setup ? it seems that
> >>> you're using Foreman as puppet ENC.
> >>>
> >> Yes, I'm on foreman 1.7.4 and puppet 3.75. You are correct that I'm
> using
> >> foreman, sorry I hadn't thought to mention it!
> >>
> >>
> >>> 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
> >>>
> >> I didn't recompile any custom selinux policies. All I did to try to
> >> resolve the issue is to consult audit2allow and install the module it
> >> suggested.
> >> I did try running /usr/sbin/foreman-selinux-enable but that didn't seem
> >> to have an effect.
> >>
> >> 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.
> >>>
> >> You are correct that I copied the key and cert from an NFS share! Both
> the
> >> puppet server and the monitor1 client share the same /home directory via
> >> NFS. Pretty cool that you picked up on that! I do suspect you're
> probably
> >> right that this may be causing the problem. Just on a hunch, I tried
> >> copying the certs and keys from the montior1 host over to the puppet
> host
> >> to the /tmp directory on the puppet server. That leaves out NFS
> altogether.
> >> And when I do that, my bacula puppet module WORKS!! Puppet doesn't
> complain
> >> at all!
> >>
> >> But if I check out another host where I copied the cert and key from the
> >> NFS home directory I still get the error:
> >>
> >> Error:
> >>
> /Stage[main]/Bacula::Config/File[/etc/pki/tls/private/monitor2.mydomain.com.key]:
> >> Could not evaluate: Could not retrieve information from environment
> >> production source(s)
> >> puppet:///modules/bacula/monitor2/monitor2.mydomain.com.key
> >> Error:
> >>
> /Stage[main]/Bacula::Config/File[/etc/pki/tls/certs/monitor2.mydomain.com.crt]:
> >> Could not evaluate: Could not retrieve information from environment
> >> production source(s)
> >> puppet:///modules/bacula/monitor2/monitor2.mydomain.com.crt
> >>
> >> Also when I try to set context using the line you suggested I get an
> >> error:
> >>
> >> #semanage fcontext -a -t passenger_t "/etc/puppet/environments(/.*)?"
> >> ValueError: Type passenger_t is invalid, must be a file or device type
> >>
> >> So I googled around and found what seems to be the correct syntax:
> >>
> >> semanage fcontext -a -t passenger_exec_t
> "/etc/puppet/environments(/.*)?"
> >>
> >> Because when I applied that line, I didn't get any errors or complaints.
> >> However the problem still existed on the monitor2 host which had the key
> >> pair copied from the NFS share.
> >>
> >> So in summary it appears that there is some interaction between SELinux
> >> and NFS that is causing the issue.
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Tim
> >>
> >> On Sun, Jun 21, 2015 at 11:09 AM, Tim Dunphy <bluethundr at gmail.com>
> wrote:
> >>
> >>> Yes, you did when you used the audit2allow with the -M option argument
> >>>> of "puppet", which is confirmed by the command you issued to try to
> load
> >>>> it "semodule -i puppet.pp" (which you stated in your original
> message).
> >>>> I'm okay with you asserting otherwise and not following my first
> >>>> suggestion -- my second is to use a totally different name, e.g.,
> "barf"
> >>>> and thus "semodule -i barf.pp".
> >>>
> >>> Haha!! Ok man. I get you now. Thanks. Also I meant to send this to the
> >>> list.. Whoops! I'll try doing it again with something like 'my' in the
> >>> front. I remember having a similar problem with Zabbix last week that I
> >>> solved this way.
> >>>
> >>> On Sun, Jun 21, 2015 at 12:19 AM, Mark Milhollan <mlm at pixelgate.net>
> >>> wrote:
> >>>
> >>>> On Sat, 20 Jun 2015, Tim Dunphy wrote:
> >>>>> I wrote:
> >>>>>> That suggests there's already a module named puppet, and thus you
> are
> >>>>>> replacing it with the one you made which does not supply the
> >>>>>> puppet_var_lib_t type.  Always prefix your own modules with
> something
> >>>>>> that makes them almost certain to be unique, e.g., yourdom_puppet.
> >>>>>>
> >>>>> No, actually I didn't compile my own selinux module. :) Not sure how
> you
> >>>>> got that idea, but that is not the case.
> >>>> Yes, you did when you used the audit2allow with the -M option argument
> >>>> of "puppet", which is confirmed by the command you issued to try to
> load
> >>>> it "semodule -i puppet.pp" (which you stated in your original
> message).
> >>>> I'm okay with you asserting otherwise and not following my first
> >>>> suggestion -- my second is to use a totally different name, e.g.,
> "barf"
> >>>> and thus "semodule -i barf.pp".
> >>>>
> >>>>
> >>>> /mark
> >>>>
> >>>
> >>>
> >>> --
> >>> GPG me!!
> >>>
> >>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> >>>
> >>>
> >>
> >> --
> >> GPG me!!
> >>
> >> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
> >>
> >>
> >
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
GPG me!!

gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B



More information about the CentOS mailing list