Open Stack

We can do "#includedir /etc/nova/sudoers.d" from sudoers as well.
I think, a solution with a separate conf/dir for rootwrap is a step
back to sudo.

Kind regards, Yuriy.


On Wed, May 2, 2012 at 1:54 PM, Thierry Carrez <thierry at openstack.org> wrote:
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp