openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Kun Huang wrote:
> In this wiki, http://wiki.openstack.org/Nova/Rootwrap, the part of
> "security model" results in "This chain ensures that the nova user
> itself is not in control of the configuration or modules used by the
> nova-rootwrap executable". I understand that chain but I`m confused with
> this conclusion.
> 
> That chain means that a nova-rootwrap executable runs safely under
> root-control. In another word, the program nova-rootwrap runs is
> protected by root, and it cannot be influenced by other users. But that
> conclusion implies that the insecurity model is /nova/ user is in
> control by someone. This is what I'm confused with.

The goal of the rootwrap (used by Nova, but also Cinder and Quantum) is
to allow openstack services to run some commands as root, while running
the remaining of the code as an unprivileged user. This limits the
amount of damage that a security hole in openstack may inflict on the
system.

Imagine a security hole in Nova that enabled an attacker to execute
arbitrary code. That code would be executed as the nova user, which
limits the amount of damage on the rest of the system. The trick is to
allow the nova user to run /some/ code as root, without letting it
execute /anything/ as root.

Rootwrap is just a mechanism to provide limited privilege escalation.
The rootwrap chain mentioned in the wiki ensures that only the root user
controls what the nova user can execute as root.  If you let the nova
user itself in control of what the nova user can execute as root, you
end up with around the same security as if you were running as the root
user directly.

Now, the privilege escalation limitation is only as good as the
precision of the rootwrap filters you use. It's pretty good for nova-api
nodes, which are basically not allowing anything to be run as root. It's
not nearly as good on nova-compute nodes, where we still use pretty
liberal filters that could use some work. We could also get rid of the
code that requires most of the run-as-root stuff, in particular the
pre-boot file injection mechanisms (evil! use boot-time customization
instead!).

Hope this clarifies,

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack