Open Stack

On 05/21/2018 03:49 PM, Luke Hinds wrote:
> A few operators have requested if its possible to limit sudo's coverage
> on both the under / overcloud. There is concern over `ALL=(ALL)
> NOPASSWD:ALL` , which allows someone to  `sudo su`.
> 
> This task has come under the care of the tripleo security squad.
> 
> The work is being tracked and discussed here [0].
> 
> So far it looks like the approach will be to use regexp within
> /etc/sudoers.d/*., to narrow down as close as possible to the specific
> commands called. Some services already do this with rootwrap:
> 
> ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap
> /etc/ironic/rootwrap.conf *   
> 
> It's fairly easy to pick up a list of all sudo calls using a simple
> script [1]
> 
> The other prolific user of sudo is ansible / stack, for example:
> 
> /bin/sh -c echo BECOME-SUCCESS-kldpbeueyodisjajjqthpafzadrncdff;
> /usr/bin/python
> /home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/systemd.py;
> rm -rf
> "/home/stack/.ansible/tmp/ansible-tmp-1526579105.0-109863952786117/" >
> /dev/null 2>&1
> 
> My feelings here are to again use regexp around the immutable non random
> parts of the command.  cjeanner also made some suggestions in the
> etherpad [0].

Might be a temporary way to limit the surface indeed, but an upstream
change in Ansible would still be really nice. Predictable names is the
only "right" way, although this will create a long sudo ruleset. A
really long one to be honnest. Maintainability is also to be discussed
in either way (maintain a couple of regexp vs 200+ rules.. hmmm).

> 
> However aside to the approach, we need to consider the impact locking
> down might have should someone create a develop a new bit of code that
> leverages commands wrapped in sudo and assumes ALL with be in place.
> This of course will be blocked.

This will indeed require some doc, as this is a "major" change. However,
the use of regexp should somewhat limit the impact, especially since
Ansible pushes its exec script in the same location.
Even new parts should be allowed (that might be a bit of concern if we
want to really dig in the consequences of a bad template being injected
in some way [looking config-download ;)]).
But at some point, we might also decide to let the OPs ensure their
infra isn't compromised.
Always the same thread-of with Security vs The World - convenience vs
cumbersome management, and so on.

> 
> Now my guess is that our CI would capture this as the deploy would
> fail(?) and the developer should work out an entry is needed when
> testing their patch, but wanted to open this up to others who know
> testing at gate better much better than myself.  Also encourage any
> thoughts on the topic to be introduced to the etherpad [0]
> 
> [0] https://etherpad.openstack.org/p/tripleo-heat-admin-security
> [1] https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f
> 
> -- 
> Luke Hinds

-- 
Cédric Jeanneret
Software Engineer
DFG:DF

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180522/10234770/attachment.sig>