[openstack-dev] [neutron][security][rootwrap] Proposal to replace rootwrap/sudo with privsep helper process (for neutron, but others too)

Miguel Ángel Ajo majopela at redhat.com
Fri Feb 13 11:33:56 UTC 2015


We have an ongoing effort in neutron to move to rootwrap-daemon.  

https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/rootwrap-daemon-mode,n,z

To speed up multiple system calls, and be able to spawn daemons inside namespaces.

I have to read a bit what are the good & bad points of privsep.   

The advantage of rootwrap-daemon, is that we don’t need to change all our networking libraries across neutron,
and we kill the sudo/rootwrap spawn for every call, yet keeping the rootwrap permission granularity.

Miguel Ángel Ajo


On Friday, 13 de February de 2015 at 10:54, Angus Lees wrote:

> On Fri Feb 13 2015 at 5:45:36 PM Eric Windisch <eric at windisch.us (mailto:eric at windisch.us)> wrote:
> > ᐧ
> > >  
> > >     from neutron.agent.privileged.commands import ip_lib as priv_ip
> > >     def foo():
> > >         # Need to create a new veth interface pair - that usually requires root/NET_ADMIN
> > >         priv_ip.CreateLink('veth', 'veth0', peer='veth1')
> > >  
> > > 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).
> >  
> > 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.
> >  
> > 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.
>  
> 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.
>  
> 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.
>  
>  - Gus  
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150213/6126c570/attachment.html>


More information about the OpenStack-dev mailing list