Issue #1563 has been updated by seanmil.
For the purposes of this discussion I will be referring to the SELinux Tresys Reference Policy as if it is the only possible SELinux policy. As it is the one most SELinux-shipping distros base off of currently, it is a good pick but certainly this could work any way you imagine depending on the policy in place. "Out of the box" Puppet has no specific SELinux policy, resulting in Puppet running under the initrc_t or unconfined_t domains (depending on if you start it via /etc/rc.d/init.d/puppet or the command line). Both of these domains give Puppet essentially unrestricted access to the system to do as it pleases. This is good and is what you would want under the principle of least surprise - keep things that don't have a specific policy working as they always have. The specific problem is that, since Puppet has no policy, when it creates tmpfiles the system uses the default policy rules. For files in /tmp/puppet.#####.# that is the tmp_t label. However, any services which DO have SELinux policies (and which you would want Puppet to manage with service start/stops, etc.) do not have permission to write to files labelled with tmp_t. This is good policy since /tmp exploits have been numerous over the years, but it means that when Puppet passes those file descriptors to the programs they don't have permissions to write to their STDOUT/STDERR - since those file descriptors are in the tmp_t domain. After talking with the SELinux guys and detailing the problem they said that this should be possible to do without modifying any Puppet code. However, it requires writing a policy for Puppet so that when Puppet is executed it transitions to the puppet_t domain (for example) and any files written to /tmp from the puppet_t domain get labelled with puppet_tmp_t (for example). Then, in the Puppet policy, you can add a rule that says "allow all SELinux domains to read and write files labelled puppet_tmp_t". I am working on a policy file that does this now, except I know nothing about writing SELinux policy files so it is slow going. Right now it transitions to puppet_t (but only if the init script is used) and puppetd immediately dies due to an SELinux denial for access to /sbin, since I haven't yet given puppet_t processes access to /sbin. :) I expect/hope to be able to figure this out and have at least some level of a functional SELinux policy for Puppet. I'll update here (probably in a few days) with my success/failure :) If I attach a Puppet policy file that compiles against the SELinux reference policy to this ticket would it be something you would entertain shipping with Puppet for testing/use by a wider audience? It would be available to anyone interested and if someone didn't choose to load it they would just get the current behavior. ---------------------------------------- Bug #1563: [PATCH] Change Util::Execute to use pipes instead of temporary files for capturing output http://projects.reductivelabs.com/issues/show/1563 Author: seanmil Status: Needs more information Priority: High Assigned to: luke Category: plumbing Target version: 0.24.6 Complexity: Easy Affected version: 0.24.5 Keywords: SELinux execute Tempfile Patch attached to fix reported behavior. When triggering Puppet runs which included initscript starts/stops I noticed that I would receive three SELinux AVC denials logged for the process that was being started/stopped for a file of the form /tmp/puppet.$PID.0. Many of the system daemons which ship with CentOS 5 have confined SELinux domains which don't permit access to much of the system - including these Puppet temp files. Trying to figure out where to create the file (and with which context) for every service would be impractical (impossible? some services may not have any context that would be usable for write permissions) so I decided to just rewrite it to use Unix pipes. WorksForMe in my testing. I'm marking this as high because, depending on what commands are being run and their SELinux policies, this could cause command output to silently disappear (other then the denials in the logs). This could be very frustrating for someone who is trying to use that output. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
