These are all installation-specific. Devstack is the closest thing there is to an official installer and that clearly doesn't do all the right things, from the perspective of making it *easy* to work with and test, rather than making it production-ready. I think most of the integrators are doing the right thing, or at least trying/intending to.
The typical deployment is a 'nova' user running nova with a sudoers configuration allowing the execution of rootwrap. Because the Nova user executes the nova commands, the nova user is able to re-execute its commands with different arguments. The nova.conf is a different story, but largely irrelevant. The only ways to "extend" rootwrap right now are to use sudoers-only (foregoing some of the checks it does), wrap rootwrap itself, or some entirely different setuid wrapper. I'd really like to see this security mechanism overhauled. Rootwrap was an improvement over what was there before, however, I don't believe that rootwrap is a viable long-term solution as currently designed. Rootwrap has resulted in the use of potentially insecure shell-outs for the purposes of privilege escalation in cases where pure Python would be safer. -- Eric Windisch On Sunday, April 29, 2012 at 7:41 PM, 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 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.) > > b) Does nova usually run as root user? (Again, thinking 'no' because > otherwise we wouldn't need a rootwrap tool in the first place.) > > 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.') > > 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? > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] (mailto:[email protected]) > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
