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
