Just out of curiosity, are you going to double wrap this in a Java Security Policy for those systems that don't have SELinux?
Thanks, Trevor On Fri, Mar 27, 2015 at 5:49 AM, Dominic Cleal <[email protected]> wrote: > On 26/03/15 19:25, Melissa Stone wrote: > > 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? > > Yes, that's the most common way. Having separate binaries helps a lot, > as they can be labelled differently. > > > 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? > > Indeed, I think a lot of these ideas are obsolete with a move towards > Puppet Server and the JVM as the process startup obviously changes > significantly. It probably isn't worth trying to confine the older Ruby > "puppet" binary now. > > The SELinux context will be process-wide, so affects all services within > the JVM, so any policy that would be created would have to cover all > services that might run inside it. > > > And now for more implementation oriented questions: > > > > > > SELinux domains > > > > What domains do we need for Puppet + SELinux? What resources do they > > need access to? > > Confining anything that listens on the network should probably be the > priority, i.e. the master, as that's the main attack surface. A policy > would have to give access to any local state files it uses, config > files, modules, through to any network connections it makes too. > > > > > 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? > > I suppose what we would want to avoid is a period in which something > external, such as a user on the network (probably not an issue) or some > untrusted code is loaded or executed that could access resources that > the server wouldn't have access to when confined. > > As a hand waving example, if we loaded environments and executed custom > types, or configuration somehow referenced another file (/etc/shadow for > argument's sake) which was read before confining the server, then this > wouldn't be ideal. Confining the process earlier would help. > > > 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? > > Indeed, opt-in makes sense to fix those problems. Or, if the entire > process can be confined by using filesystem labels or a systemd unit > file (SELinuxContext) then it's even easier, as that happens in policy > or packaging only, which wouldn't affect gem or source usage. > > -- > Dominic Cleal > Red Hat Engineering > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/55152795.3070300%40redhat.com > . > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoXQQ_tK0cUAkQb1ZbLP%3DV%2B_nuUp2Q-qyYVknM6XoyaTkQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
