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