Issue #1590 has been updated by luke.
The puppetmasterd process creates the CA keys and such, so it definitely needs write access to them. I'm okay with some of these changes (although that rundir change is not acceptable; it's a pain to get that right, and no one is complaining about it right now), but in general, the puppetmasterd process is entirely responsible for managing certificates. None of these permissions change in 0.25 AFAIK; all that changes is what classes need access to the files. You're right that if puppetmasterd is compromised then you're screwed, but that's the case with any CA, right? If we accept these changes, then we're in the situation where creating a CA requires root access, and even worse, some small initialization step requires root and the rest of the time you should not be root. I think this is a bad idea, so please provide better justification for the change. And again, please remove the change to the rundir; if you think there's a problem there, file a separate bug. That goes for any other bugs you're trying to fix -- each ticket is for one bug at a time. ---------------------------------------- Bug #1590: wrong permissions/ownership for ca key http://projects.reductivelabs.com/issues/show/1590 Author: jerico Status: Needs design decision Priority: Normal Assigned to: luke Category: SSL Target version: unplanned Complexity: Medium Affected version: 0.24.4 Keywords: The default puppet ca is poorly protected. Much of the use of running puppetmasterd as a dedicated user is lost as sensitive ca files (=password, key, crl) establishing encryption and authentication/authorization are writeable by the puppet user by default. -rw-rw---- 1 puppet puppet ca_key.pem -rw-rw-r-- 1 puppet puppet ca_crl.pem -rw-rw---- 1 puppet puppet ca.pass There are two problems with this setup: These files should have root ownership and they should not be writeable by puppetmasterd at runtime. Somebody achieving control through a 0-day bug in the puppetmasterd process will be able to work around encryption, authentication and authorization. IMO this issue is a potential remote exploit and therefore critical. IMO best fix: Start puppetmasterd with root privileges, read (or create) the files, then downgrade to configured low-privilege user as soon as possible. This is a practice implemented by many high profile daemons (e.g. apache2, openvpn, ...) and can be easily combined with a chroot strategy. Alternatively: Create a root level admin tool that creates the CA and PKI with root:puppet ownership and 640 permissions. ---------------------------------------- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://reductivelabs.com/redmine/my/account --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
