<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 22, 2018 at 8:24 AM, Cédric Jeanneret <span dir="ltr"><<a href="mailto:cjeanner@redhat.com" target="_blank">cjeanner@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 05/22/2018 09:08 AM, Luke Hinds wrote:<br>
> <br>
> <br>
> On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret <<a href="mailto:cjeanner@redhat.com">cjeanner@redhat.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:cjeanner@redhat.com">cjeanner@redhat.com</a>>> wrote:<br>
> <br>
> <br>
> <br>
> On 05/21/2018 03:49 PM, Luke Hinds wrote:<br>
> > A few operators have requested if its possible to limit sudo's coverage<br>
> > on both the under / overcloud. There is concern over `ALL=(ALL)<br>
> > NOPASSWD:ALL` , which allows someone to `sudo su`.<br>
> > <br>
> > This task has come under the care of the tripleo security squad.<br>
> > <br>
> > The work is being tracked and discussed here [0].<br>
> > <br>
> > So far it looks like the approach will be to use regexp within<br>
> > /etc/sudoers.d/*., to narrow down as close as possible to the specific<br>
> > commands called. Some services already do this with rootwrap:<br>
> > <br>
> > ironic ALL = (root) NOPASSWD: /usr/bin/ironic-rootwrap<br>
> > /etc/ironic/rootwrap.conf * <br>
> > <br>
> > It's fairly easy to pick up a list of all sudo calls using a simple<br>
> > script [1]<br>
> > <br>
> > The other prolific user of sudo is ansible / stack, for example:<br>
> > <br>
> > /bin/sh -c echo BECOME-SUCCESS-<wbr>kldpbeueyodisjajjqthpafzadrncd<wbr>ff;<br>
> > /usr/bin/python<br>
> > /home/stack/.ansible/tmp/<wbr>ansible-tmp-1526579105.0-<wbr>109863952786117/systemd.py;<br>
> > rm -rf<br>
> > "/home/stack/.ansible/tmp/<wbr>ansible-tmp-1526579105.0-<wbr>109863952786117/" ><br>
> > /dev/null 2>&1<br>
> > <br>
> > My feelings here are to again use regexp around the immutable non random<br>
> > parts of the command. cjeanner also made some suggestions in the<br>
> > etherpad [0].<br>
> <br>
> Might be a temporary way to limit the surface indeed, but an upstream<br>
> change in Ansible would still be really nice. Predictable names is the<br>
> only "right" way, although this will create a long sudo ruleset. A<br>
> really long one to be honnest. Maintainability is also to be discussed<br>
> in either way (maintain a couple of regexp vs 200+ rules.. hmmm).<br>
> <br>
> <br>
> As I understand it, the problem with predicable names is they also<br>
> become predictable to attackers (this would be the reason ansible adds<br>
> in the random string). It helps prevent someone creating a race<br>
> condition to replace the python script with something more nefarious.<br>
> Its the same reason commands such as mktemp exists.<br>
<br>
</div></div>Fair enough indeed. Both solution have their pros and cons. In order to<br>
move on, I think the regexp in sudoers is acceptable for the following<br>
reasons:<br>
- limits accesses outside of ansible generated code<br>
- allows others to still push new content without having to change sudo<br>
listing (thanks to regexp)<br>
- still hard to inject bad things in the executed script/code<br>
- quick to implement (well, fastest than requiring an upstream change<br>
that will most probably break some internal things before working<br>
properly, and without adding more security as you explained it)<br>
<br></blockquote><div><br></div><div>Thanks for chiming in Cédric , value your contributions here.</div><div><br></div><div>I was thinking about this earlier on my way to work.. <br></div><div><br></div><div>Perhaps we could have a script in CI that fails on sudo calls being blocked (as no regexp exists for them)? This way it will prevent people going on a wild goose chase trying to work out why a patch they are working on has failed. As an example, someone might change a single argument in an iptables command (a few of those run under sudo) that desyncs the command to the sudo regexp?<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
@Juan do you agree with that statement? As we had some quick chat about it.<br>
<br>
Note: I'm not part of the security squad ;). But I like secured things.<br>
<div><div class="h5"><br>
> <br>
> > <br>
> > However aside to the approach, we need to consider the impact locking<br>
> > down might have should someone create a develop a new bit of code that<br>
> > leverages commands wrapped in sudo and assumes ALL with be in place.<br>
> > This of course will be blocked.<br>
> <br>
> This will indeed require some doc, as this is a "major" change. However,<br>
> the use of regexp should somewhat limit the impact, especially since<br>
> Ansible pushes its exec script in the same location.<br>
> Even new parts should be allowed (that might be a bit of concern if we<br>
> want to really dig in the consequences of a bad template being injected<br>
> in some way [looking config-download ;)]).<br>
> But at some point, we might also decide to let the OPs ensure their<br>
> infra isn't compromised.<br>
> Always the same thread-of with Security vs The World - convenience vs<br>
> cumbersome management, and so on.<br>
> <br>
> ><br>
> > Now my guess is that our CI would capture this as the deploy would<br>
> > fail(?) and the developer should work out an entry is needed when<br>
> > testing their patch, but wanted to open this up to others who know<br>
> > testing at gate better much better than myself. Also encourage any<br>
> > 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" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/tripleo-heat-admin-<wbr>security</a><br>
> <<a href="https://etherpad.openstack.org/p/tripleo-heat-admin-security" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/tripleo-heat-admin-<wbr>security</a>><br>
> > [1]<br>
> <a href="https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>lukehinds/<wbr>4cdb1bf4de526a049c51f05698b8b0<wbr>4f</a><br>
> <<a href="https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f" rel="noreferrer" target="_blank">https://gist.github.com/<wbr>lukehinds/<wbr>4cdb1bf4de526a049c51f05698b8b0<wbr>4f</a>><br>
> ><br>
> > --<br>
> > Luke Hinds<br>
> <br>
> -- <br>
> Cédric Jeanneret<br>
> Software Engineer<br>
> DFG:DF<br>
> <br>
> <br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
</div></div>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<span class="">> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat<br>
</span>> e: <a href="mailto:lhinds@redhat.com">lhinds@redhat.com</a> <mailto:<a href="mailto:lhinds@redhat.com">lhinds@redhat.com</a>> | irc: lhinds @freenode<br>
<span class="im HOEnZb">> |t: +44 12 52 36 2483<br>
> <br>
> <br>
</span><div class="HOEnZb"><div class="h5">> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
> <br>
<br>
-- <br>
Cédric Jeanneret<br>
Software Engineer<br>
DFG:DF<br>
<br>
</div></div><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-size:12.8px">Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat</span><br style="font-size:12.8px"><span style="font-size:12.8px">e: </span><a href="mailto:lhinds@redhat.com" style="color:rgb(17,85,204);font-size:12.8px" target="_blank">lhinds@redhat.com</a><span style="font-size:12.8px"> | irc: lhinds @freenode |</span><span style="font-size:12.8px"> t: </span>+44 12 52 36 2483<br style="font-size:12.8px"></div></div></div></div></div></div>
</div></div>