[openstack-dev] Python overhead for rootwrap

Robert Collins robertc at robertcollins.net
Fri Jul 26 01:44:51 UTC 2013

On 26 July 2013 09:43, Thierry Carrez <thierry at openstack.org> wrote:
> Russell Bryant wrote:
>> On 07/25/2013 04:40 PM, Mike Wilson wrote:
>>> In my opinion:
>>> 1. Stop using rootwrap completely and get strong argument checking
>>> support into sudo (regex).
>>> 2. Some sort of long lived rootwrap process, either forked by the
>>> service that want's to shell out or a general purpose rootwrapd type thing.
>>> I prefer #1 because it's surprising that sudo doesn't do this type of
>>> thing already. It _must_ be something that everyone wants. But #2 may be
>>> quicker and easier to implement, my $.02.
>> We could do #1 and keep rootwrap around as the fallback if the local
>> version of sudo doesn't support what we need.
> It's not just regexp support, rootwrap basically lets you extend the
> rules to be openstack-specific (custom filters). That feature is not
> widely used yet but is the key to fine-grained privilege escalation in
> the future. Also getting something new into sudo is (for good reasons)
> quite difficult.
> I would rather support solution 3: create a single, separate  executable
> that does those 20 things that need to be done (can be a shell script
> with some logic in it), and have rootwrap call that *once*. That way you
> increase speed by 20 times without dumping the security model.

I think userspace is the wrong place to do many of those things : race
conditions around anything that checks system state before executing
are going to be super common.

I like having a clear 'now we are doing escalated privileges' model,
but have yet to see evidence that doing anything other than sudo for
statically defined roles and selinux/apparmor for dynamic
considerations will actually be secure.

E.g. I think rootwrap is broken by design. [slightly strong position,
but one that is defensible :)]


Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services

More information about the OpenStack-dev mailing list