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 <thie...@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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp