How to control who can add/update permissions in sudoers

[Alex Scoble]

Hi all,

We're currently on PE 3.8.4.

We need to be able to manage sudoers permissions with Puppet, but control things so sudoers permissions can only be granted within a specific module.

So permissions could be included via 'include foo::bar' from anywhere, but the actual sudoers permissions used by the include could only be set within the specific module that has access tightly controlled.

The goal is to prevent someone from injecting a new sudoers rule in to a module/manifest outside of our control.

Any ideas?

Thanks,

Alex

[Thomas Müller]

Look for assert_private in puppetlabs-stdlib module. Maybe its what you are looking for.

Thomas

[jcbollinger]

I don't think there is any reliable way to do what you ask from within Puppet.  You may be able to achieve it by completely protecting the sudo configuration from Puppet via mandatory access controls (SELinux) or a similar mechanism, but then Puppet cannot manage it at all.  Perhaps that's ok, but it seems rather pointless: if you do not trust your own manifests, then you are in a world of hurt.

There are innumerable things that an assailant wanting to breach your security could do with the ability to influence nodes' catalogs, and closing down just a single avenue -- if that were even possible -- misses the forest for the trees.  Anyone who can inject a single File or Exec resource into a node's catalog can very likely take control of that node if they so desire.  Therefore, I recommend procedural safeguards: control access to all your manifests, perform code reviews for all changes, etc..


John

[Rob Nelson]

I was coming in here to say the same thing John said. Your sudoers definition is going to be a combination of code (include sudo; sudo::conf {'whatever':}) and data (the sudo::conf attributes). That data can be embedded in your code, or come from a hiera/lookup backend. Both of those should be in some form of revision control with proper review policies and permissions. This ensures that only the correct people can submit/merge changes, and that all merged code is reviewed before it makes it to production.

I recommend Gary's blog post http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/ starting with the section "Just put it in the control repo" (lots of other good articles on the site as well). It describes some of the workflow impacts of a consolidated repo, and how that might be a positive or negative toward control of your data. As I read the recommendations, there are certainly valid reasons to keep some things out of the control repo, but only if you explicitly need to. It's up to you to determine if you need to, or if your code review and gating processes are sufficient.

Rob Nelson
rnel...@gmail.com

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f6dbf98e-03d8-40f2-92a1-a1807ffc2441%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Alex Scoble]

Problem is that if you don't have a way of limiting where sudo entries can be made, someone can create a new module and grant themselves full sudo rights there for a large number of systems. When in a large enterprise such as ours, there are modules that are created and maintained by teams outside of the main teams that maintain the bulk of the puppet code.

I think one possibility we are looking in to is using Teamcity (could also be done with Jenkins) to check that sudo calls aren't made outside of our protected sudo module.

[Rob Nelson]

This is probably something that should be addressed via code management or audits, rather than via puppet. It can't really know e intentions, so if someone wants to exec 'rm -fR' it will gleefully let it happen. It's on you to trust your developers and have a pipeline to test things. Canary nodes that can be audited may be a good idea here.

On Thursday, May 19, 2016, Alex Scoble <bloggi...@gmail.com> wrote:

Problem is that if you don't have a way of limiting where sudo entries can be made, someone can create a new module and grant themselves full sudo rights there for a large number of systems. When in a large enterprise such as ours, there are modules that are created and maintained by teams outside of the main teams that maintain the bulk of the puppet code.

I think one possibility we are looking in to is using Teamcity (could also be done with Jenkins) to check that sudo calls aren't made outside of our protected sudo module.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5198fce0-fb84-42fe-bc8e-b6c2b48141d3%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson
rnel...@gmail.com