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 <dclea...@redhat.com> 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 puppet-dev+unsubscr...@googlegroups.com. > 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 tvaug...@onyxpoint.com -- 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 puppet-dev+unsubscr...@googlegroups.com. 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.
