openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Andrew Bogott wrote:
>     As part of the plugin framework, I'm thinking about facilities for
> adding commands to the nova-rootwrap list without directly editing the
> code in nova-rootwrap.  This is, naturally, super dangerous; I'm worried
> that I'm going to open a security hole big enough to pass a herd of
> elephants.

It is dangerous :) I plan to work on that, with options being audited in
the open like I did for the original implementation. So far I stayed
away from using a configuration file (or .d directory) for
nova-rootwrap, so that only the module loading path had to be secured
(it has to anyway).

>     It doesn't help that I mostly know about devstack, and don't know a
> whole lot about the variety of ways that Nova is installed on actual
> production systems.  So, my questions:
> 
> a)  Is the nova code on a production system generally owned by root and
> read-only?  (If the answer to this one is ever 'no' then we're done,
> because we're already 100% insecure.)

yes

> b)  Does nova usually run as root user?  (Again, thinking 'no' because
> otherwise we wouldn't need a rootwrap tool in the first place.)

no

> c)  Who generally has rights to modify nova.conf and/or add command-line
> args to the nova launch?  (I want the answer to this to be 'just root'
> but I fear the answer is 'both root and the nova user.')

depends on the distribution, though I suspect most of them would make
nova.conf root-only.

The security model of the current system is completely external to
nova.conf: the sudoers file allows to the nova user to run
/usr/bin/nova-rootwrap as root with a cleaned-up PATH, which does Python
module loading from safe directories. No config file is loaded. So the
sudoers file is the key to securing the model.

> The crux: If additional commands can be added to rootwrap via nova.conf
> or the commandline, does that open security holes that aren't already
> open?  Such a facility will give root to anyone who can modify the
> nova.conf or the nova commandline.  So, if the nova user can modify the
> commandline, the question is:  did the nova user /already/ have root
> access?

One option is to use a separate /etc/nova/nova-rootwrap.conf that would
be root-writeable (or more likely a /etc/nova/rootwrap.d directory). But
then we probably have to hardcode the config file location.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack