FAQ
Hello,

I am trying to better understand the security impact a compromised host
managed by puppet could have on our infrastructure.

Suppose an attacker gained root on a machine called 'owned', and we have
this in site.pp:

node owned {
     file {'foo':
         content => 'puppet:///modules/module_name/foo',
     }
}

Will agent running on 'owned' be able to retrieve:
  - <modulepath>/module_name/files/bar
  - <modulepath>/module_name/manifests
  - hiera data (other than what it's supposed to have access to)


Thanks very much,

Vlad



--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Ellison Marks at May 30, 2013 at 11:27 pm
    Pretty much everything in puppet is secured with SSL certificates. If
    someone has root access to one of your client machines, they have that
    certificate. They can then retrieve anything that that node is allowed to
    retrieve, which is generally specified in auth.conf. By default, I think
    this includes their own catalog, their own node definition, all files
    served by the master process... a few other things.

    It shouldn't be able to get at your manifests directly, as those are
    compiled before being sent to the client, nor should it be able to get at
    hiera data on the master.
    On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik wrote:

    Hello,

    I am trying to better understand the security impact a compromised host
    managed by puppet could have on our infrastructure.

    Suppose an attacker gained root on a machine called 'owned', and we have
    this in site.pp:

    node owned {
    file {'foo':
    content => 'puppet:///modules/module_name/foo',
    }
    }

    Will agent running on 'owned' be able to retrieve:
    - <modulepath>/module_name/files/bar
    - <modulepath>/module_name/manifests
    - hiera data (other than what it's supposed to have access to)


    Thanks very much,

    Vlad


    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Nick Fagerlund at May 31, 2013 at 1:09 am
    Hi Vlad,

    This is all more or less dictated by the auth.conf file, although the
    implications can take a little while to chase down. You can see
    http://docs.puppetlabs.com/guides/rest_auth_conf.html for the syntax of
    this file and its general capabilities. The default rules in Puppet 3.x are
    here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf

    Moving on to your concrete questions:

    - "Owned" would NOT be able to directly access ANY manifests or Hiera data.

    In current versions of Puppet with default auth.conf, it works like this: A
    node is allowed to access the /catalog/<NAME> HTTP endpoint, where NAME
    *must* be the node's own certificate name. (Nodes cannot access
    /catalog/<SOMEONE ELSE>.) A GET request to this endpoint causes the puppet
    master to use its manifests and Hiera data to compile a "catalog." (We
    mention this here:
    http://docs.puppetlabs.com/puppet/latest/reference/lang_summary.html#compilation-and-catalogs)


    A catalog is not just a subset of manifests; it removes all conditional
    logic, irrelevant data, etc., and becomes an unambiguous single-node
    document, rather than a contingent multi-node piece of code. All Hiera data
    gets resolved, and becomes literal node-appropriate values in the catalog.

    - By default, "owned" WOULD be able to access file contents in
    <modulepath>/module_name/files. This can be prevented by making additional
    rules in auth.conf for specific modules you are worried about.

    The default auth.conf allows all certified nodes to access any endpoint
    beginning with /file. When fetching file contents for
    <modulepath>/my_module/files/this_file.txt, puppet agent hits
    /file_metadata/modules/my_module/this_file.txt (to check whether it already
    has the correct content) and then
    /file_content/modules/my_module/this_file.txt (to fetch the content if it
    isn't up to date). These are both prefixed by "/file", so everyone can get
    them. Nodes can also use the "file_metadatas" endpoint to get directory
    listings.

    If you have files in a special module that you are worried about, and if
    you can express the nodes who are allowed to access it in terms of
    certificate name or IP address, you can create a new auth.conf rule for
    that module and place it ABOVE the "/file" rule in auth.conf:

    path ~ ^/file_(metadata|content)s?/modules/my_module
    auth yes
    allow /^(.+)\.dmz\.example\.com$/
    allow_ip 192.168.100.0/24

    This trick also works for custom fileserver mount points as defined in
    fileserver.conf (http://docs.puppetlabs.com/guides/file_serving.html),
    which may be a better choice for highly sensitive files.

    Finally, for truly sensitive content, you have some extra options:

    - You can avoid the "source" attribute for sensitive files, and use
    "content" instead. This compiles the approved content for THAT NODE into
    the catalog. You can use the template() function
    (http://docs.puppetlabs.com/references/latest/function.html#template) to
    get content from an external file which nodes cannot directly access, and
    if your manifests make sure that only highly trusted nodes will have that
    content compiled into their catalogs, the information is effectively
    protected from less-trusted nodes that get owned.
    - You can investigate the hiera-gpg tool, which... I'm afraid I haven't
    learned how to use it, yet, but it promises a fairly robust way to handle
    dangerous content.

    Also, keep in mind that facts
    (http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#facts-and-built-in-variables)
    reported by the node are not necessarily trustworthy -- If you are using
    facts to make decisions about who can access certain content, it may be
    possible for an attacker to guess a fact value that will get them something
    interesting in their catalog. Note also that the special $clientcert
    variable is essentially just a fact; it isn't validated by the puppet
    master. We're currently investigating adding a trusted certificate name
    variable, see here: http://projects.puppetlabs.com/issues/19514

    Hope that helps,

    N

    On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik wrote:

    Hello,

    I am trying to better understand the security impact a compromised host
    managed by puppet could have on our infrastructure.

    Suppose an attacker gained root on a machine called 'owned', and we have
    this in site.pp:

    node owned {
    file {'foo':
    content => 'puppet:///modules/module_name/foo',
    }
    }

    Will agent running on 'owned' be able to retrieve:
    - <modulepath>/module_name/files/bar
    - <modulepath>/module_name/manifests
    - hiera data (other than what it's supposed to have access to)


    Thanks very much,

    Vlad


    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Vladimir Brik at May 31, 2013 at 2:01 pm
    Nick,

    Thank you very much for the detailed explanation!

    Vlad
    On 05/30/13 20:09, Nick Fagerlund wrote:
    Hi Vlad,

    This is all more or less dictated by the auth.conf file, although the
    implications can take a little while to chase down. You can see
    http://docs.puppetlabs.com/guides/rest_auth_conf.html for the syntax of
    this file and its general capabilities. The default rules in Puppet 3.x
    are here: https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf

    Moving on to your concrete questions:

    - "Owned" would NOT be able to directly access ANY manifests or Hiera data.

    In current versions of Puppet with default auth.conf, it works like
    this: A node is allowed to access the /catalog/<NAME> HTTP endpoint,
    where NAME *must* be the node's own certificate name. (Nodes cannot
    access /catalog/<SOMEONE ELSE>.) A GET request to this endpoint causes
    the puppet master to use its manifests and Hiera data to compile a
    "catalog." (We mention this here:
    http://docs.puppetlabs.com/puppet/latest/reference/lang_summary.html#compilation-and-catalogs)


    A catalog is not just a subset of manifests; it removes all conditional
    logic, irrelevant data, etc., and becomes an unambiguous single-node
    document, rather than a contingent multi-node piece of code. All Hiera
    data gets resolved, and becomes literal node-appropriate values in the
    catalog.

    - By default, "owned" WOULD be able to access file contents in
    <modulepath>/module_name/files. This can be prevented by making
    additional rules in auth.conf for specific modules you are worried about.

    The default auth.conf allows all certified nodes to access any endpoint
    beginning with /file. When fetching file contents for
    <modulepath>/my_module/files/this_file.txt, puppet agent hits
    /file_metadata/modules/my_module/this_file.txt (to check whether it
    already has the correct content) and then
    /file_content/modules/my_module/this_file.txt (to fetch the content if
    it isn't up to date). These are both prefixed by "/file", so everyone
    can get them. Nodes can also use the "file_metadatas" endpoint to get
    directory listings.

    If you have files in a special module that you are worried about, and if
    you can express the nodes who are allowed to access it in terms of
    certificate name or IP address, you can create a new auth.conf rule for
    that module and place it ABOVE the "/file" rule in auth.conf:

    path ~ ^/file_(metadata|content)s?/modules/my_module
    auth yes
    allow /^(.+)\.dmz\.example\.com$/
    allow_ip 192.168.100.0/24

    This trick also works for custom fileserver mount points as defined in
    fileserver.conf (http://docs.puppetlabs.com/guides/file_serving.html),
    which may be a better choice for highly sensitive files.

    Finally, for truly sensitive content, you have some extra options:

    - You can avoid the "source" attribute for sensitive files, and use
    "content" instead. This compiles the approved content for THAT NODE into
    the catalog. You can use the template() function
    (http://docs.puppetlabs.com/references/latest/function.html#template) to
    get content from an external file which nodes cannot directly access,
    and if your manifests make sure that only highly trusted nodes will have
    that content compiled into their catalogs, the information is
    effectively protected from less-trusted nodes that get owned.
    - You can investigate the hiera-gpg tool, which... I'm afraid I haven't
    learned how to use it, yet, but it promises a fairly robust way to
    handle dangerous content.

    Also, keep in mind that facts
    (http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#facts-and-built-in-variables)
    reported by the node are not necessarily trustworthy -- If you are using
    facts to make decisions about who can access certain content, it may be
    possible for an attacker to guess a fact value that will get them
    something interesting in their catalog. Note also that the special
    $clientcert variable is essentially just a fact; it isn't validated by
    the puppet master. We're currently investigating adding a trusted
    certificate name variable, see here:
    http://projects.puppetlabs.com/issues/19514

    Hope that helps,

    N


    On Thursday, May 30, 2013 1:24:27 PM UTC-7, Vladimir Brik wrote:

    Hello,

    I am trying to better understand the security impact a compromised
    host managed by puppet could have on our infrastructure.

    Suppose an attacker gained root on a machine called 'owned', and we
    have this in site.pp:

    node owned {
    file {'foo':
    content => 'puppet:///modules/module_name/foo',
    }
    }

    Will agent running on 'owned' be able to retrieve:
    - <modulepath>/module_name/files/bar
    - <modulepath>/module_name/manifests
    - hiera data (other than what it's supposed to have access to)


    Thanks very much,

    Vlad



    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 30, '13 at 8:26p
activeMay 31, '13 at 2:01p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase