Issue #1765 has been updated by andrew.
I know puppet is a little more complicated than grep, but philosophically I like the idea of simple tools with clear responsibilities connecting together to do interesting things. If a machine is compromised, spoofing facter's fqdn is not going to be harder than spoofing the cert. If DNS can facilitate the reverse lookup then that could already be already be leveraged to do what is suggested using external nodes. You can write arbitrary logic and decide what classes should be returned to the host. So your external nodes just needs to compare whatever you think is appropriate and then return the classes for that host or sound the alarm and return the 'nosoupforyou' class. The fqdn/ip and reverse look up should be almost trivial to implement there. I can imagine some more complicated dynamic schemes with custom facts that would make it even harder to compromise, but that's probably gratuitous. ---------------------------------------- Bug #1765: Certificate hostnames are not verified http://projects.reductivelabs.com/issues/show/1765 Author: IanTurner Status: Needs design decision Priority: Normal Assigned to: Category: SSL Target version: Complexity: Hard Affected version: 0.24.6 Keywords: certificate security spoof validation authentication dns The puppetmaster only verifies the validity of the client certificate, but does not verify the associated hostname. Thus a client with a certificate signed as "publicserver" can instead claim to be "secretserver" and gain access to the latter's configuration. This certificate hostname spoofing can be a serious issue, since client configuration may include password hashes and other confidential data. The best approach to client validation is to verify that all three of the following are identical at the FQDN level: 1. The FQDN on the signed client certificate. 2. The FQDN presented by the client facter invocation. 3. The result of a reverse lookup on the connecting client IP address. Additionally, an address (A/AAAA record, not CNAME record) lookup on this FQDN should in turn yield the connecting client IP address in the query result. ---------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
