> > [snip] > > > > 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. >
That's what I was thinking as well; thanks for clarifying. I think that we can split the difference here - that is, we can store SELinux configuration in the main puppet.conf and still run in a confined manner when we're exposed to user operations. In order to run in a manner that could have security implications, we wind up having to read puppet.conf anyways - for the agent, we need to know which server to connect to, and for the webrick server we need to determine which interface/port we need to listen on. In each case we have to load configuration before exposing the process to security threats; this means that we can read SELinux configuration from puppet.conf, change the SELinux domain as necessary, and then start normal operations. Taking this approach takes away one of my bigger concerns about the existing pull request - the secondary configuration mechanism. Treating SELinux configuration as just another set of configuration options is consistent and unsurprising. One downside of this approach is that if a user runs Puppet with a custom confdir and bypasses the SELinux configuration then that security is gone, but using environment variables doesn't make this any better. In the case where Puppet is running under Passenger, is it safe to assume that any SELinux domain transitions have already occurred? As a general note, we should make sure that the result of this conversation makes it back onto the JIRA ticket so we have a record of the design when we go into actually writing something. -- Adrien Thebo | Puppet Labs -- 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/CALVJ9SJJtoRAZY4_4Acymhsau_3831p7puQxRkSfGdSN64HSQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
