Open Stack

On 05/22/2018 09:24 AM, Cédric Jeanneret wrote:
> 
> 
> On 05/22/2018 09:08 AM, Luke Hinds wrote:
>>
>>
>> On Tue, May 22, 2018 at 5:27 AM, Cédric Jeanneret <cjeanner at redhat.com
>> <mailto:cjeanner at redhat.com>> wrote:
>>
>>
>>
>>     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).
>>
>>
>> As I understand it, the problem with predicable names is they also
>> become predictable to attackers (this would be the reason ansible adds
>> in the random string). It helps prevent someone creating a race
>> condition to replace the python script with something more nefarious.
>> Its the same reason commands such as mktemp exists.
> 
> Fair enough indeed. Both solution have their pros and cons. In order to
> move on, I think the regexp in sudoers is acceptable for the following
> reasons:
> - limits accesses outside of ansible generated code
> - allows others to still push new content without having to change sudo
> listing (thanks to regexp)
> - still hard to inject bad things in the executed script/code
> - quick to implement (well, fastest than requiring an upstream change
> that will most probably break some internal things before working
> properly, and without adding more security as you explained it)

Small idea: it might be interesting to check if SELinux can't be a ally
for that issue in fact: dedicated context, separation, that's a SELinux
kind of thing isn't it?
I'm no SELinux poweruser¹, but that kind of usage is, to my small
knowledge of this product, a perfect fit.

Would be good to dig in that direction, don't you think?



###
¹ I'm more the poor guy at the end head-banging his desk when SELinux
comes in the way ;). That hurts.

> 
> @Juan do you agree with that statement? As we had some quick chat about it.
> 
> Note: I'm not part of the security squad ;). But I like secured things.
> 
>>
>>     > 
>>     > 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
>>     <https://etherpad.openstack.org/p/tripleo-heat-admin-security>
>>     > [1]
>>     https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f
>>     <https://gist.github.com/lukehinds/4cdb1bf4de526a049c51f05698b8b04f>
>>     >
>>     > --
>>     > Luke Hinds
>>
>>     -- 
>>     Cédric Jeanneret
>>     Software Engineer
>>     DFG:DF
>>
>>
>>     __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> -- 
>> Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat
>> e: lhinds at redhat.com <mailto:lhinds at redhat.com> | irc: lhinds @freenode
>> |t: +44 12 52 36 2483
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 

-- 
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/db8b6208/attachment.sig>