Puppet users - Jan 2013 - Security considerations for basing decisions on facts

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

On Tuesday, January 22, 2013 7:08:09 AM UTC-6, Boyan Tabakov
wrote:
>
> 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? 
>
>
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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/CymeL7ZdAqcJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Jan 22, 2013, at 3:04 PM, jcbollinger <John.Bollinger@stJude.org>
wrote:
>
>
> On Tuesday, January 22, 2013 7:08:09 AM UTC-6, Boyan Tabakov wrote:
> 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?
>
>
>
> 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
>
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.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/s2DSmxqSpmYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 1/23/2013 12:22 PM, Jist Anidiot wrote:
> 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.
	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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.