Open Stack

Joe Gordon wrote:
> Going forward I think we should support two approaches:
> 
> 1) some faster mostly python based (because we are a python project)
> rootwrap solution, there are many good ideas proposed above.   Although 
> Robert Collins comments have yet to be addressed.

About Robert's arguments: most filters operate on command arguments
without checking state, so they don't introduce a TOCTOU race. Some
advanced filters indeed use current state of the system in their checks
so they introduce a TOCTOU race but those are not thought to be
exploitable. For example KillFilter checks the PID target before it
kills it, but since you don't control PID allocation you can't exploit
that race to gain anything.

> 2) Also support just using sudo.
> Assuming any sort of rootwrap solution we propose will incur a non-zero
> overhead, I can imagine some users wanting to sacrifice some security
> for performance.   For example if they run a private cloud where the
> tenants are mostly trusted.

Now that's interesting, because we actually don't support running "sudo"
as the root wrapper anymore (since Folsom/Grizzly). We removed the
"root_helper" parameter (in Nova and Cinder) and use "rootwrap_config"
instead.

You can still bypass rootwrap completely by running the component as the
root user instead of the unprivileged (nova) user, but that's about it.
Is that really a use case we want to support ?

Note that if we add the ability to run python snippets of code in
rootwrap, we'll definitely lose the ability to run outside rootwrap. So
there seems to be a trade-off here:

I thought we could move functions like
linux_net.initialize_gateway_device to a Python snippet library that
rootwrap would run in one go (using some artificial construct like
"nova-rootwrap /etc/nova/rootwrap.conf py initialize_gateway_device
parameters...") but then we'd lose the ability to run as the root user
and to bypass rootwrap completely (since sudo py
initialize_gateway_device wouldn't do you any good)... or maybe we can
come up with a construct that would still work when called using basic
sudo ?

-- 
Thierry Carrez (ttx)