<div dir="ltr"><div class="gmail_quote">On Fri Feb 13 2015 at 10:35:49 PM Miguel Ángel Ajo <<a href="mailto:majopela@redhat.com">majopela@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<span style="font-size:14px">We have an ongoing effort in neutron to move to rootwrap-daemon.</span>
</div><div><br></div><div><a href="https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/rootwrap-daemon-mode,n,z" target="_blank">https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/rootwrap-daemon-mode,n,z</a></div><div><br></div></blockquote><div>Thanks for replying. I should have mentioned rootwrap-daemon in my original post:</div><div><br></div><div>The main difference between this privsep proposal and rootwrap (in daemon-mode or rootwrap "classic") is that rootwrap is oriented around command lines, and privsep is oriented around python function calls.</div><div><br></div><div>Using functions rather than command lines means we can move to using native libraries more easily (as I've done here with pyroute2), which allows a more closely integrated, performant and safer interface. It also means we can describe more customised behaviour in the exposed function API, leading to fewer cross-process calls and less scope for exposing unintended behaviour.</div><div><br></div><div>To pick one example, starting up a long-running daemon (assuming we wanted to do this) from the privsep process "just works" without any need to work around the privsep mechanism.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div><span style="font-size:14px">To speed up multiple system calls, and be able to spawn daemons inside namespaces.</span></div></blockquote><div><br></div><div>Yep, rootwrap-daemon certainly removes the python rootwrap startup time; privsep *also* removes the subprocess exec startup time for cases where we have moved to native libraries (again, see the pyroute2 example).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="font-size:14px">I have to read a bit what are the good & bad points of privsep. </span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">The advantage of rootwrap-daemon, is that we don’t need to change all our networking libraries across neutron,</span></div><div><span style="font-size:14px">and we kill the sudo/rootwrap spawn for every call, yet keeping the rootwrap permission granularity.</span></div></blockquote><div><br></div><div>The good news is that privsep and rootwrap (in either mode) can coexist just fine. A staged migration to privsep might involve spawning the privsep daemon via sudo on the first call to something that needs it. This approach means we wouldn't require adding the privsep_daemon.start() call early in any relevant main() - and the only downside is that we retain a (single) dependency on sudo/sudoers.</div><div><br></div><div> - Gus</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><span style="font-size:10pt">Miguel Ángel Ajo</span></div><div><br></div></div>
<p style="color:#a0a0a8">On Friday, 13 de February de 2015 at 10:54, Angus Lees wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div dir="ltr"><div>On Fri Feb 13 2015 at 5:45:36 PM Eric Windisch <<a href="mailto:eric@windisch.us" target="_blank">eric@windisch.us</a>> wrote:<br><blockquote type="cite"><div><div dir="ltr"><div hspace="streak-pt-mark" style="max-height:1px"><img style="width:0px;max-height:0px" src="https://mailfoogae.appspot.com/t?sender=aZXJpY0B3aW5kaXNjaC51cw%3D%3D&type=zerocontent&guid=1f5b166c-c37d-4b6d-9154-2391bb2f16ee"><font color="#ffffff" size="1">ᐧ</font></div></div><div dir="ltr"><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"> </span>from neutron.agent.privileged.commands import ip_lib as priv_ip</div><div><span style="line-height:1.5"> def foo():</span></div><div><span style="line-height:1.5"> # Need to create a new veth interface pair - that usually requires root/NET_ADMIN</span></div><div><span style="line-height:1.5"> priv_ip.CreateLink('veth', 'veth0', peer='veth1')</span></div><div><br></div><div>Because we now have elevated privileges directly (on the privileged daemon side) without having to shell out through sudo, we can do all sorts of nicer things like just using netlink directly to configure networking. This avoids the overhead of executing subcommands, the ugliness (and danger) of generating command lines and regex parsing output, and make us less reliant on specific versions of command line tools (since the kernel API should be very stable).</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div><div><div>One of the advantages of spawning a new process is being able to use flags to clone(2) and to set capabilities. This basically means to create containers, by some definition. Anything you have in a "privileged daemon" or privileged process ideally should reduce its privilege set for any operation it performs. That might mean it clones itself and executes Python, or it may execvp an executable, but either way, the new process would have less-than-full-privilege.</div><div><br></div><div>For instance, writing a file might require root access, but does not need the ability to load kernel modules. Changing network interfaces does not need access to the filesystem, no more than changes to the filesystem needs access to the network. The capabilities and namespaces mechanisms resolve these security conundrums and simplify principle of least privilege.</div></div></div></div></div></blockquote><div><br></div><div>Agreed wholeheartedly, and I'd appreciate your thoughts on how I'm using capabilities in this change. The privsep daemon limits itself to a particular set of capabilities (and drops root). The assumption is that most OpenStack services commonly need the same small set of capabilities to perform their duties (neutron -> net_admin+sys_admin for example), so it makes sense to reuse the same privileged process.</div><div><br></div><div>If we have a single service that somehow needs to frequently use a broad swathe of capabilities then we might want to break it up further somehow between the different internal aspects (multiple privsep helpers?) - but is there such a case? There's also no problems with mixing privsep for frequent operations with the existing sudo/rootwrap approach for rare/awkward cases.</div><div><br></div><div> - Gus</div></div></div>
</div></div></span></blockquote><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div>__________________________________________________________________________</div><div>OpenStack Development Mailing List (not for usage questions)</div><div>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span></blockquote>
<div>
<br>
</div>
______________________________<u></u>______________________________<u></u>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<u></u>openstack.org?subject:<u></u>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div></div>