openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #12815
Re: Question on nova disk injection...
Eric Windisch wrote:
> On Tuesday, June 5, 2012 at 19:18 PM, Joshua Harlow wrote:
>
>> Why couldn’t nova just escalate pythons privileges to the super user
>> when writing a file (thus allowing it to use python file writing
>> functions and such).
>
> Because we use Eventlet. os.setuid applies to the entire
> process. Coroutine switching during this would be dangerous.
Indeed.
> Three options seem to exist:
> [...]
>
> 2. One less elegant, but easy, solution might just be to extend the
> rootwrap functionality. Have it support calling commands on the system
> *and* executing trusted Python methods with trusted arguments. We'd
> still be shelling out to rootwrap, but rootwrap could internally provide
> 'mkdir' and 'chmod' style commands around the os stdlib, rather than
> shelling out a second time, as it does currently.
This is the path I'm following in Folsom, as part of
https://blueprints.launchpad.net/nova/+spec/folsom-nova-rootwrap.
My original plan was to let a CommandFilter overload its "execute"
method (which usually would just call subprocess.Popen) to execute
Python code instead of the corresponding shell call.
This adds a bit of confusion (from the code it looks like you're just
running a shell command in utils.execute, whereas nova-rootwrap decides,
in that specific case, to run some python code instead). The benefit is
that it keeps backward compatibility with usage of "sudo" instead of
"sudo nova-rootwrap" as the root wrapper (if you just use "sudo" it
would still work, by calling the real command instead of the python code).
Alternatively, we could stop supporting "sudo" as a root_wrapper in Nova
and add support for calling Python functions in utils.execute and
nova-rootwrap (with filters that would filter function parameters).
What implementation suboption would have your preference ? Is
nova-rootwrap now universally used ? Should we prefer compatibility or
absence of confusion ?
> 3. rootwrap itself could actually be implemented as a Nova service, if
> we could trust the RPC mechanism direct access to the rootwrap methods
> -- which we is not all too safe, currently. This would effectively be a
> mix of options 1/2.
This is the most elegant, but also the trickiest to secure option.
Attack surface on option #2 is more limited, uses a well-known
escalation mechanism (sudoers), so it's a lot easier to audit.
Regards,
--
Thierry Carrez (ttx)
Release Manager, OpenStack
Follow ups
References