Issue #1590 has been updated by luke. Status changed from Needs design decision to Rejected
It sounds like what you're really saying is, we should make it so someone else can use a completely different certificate authority with Puppet. All you seem to be retaining is the ability to pass signed certs back to the client, which is pretty trivial. You say it would retain the ability to generate client certs, but you can't have that without the CA key. When 0.25 comes out, it will be downright straightforward for you to write plugins that do all reading and writing from a central, protected host, and you can build that host however you want. At this point, I'm willing to look at patches that explicitly point to areas where we could make it easier to integrate an external, more tightly controlled CA, but I'm not willing to modify the builtin CA to be more controlled. You could even use Puppet's CA on that controlled machine, since it's not really root you're concerned about, it's having a networked process with write rights. Just use puppetca with no puppetmasterd. And for the record, the current CA's entire job is to wrap openssl -- that's the whole reason it exists, so there's not much point in talking about making another wrapper for it. ---------------------------------------- Bug #1590: wrong permissions/ownership for ca key http://projects.reductivelabs.com/issues/show/1590 Author: jerico Status: Rejected 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 -~----------~----~----~----~------~----~------~--~---
