Nagios Module's check_yum and selinux on RHEL 6

[Sean Alderman]

There seems to be some issue with the check_yum via check_nrpe from the Nagios server on RHEL 6 systems with selinux set to enforcing.  It appears that the nagios/nrpe user on the agent can run the check successfully by hand, but originating from the nrpe daemon, it is denied by selinux.  Most of the platforms I manage are set to permissive mode, not enforcing, so I haven't seen this very often, but we have had a few.  The result from Nagios' perspective, is that check_nrpe is unable to find /usr/bin/yum.

I did find a blog about how to correct this, and I'm looking to see if the remedy [1] is something that can be accomplished from the Nagios Puppet Module, or if it would be appropriate to do so.

[1] http://codeforthesoul.blogspot.com/2012/02/selinux-policy-to-run-checkyum.html

I've struggled with coercing puppet into doing something once and only once.  My cases have always been where puppet can't definitively determine if the task has been run before, not sure if that would be the case for this remedy or not though.

Thanks for your thoughts!

[Alessandro Franceschi]

I've to admit that support fo Selinux in ex42 modules is quite under the bar.

In this case a good selinux module that would allow management of new policies would be , imho, the right approach to follow (introducing in the nagios module a optional dependency  for this selinux one).

I take the occasion to share with you my intention to provide in the future a nagios_plugins module that only manages nagios plugins, so that we can rid of the confusion in the plugins management across different modules (nrpe, nagios, icinga...).

I suppose this will be done on the new major version of the modules.

[Rodrigo Menezes]

Hey Sean,

If I remember correctly I also ran into this issue. The problem ended up being with the version of NRPE and it's plugins I was using. What I ended up doing was using the NRPE rpm package from EPEL.

--
You received this message because you are subscribed to the Google Groups "Example42 Puppet Modules" group.
To unsubscribe from this group and stop receiving emails from it, send an email to example42-puppet-m...@googlegroups.com.
To post to this group, send email to example42-pu...@googlegroups.com.
Visit this group at http://groups.google.com/group/example42-puppet-modules.
For more options, visit https://groups.google.com/groups/opt_out.

[Sean Alderman]

Rodrigo,
  Thanks for the reply.  I am using EPEL's nrpe and plugins RPMs.  The check_yum plugin isn't packaged by EPEL (see next note to Al).

Al,
  Ok.  I didn't really expect your modules to directly support selinux, but it seems this particular plugin is provided by the module, so that's gray area.  I'm not even sure how to go about trying to encapsulate the steps in the blogged work-around into a puppet module at this point.  That task is probably a bit off topic for this list.

  I love the plugin's use case, leveraging the yum-security plugin is awesome.  If the plugin would get it pushed into the EPEL repo, I imagine the package would be built with proper selinux contexts applied.  The plugin maintainer is apparently concerned about time required, EPEL's insistence on a rewrite to a non-interpreted language, and the longevity of RPM/yum as a packaging platform.  Perhaps I will just approach this by forcing systems into permissive mode, or leave it to the local admins to apply the work-around by hand.  I don't have the Updates check making notifications, so it won't be bothering admins who don't seek to resolve the issue.

Thanks for both your inputs!  :)

To unsubscribe from this group and stop receiving emails from it, send an email to example42-puppet-modules+unsub...@googlegroups.com.

[Alessandro Franceschi]

Since the module is provided as a file via the module, maybe we can have just to add the relevant selinux arguments to the file resource.
Any PR on that is welcomed.

[Sean Alderman]

Thanks, I'll make an attempt to write a patch and submit a PR.

[Sean Alderman]

So for anyone who's interested in this issue...

I've not been able to successfully get audit2allow to help me build a policy for this check_yum plugin that works in all cases.  I've tried several variations and they all lead check_yum to fail testing the execute-ability of /usr/bin/yum.  I have a gist of the most complete list of things I tried - https://gist.github.com/salderma/7234952.  I've appealed to a higher source, namely the author of this blog - http://mgrepl.fedorapeople.org/Blog/nagios.html, and will see what he says that I missed.

Meanwhile, I found a very nice and suitable solution rummaging around on github -  https://github.com/whizzit/selinux-nrpe-yum  This is quite nice and while it's not a puppet solution, it might as well be...after building the RPM, I can now ensure that package gets deployed from my local repo via puppet.

[Alessandro Franceschi]

Thank you for the update and for sharing your findings.

al

[Rodrigo Menezes]

Hey Sean,

I went digging around to see if I could remember how I got check_yum to work without turning off selinux. I think I may have found it, but again it's been a while since I last looked/did this so it may not be correct.

I made modifications to my icinga module which weren't pulled upstream for good reasons. You can see the changes here: https://github.com/brdude/puppet-nrpe/blob/master/manifests/ . When publishing the check_yum script i use this:

file { "Nrpe_plugin_${name}":
    path    => "${nrpe::pluginsdir}/${name}",
    owner   => root,
    group   => root,
    mode    => '0755',
    ensure  => $ensure,
    require => Package['nrpe'],
    notify  => Service['nrpe'],
    source  => "puppet:///modules/nrpe/plugin/${name}",
    seluser => "system_u",
    selrole => "object_r",
    seltype => "nagios_unconfined_plugin_exec_t",
    selrange => "s0",
  }

It's not the best selinux policy and it may not work for you (again long time since I made this modification) but it may be worth a shot.

To unsubscribe from this group and stop receiving emails from it, send an email to example42-puppet-m...@googlegroups.com.