<div dir="ltr"><div><div><div><div><div>A few operators have requested if its possible to limit sudo's coverage on both the under / overcloud. There is concern over `<span class="gmail-">ALL=(ALL) NOPASSWD:ALL` , which allows someone to  `sudo su`.</span><br><span class="gmail-"></span></div><span class="gmail-"><br></span></div><span class="gmail-">This task has come under the care of the tripleo security squad. <br><br></span></div><span class="gmail-">The work is being tracked and discussed here [0].<br><br></span></div><span class="gmail-">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:<br><br><span class="gmail-">ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap /etc/ironic/rootwrap.conf *    <br><br></span></span></div><div><span class="gmail-"><span class="gmail-">It's fairly easy to pick up a list of all sudo calls using a simple script [1]<br><br></span></span></div><div><span class="gmail-"><span class="gmail-">The other prolific user of sudo is ansible / stack, for example:<br></span></span><br><span class="gmail-"><span class="gmail-">/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<br><br></span></span></div><div><span class="gmail-"><span class="gmail-">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].<br></span></span></div><div><span class="gmail-"><span class="gmail-"><br></span></span></div><div>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. <br><br>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]<br><br>[0] <a href="https://etherpad.openstack.org/p/tripleo-heat-admin-security">https://etherpad.openstack.org/p/tripleo-heat-admin-security</a><br>[1] <a href="https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f">https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f</a><br></div><div><span class="gmail-"></span></div><span class="gmail-"><br></span><div><div><div><div><div><div><div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8px">Luke Hinds</span><br style="font-size:12.8px"></div></div></div></div></div></div>
</div></div></div></div></div></div></div></div>