Hi all, I just wanted to point out that Adrien brought up some interesting comments in the ticket for this discussion. So that response gets more exposure, I wanted to post it here:
>From Adrien Thebo: I've reviewed PR 3627 and the puppet-dev mailing list thread, and I think that this issue could use more discussion before we start merging things. First off, it doesn't seem like a lot of other projects have to deal with this concern. Is this because the executable itself has a context set and the process itself doesn't need to know about the context? Secondly, how will this impact the JVM? Since (AFAIK) the JVM runs as a single process with multiple services running in that process, is it even possible to switch the SELinux context without breaking everything else inside of the JVM? And now for more implementation oriented questions: SELinux domains What domains do we need for Puppet + SELinux? What resources do they need access to? Configuration via environment variables The current pull request uses the following environment variables: - NO_PUPPET_SELINUX_DTRANS - PUPPET_SELINUX_MASTER_DOMAIN - PUPPET_SELINUX_CA_DOMAIN Right now Puppet doesn't use ENV for configuration; it has a few trivial things like looking at 'PATH' and 'HOME' but doesn't read values out in order to configure itself. Using the environment to configure the SELinux context means that we have a new configuration mechanism that will not be documented along with other settings. Using environment variables for configuration means that if different values are needed, they won't "stick" - there's no way to always apply these settings without modifying init scripts or /etc/profile or the like. This leads into... Environment variables vs configuration via a file Dominic Cleal indicated that we should change the SELinux context before we read any configuration files, which makes us need an alternate method of configuring SELinux, which the reason of running unconfined for as little time as possible. Why? Doing so makes it more challenging to handle configuration. Is it really that risky to run unconfined until we can read a config file to get SELinux settings? If we do run unconfined long enough to read a config file, what are the potential ramifications of running unconfined for this period? 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. 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? 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? 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. On Tuesday, September 9, 2014 at 8:03:11 AM UTC-7, Lukáš Zapletal wrote: > > Hello, > > I filed a pull request with a draft code which is alighed with what > Dominic proposed: > > https://github.com/puppetlabs/puppet/pull/2997 > > It does not introduce any new global command line parameters because I > think it's an overkill. There are three env. variables which can be used to > tune this up, but I think this would be rare cases. > > LZ > > On Wednesday, August 27, 2014 9:00:49 PM UTC+2, Joshua Partlow wrote: >> >> Hi everyone, >> >> There is a PR for Puppet to address difficulties setting security >> contexts in SELinux for specific puppet subcommands ( >> https://github.com/puppetlabs/puppet/pull/2997). The contributer (Lukáš >> Zapletal) originally was looking to add additional wrapper scripts around >> subcommands so that a puppet_exec_t could be set for these files. There is >> general concern about the confusion caused by reintroducing separate >> commands, and Dominic Cleal suggested making use of Ruby's SELinux bindings >> (specifically Puppet::Util::SELinux.setcon in Puppet) to instead handle the >> context switch internally. >> >> Talking this over during the triage today, this seems like a reasonable >> approach, but we're lacking SELinux experience, and were wondering if there >> were additional Puppet/SELinux users out there who might weigh in on this? >> >> thanks, >> Josh >> >> -- >> Josh Partlow >> jpar...@puppetlabs.com >> Developer, Puppet Labs >> >> Join us at PuppetConf 2014, September 20-24 in San Francisco >> Register by September 8th to take advantage of the Final Countdown —save >> $149! >> > -- 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/05f2cdd3-437f-4179-89f4-3224c756443d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
