On Thursday, March 26, 2015 at 2:25:38 PM UTC-5, Melissa Stone wrote: > > The current pull request uses the following environment variables: > > - NO_PUPPET_SELINUX_DTRANS > - PUPPET_SELINUX_MASTER_DOMAIN > - PUPPET_SELINUX_CA_DOMAIN > > Maybe it's just a knee-jerk reaction, but I'm having trouble with the idea that relying on data from the environment could possibly serve a valid system security objective. That's more usually considered a weakness, and environment-based exploits are legion.
Do the contexts used need to be configurable in Puppet at all? Couldn't they be hard-coded, in which case it becomes a matter of system SELinux policy, rather than Puppet configuration, to grant appropriate access to the contexts in which the various subcommands run? > Switching contexts for packaged installs vs gem installs > It was proposed that we don't switch SELinux contexts if Puppet was > installed via a gem or run from source. This seems really challenging to > implement. > What if there were a command-line option that controlled whether Puppet would attempt to perform a context switch, with a default value configurable at build time? A default build might default to not switching, yet still have the option for the user to request a switch, whereas, say, the RPM build would default to switching (but have the option to suppress a switch). Switching contexts for different users > > If I'm developing on Puppet and standing up a test master as my own user, > I really don't want SELinux turning itself on. How can we prevent this? > Why would SELinux "turn itself on"? Do you mean the SELinux subsystem itself, or Puppet's use of it? For the latter, I'm still liking a controlling command-line option, whose default value is configurable at build / install time. > Opt-out vs opt-in > > The current approach takes an opt-out approach to SELinux; if it's opt-in > we avoid the issue of switching contexts for packaged installs vs gem > installs. Is this a viable option? > Opt-in seems viable to me, both as a build/install choice and as a runtime choice. It must be understood, of course, that with some system configurations, refusing to opt in will mean that Puppet will not be able to do some of the work you may ask it to do. > Default values for SELinux domains > > It was mentioned that we can isolate the default values for SELinux > domains to an isolated file so that downstream vendors can just patch that > file; I think this is a great idea. It seems a lot simpler than using > environment variables. > If the various subcommands operated in predetermined, standard contexts, then wouldn't that make it so that downstream vendors just need to write or patch a policy module? John -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/ffe4ab64-4299-4b6b-94dc-90166ae2fffe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
