Issue #1590 has been updated by jerico.
> Are you saying we should extract the CA into a separate application entirely > and it should run as root only? Yes, that's right. Either extract it to puppetca or let the user use openssl proper. I am proposing that this should be a configurable option for those users who want it. Let's say that there will be an "automatic CA setup" (=default) and a "manual CA setup". "Automatic CA mode" is what we have today. If the user chooses "manual CA mode", however, then puppetmasterd will no longer be able to: - generate the the CA root certificate (above all it's private key...) - read the CA root certificate's private key - generate client certificate requests - sign client certificate requests - write to the CRL This policy will be enforced at an OS permission level. This means that all certificates and keys as well as their containing directories will be owned by root and their permissions adjusted to least privilege. In "manual CA mode" the private root CA key should be maintained on a dedicated machine (possibly without network connection). > If so, then I assume we have to build an API between it and puppetmasterd, so > that it can still do some CA operations? The only operation puppetmasterd could continue to do is sending back signed certificates to the clients. puppetd could continue to: - automatically generate client certificates/keys - send certificate requests to the central puppetmasterd machine so that they can be collected in a central place puppetmasterd would however no longer be able to sign requests nor to generate the initial root ca certificate/key, nor would puppetd clients accept trusted root certificates sent over from puppetmasterd. These steps would have to be done manually through puppetca or easy-rsa/openssl proper. I admit that this is far less comfortable than having puppetmasterd doing all the work. But it's the only way I see how you get better protection for your root key. People who use such an expert mode will probably be able to generate and install all certificates/keys etc. with openssl or easy-rsa, however. It only needs to be documented how puppet must be configured to set the correct permissions for keys and keep it from automatically transferring the trusted root certificate. If you want to improve usability you might use puppetca to hide at least some of the complexity of the openssl application... Maybe something like (not very well thought out though): puppetca --generate-root-certificate could generate the root CA certificate/key infrastructure. puppetca --install-root-certificate could install the root certificate in the right place on the clients puppetca --sign should continue to work normally on the dedicated CA machine. I admit that if puppetmasterd is compromised then there are probably other possiblities of compromising the clients. But IMO this doesn't justify leaving attack vectors open where they could be blocked. Maybe there are some security experts in the puppet user community who comment on this? ---------------------------------------- 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 puppet-bugs@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
