<div>
<span style="font-size: 12px;">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.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">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.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">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.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">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.</span></div><div><span style="font-size: 12px;"><br></span></div><div>-- <br>Eric Windisch<div><br></div></div>
<p style="color: #A0A0A8;">On Sunday, April 29, 2012 at 7:41 PM, Andrew Bogott wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div> As part of the plugin framework, I'm thinking about facilities for </div><div>adding commands to the nova-rootwrap list without directly editing the </div><div>code in nova-rootwrap. This is, naturally, super dangerous; I'm worried </div><div>that I'm going to open a security hole big enough to pass a herd of </div><div>elephants.</div><div><br></div><div> It doesn't help that I mostly know about devstack, and don't know a </div><div>whole lot about the variety of ways that Nova is installed on actual </div><div>production systems. So, my questions:</div><div><br></div><div>a) Is the nova code on a production system generally owned by root and </div><div>read-only? (If the answer to this one is ever 'no' then we're done, </div><div>because we're already 100% insecure.)</div><div><br></div><div>b) Does nova usually run as root user? (Again, thinking 'no' because </div><div>otherwise we wouldn't need a rootwrap tool in the first place.)</div><div><br></div><div>c) Who generally has rights to modify nova.conf and/or add command-line </div><div>args to the nova launch? (I want the answer to this to be 'just root' </div><div>but I fear the answer is 'both root and the nova user.')</div><div><br></div><div>The crux: If additional commands can be added to rootwrap via nova.conf </div><div>or the commandline, does that open security holes that aren't already </div><div>open? Such a facility will give root to anyone who can modify the </div><div>nova.conf or the nova commandline. So, if the nova user can modify the </div><div>commandline, the question is: did the nova user /already/ have root access?</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>Mailing list: <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a></div><div>Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a></div><div>Unsubscribe : <a href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a></div><div>More help : <a href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>