openstack team mailing list archive

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

On Fri, Jan 11, 2013 at 11:32:08AM +0100, Thierry Carrez wrote:
> 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!).

FWIW, if you've got libguestfs available, the file injection code does
not require any rootwrap usage. Ironically the config drive stuff now
does require root if you configure it to use FAT instead of ISO9660 :-(

I have a general desire to make it such that you can run with KVM and
Nova without requiring rootwrap for anything. last time I looked the
three general areas where we required root wrap were networking, storage
and file injection. My recent refactoring of file injection addressed
the latter by using libguestfs APIs instead of libguestfs FUSE. Networking
is mostly solved if using newest libvirt + Quantum instead of Nova's
own networking. Storage is something that cna be addressed by using
libvirt's storage APIs instead of running commands directly.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|