On Thursday, January 17, 2013 4:24:29 AM UTC-6, Nacho Barrientos Arias wrote: > > Hi, > > On Wed, Jan 16, 2013 at 10:05 PM, jcbollinger > <john.bo...@stjude.org<javascript:> > > wrote: > >> >> Mostly. The master normally runs as an unprivileged user, so file and >> directory access controls apply to it. If you run SELinux in enforcing >> mode then SELinux policy applies no matter what user the master runs as. >> There are a couple of places to which the master needs to write (its log, >> its cache, ...), but appropriate access controls will prevent it from >> writing elsewhere (its config file, module directories, unrelated system >> directories, etc.). >> > > Thanks for replying. > > That's what we're kinda trying to do now but it's not just a matter of > limiting what the Puppet master can write I'm afraid. It's also important > what it can read. >
Well why didn't you say so before? Nevertheless, my earlier comments apply just as much to read access as to write access. > > We're using the Hiera GPG backend and the secret part of the key is stored > in the masters and must to be readable by the 'puppet' user so secrets can > be decrypted at catalog compilation time. Everyone could use a custom > function to read the key and put it in a place where it can be fetched > afterwards. > Whatever the master can do, it can do. There is no compartmentalization inside. If you do not trust your module maintainers then you are pretty much incapacitated already, They can do a lot of harm if they wish, or even by accident. In particular, what does it matter if they steal the GPG key? They would still have access to all of the data stored in hiera even if you could keep them from getting the key itself. Personally, I think GPG for the hiera data is a waste of time. It is intended, I suppose, to protect the data store against an assailant who has access to the master. Before that protection is relevant, however, the assailant needs to be able to overcome the system's internal access controls. If he can do that, then he can read the key, or spoof or eavesdrop on any process that obtains the key from elsewhere. Basically, you are looking for an automated solution for a job that really requires human eyes. If you do not fully trust the people writing and maintaining your manifests, then you should institute code review as a mandatory part of your process. > > Dunno, looks like my concern is going beyond of my original question a > bit. I'm probably implicitly asking now if there's any way to totally > disable remote code execution. > What does remote execution have to do with it? Puppet custom functions reside locally on the master and are executed on the master. > > About fine-grained ACLs on the writable directories, I still can think of > some cases where users might end up doing malicious things, for instance > erasing all the log files or even the facts cache living in > /var/lib/puppet/yaml/facts. > > Yes, that's why my original answer was "mostly." Again, if you don't trust the maintainers of your code base then you need to monitor their work. Code reviews as a standard, mandatory part of the process are the best way I can think of to accomplish that. They're a good practice for other reasons, too. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/rAh5iZSBhSAJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
