Puppet users - Jan 2013 - Restrict file creation in the masters

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.

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.

Hi,

On Wed, Jan 16, 2013 at 10:05 PM, jcbollinger
<John.Bollinger@stjude.org>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.

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.