FAQ
Hi,

Maybe I'm missing something obvious because my question sounds very naive
to me. Anyway, here I go:

Is it possible to prevent module developers from writing files in the
master via custom Puppet functions[0]?

At least in my environment[1] I can come up with several malicious things
that users could end up doing. For instance, the modules directory that the
master uses to generate the catalogs is writable by the same user that runs
the Puppet daemon so every module developer could overwrite someone else's
work.

I'm running Puppet 2.7.18.

[0] http://docs.puppetlabs.com/guides/custom_functions.html
[1] Access to Puppet masters is restricted to a few but we have many
"unrelated" people using them and writing their own manifests to configure
their services.

Thanks!
N

--
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/-/-4AitY-Ntq8J.
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.

Search Discussions

  • Jcbollinger at Jan 16, 2013 at 9:12 pm

    On Wednesday, January 16, 2013 4:30:28 AM UTC-6, Nacho Barrientos wrote:
    Hi,

    Maybe I'm missing something obvious because my question sounds very naive
    to me. Anyway, here I go:

    Is it possible to prevent module developers from writing files in the
    master via custom Puppet functions[0]?
    Mostly. The master normally runs as an unprivileged user, so file and
    directory access controls apply to it. If you run SELinux in enforcing
    mode then SELinux policy applies no matter what user the master runs as.
    There are a couple of places to which the master needs to write (its log,
    its cache, ...), but appropriate access controls will prevent it from
    writing elsewhere (its config file, module directories, unrelated system
    directories, etc.).


    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/-/4UT6h8ICls8J.
    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.
  • Nacho Barrientos Arias at Jan 17, 2013 at 10:25 am
    Hi,
    On Wed, Jan 16, 2013 at 10:05 PM, jcbollinger wrote:


    Mostly. The master normally runs as an unprivileged user, so file and
    directory access controls apply to it. If you run SELinux in enforcing
    mode then SELinux policy applies no matter what user the master runs as.
    There are a couple of places to which the master needs to write (its log,
    its cache, ...), but appropriate access controls will prevent it from
    writing elsewhere (its config file, module directories, unrelated system
    directories, etc.).
    Thanks for replying.

    That's what we're kinda trying to do now but it's not just a matter of
    limiting what the Puppet master can write I'm afraid. It's also important
    what it can read.

    We're using the Hiera GPG backend and the secret part of the key is stored
    in the masters and must to be readable by the 'puppet' user so secrets can
    be decrypted at catalog compilation time. Everyone could use a custom
    function to read the key and put it in a place where it can be fetched
    afterwards.

    Dunno, looks like my concern is going beyond of my original question a bit.
    I'm probably implicitly asking now if there's any way to totally disable
    remote code execution.

    About fine-grained ACLs on the writable directories, I still can think of
    some cases where users might end up doing malicious things, for instance
    erasing all the log files or even the facts cache living in
    /var/lib/puppet/yaml/facts.

    Nacho

    --
    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.
  • Jcbollinger at Jan 17, 2013 at 2:30 pm

    On Thursday, January 17, 2013 4:24:29 AM UTC-6, Nacho Barrientos Arias wrote:

    Hi,

    On Wed, Jan 16, 2013 at 10:05 PM, jcbollinger <John.Bo...@stjude.org<javascript:>
    wrote:
    Mostly. The master normally runs as an unprivileged user, so file and
    directory access controls apply to it. If you run SELinux in enforcing
    mode then SELinux policy applies no matter what user the master runs as.
    There are a couple of places to which the master needs to write (its log,
    its cache, ...), but appropriate access controls will prevent it from
    writing elsewhere (its config file, module directories, unrelated system
    directories, etc.).
    Thanks for replying.

    That's what we're kinda trying to do now but it's not just a matter of
    limiting what the Puppet master can write I'm afraid. It's also important
    what it can read.

    Well why didn't you say so before?

    Nevertheless, my earlier comments apply just as much to read access as to
    write access.


    We're using the Hiera GPG backend and the secret part of the key is stored
    in the masters and must to be readable by the 'puppet' user so secrets can
    be decrypted at catalog compilation time. Everyone could use a custom
    function to read the key and put it in a place where it can be fetched
    afterwards.

    Whatever the master can do, it can do. There is no compartmentalization
    inside.

    If you do not trust your module maintainers then you are pretty much
    incapacitated already, They can do a lot of harm if they wish, or even by
    accident. In particular, what does it matter if they steal the GPG key?
    They would still have access to all of the data stored in hiera even if you
    could keep them from getting the key itself.

    Personally, I think GPG for the hiera data is a waste of time. It is
    intended, I suppose, to protect the data store against an assailant who has
    access to the master. Before that protection is relevant, however, the
    assailant needs to be able to overcome the system's internal access
    controls. If he can do that, then he can read the key, or spoof or
    eavesdrop on any process that obtains the key from elsewhere.

    Basically, you are looking for an automated solution for a job that really
    requires human eyes. If you do not fully trust the people writing and
    maintaining your manifests, then you should institute code review as a
    mandatory part of your process.

    Dunno, looks like my concern is going beyond of my original question a
    bit. I'm probably implicitly asking now if there's any way to totally
    disable remote code execution.

    What does remote execution have to do with it? Puppet custom functions
    reside locally on the master and are executed on the master.


    About fine-grained ACLs on the writable directories, I still can think of
    some cases where users might end up doing malicious things, for instance
    erasing all the log files or even the facts cache living in
    /var/lib/puppet/yaml/facts.
    Yes, that's why my original answer was "mostly." Again, if you don't
    trust the maintainers of your code base then you need to monitor their
    work. Code reviews as a standard, mandatory part of the process are the
    best way I can think of to accomplish that. They're a good practice for
    other reasons, too.


    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/-/rAh5iZSBhSAJ.
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 16, '13 at 2:37p
activeJan 17, '13 at 2:30p
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase