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
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
