Security considerations for basing decisions on facts

[Boyan Tabakov]

Hello,

Let's consider the scenario when a client node in a puppet environment
gets compromised.

In case some of the puppet modules make decisions based on agent facts,
these modules are potentially exposed to abuse from the malicious puppet
agent.

For example, if a class has:

if $some_fact == 'some value' {
# deploy some configuration
}

then the compromised node could send falsified value of that fact to
obtain configuration that potentially contains secrets (private keys,
passwords, etc) that was meant only for other nodes.

AFAIK, the only authenticated piece of information that a puppet agent
passes to the puppetmaster server is the name of the node, as specified
in the SSL certificate for the agent. However, the value of $fqdn, as
seen in a manifest / class on the puppetmaster seems to be based on the
agent-supplied fact 'fqdn'.

Having said that, then can the value of $hostname be trusted to come
from the identity in the agent's SSL certificate? What are best
practices for ensuring that a compromised agent can't access
configuration meant for different nodes?

Are an ENC or external data sources (Hiera) designed to provide trusted
puppetmaster-side metadata for nodes? Is that the way to go?

Thanks in advance!

Best regards,
Boyan Tabakov

[jcbollinger]

You are correct that that only the identity of the client node is authenticated by Puppet, and even that only insomuch as the client can be relied upon to protect its SSL certificate.  The $hostname fact cannot be relied upon to convey that information, as it doesn't in any sense need to be the same thing; you're looking for $certname.  It is, however, $certname (not $hostname) by which a node block is selected and/or an ENC queried, so Puppet's architectural foundation is secure in that regard.

You are also right that a compromised client can, in principle, falsify the fact values presented to the master in an attempt to make it divulge secret information.  Whether the master might actually divulge anything is a function of the manifests with which site administration has configured it.  In other words, that's a question of how Puppet is used, not of the fundamental security of Puppet itself.

To the extent that you want to record server-side node data, I think hiera is the way to go.  I prefer that to encoding data in an ENC or in your manifests, but those are some of the other options.  All of those are secure to the extent that the master itself is secure, though I wouldn't say that any of them were designed specifically as a secure alternative to node facts.


John

[Wolf Noble]

Several months ago I created a feature request which basically requested the ability to flag certain facts as 'should never change' and have the ability to trigger different behaviors in on the master if $node delivers its facts with those items different…

https://projects.puppetlabs.com/issues/13934


if a node reports memory changed, you might want to send an email (IE: a dimm failed, the box panic'ed and rebooted, and now has less memory). This could be done with other methods and tools, this feature doesn't need to be implemented to facilitate that (nor is it necessarily the best tool for the job), but if a node reports that it's fqdn, or '$proprietary_fact' is now different, you may want the master to full-stop on catalog compilation and flag the node as problematic and notify you, as someone may be doing something nasty.

you can also use an enc and base lookups off of $certname, as you can trust that you signed that cert at some point in time (assuming you don't have auto signing enabled) and so that should be trusted as legitimate.
if you have auto-signing enabled though, this could give someone a path into nefariousness.

W

________________________________

This message may contain confidential or privileged information. If you are not the intended recipient, please advise us immediately and delete this message. See http://www.datapipe.com/legal/email_disclaimer/ for further information on confidentiality and the risks of non-secure electronic communication. If you cannot access these links, please notify us by reply message and we will send the contents to you.

[Jist Anidiot]

On Tuesday, January 22, 2013 4:04:22 PM UTC-5, jcbollinger wrote:

You are correct that that only the identity of the client node is authenticated by Puppet, and even that only insomuch as the client can be relied upon to protect its SSL certificate.  The $hostname fact cannot be relied upon to convey that information, as it doesn't in any sense need to be the same thing; you're looking for $certname.  It is, however, $certname (not $hostname) by which a node block is selected and/or an ENC queried, so Puppet's architectural foundation is secure in that regard.

Do you mean the $clientcert variable which is described at http://docs.puppetlabs.com/guides/faq.html#are-there-variables-available-other-than-those-provided-by-facter
I don't seem to have a $certname variable (I'm using puppet 3).

Thanks in advance.

[Ramin K]

You would set certname = some.host.example.com in puppet.conf or use
--certname some.host.example.com on the command line else certname
defaults to nodename which defaults to fqdn. However clientcert is the
resulting fact you would access within Puppet.

Ramin

[Boyan Tabakov]

On 22.1.2013 23:04, jcbollinger wrote:
> You are correct that that only the identity of the client node is
> authenticated by Puppet, and even that only insomuch as the client can
> be relied upon to protect its SSL certificate. The $hostname fact
> cannot be relied upon to convey that information, as it doesn't in any
> sense need to be the same thing; you're looking for $certname. It is,
> however, $certname (not $hostname) by which a node block is selected
> and/or an ENC queried, so Puppet's architectural foundation is secure in
> that regard.
>
> You are also right that a compromised client can, in principle, falsify
> the fact values presented to the master in an attempt to make it divulge
> secret information. Whether the master might actually divulge anything
> is a function of the manifests with which site administration has
> configured it. In other words, that's a question of how Puppet is used,
> not of the fundamental security of Puppet itself.
>
> To the extent that you want to record server-side node data, I think
> hiera is the way to go. I prefer that to encoding data in an ENC or in
> your manifests, but those are some of the other options. All of those
> are secure to the extent that the master itself is secure, though I
> wouldn't say that any of them were designed specifically as a secure
> alternative to node facts.

Hello,

Yes, I agree it is a problem of the usage, rather than puppet itself.
Thanks for the confirmation!

Best regards,
Boyan

[Jakov Sosic]

On 01/22/2013 10:04 PM, jcbollinger wrote:

> You are also right that a compromised client can, in principle, falsify
> the fact values presented to the master in an attempt to make it divulge
> secret information. Whether the master might actually divulge anything
> is a function of the manifests with which site administration has
> configured it. In other words, that's a question of how Puppet is used,
> not of the fundamental security of Puppet itself.

One thing did cross my mind while reading your explanation. What about
private section in fileserver.conf?

I've set up a private section, as follows:

[private]
path /etc/puppet/private/%H
allow *


Does this mean that if compromised client fakes hostname fact (because I
presume that %H means hostname), it can get all the files from private
section? Can I maybe use certname in private section?


--
Jakov Sosic
www.srce.unizg.hr