Re: [openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?
Angus Lees wrote: > How crazy would it be to just give neutron CAP_NET_ADMIN (where > required), and allow it to make network changes via ip (netlink) calls > directly? I don't think that's completely crazy. Given what neutron is expected to do, and what it is already empowered to do (through lazy and less lazy rootwrap filters), relying on CAP_NET_ADMIN instead should have limited security impact. It would be worth precisely analyzing the delta (what will a capability-enhanced neutron be able to do to the system that the rootwrap-powered neutron can't already do), and try to get performance numbers... That would help making the right choice, although I expect the best gains here are in avoiding the whole external executable call and result parsing. You could even maintain parallel code paths (use capability if present). Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?
Afaik ovs-vsctl just talks to ovsdb-server via some regular IPC mechanism - usually a unix socket, see --db. So yes, provided the file permissions on the unix socket work out, then no root powers (or any kernel capability) is necessary. Having said that, there will be plenty of examples where sudo/rootwrap is still required. I'm not suggesting we can (or should!) get rid of it entirely - just for basic network configuration. On Wed Dec 10 2014 at 12:42:46 PM George Shuklin wrote: > Is ovs-vsctl gonna be happy with CAP_NET_ADMIN? > > On 12/10/2014 02:43 AM, Angus Lees wrote: > > [I tried to find any previous discussion of this and failed - I'd > appreciate a pointer to any email threads / specs where this has already > been discussed.] > > Currently neutron is given the ability to do just about anything to > networking via rootwrap, sudo, and the IpFilter check (allow anything > except 'netns exec'). This is completely in line with the role a typical > neutron agent is expected to play on the local system. > > There are also recurring discussions/issues around the overhead of > rootwrap, costs of sudo calls, etc - and projects such as rootwrap daemon > underway to improve this. > > How crazy would it be to just give neutron CAP_NET_ADMIN (where > required), and allow it to make network changes via ip (netlink) calls > directly? > We will still need rootwrap/sudo for other cases, but this should remove a > lot of the separate process overhead for common operations, make us > independent of iproute cli versions, and allow us to use a direct > programmatic API (rtnetlink and other syscalls) rather than generating > command lines and regex parsing output everywhere. > > For what it's worth, CAP_NET_ADMIN is not sufficient to allow 'netns > exec' (requires CAP_SYS_ADMIN), so it preserves the IpFilter semantics. On > the downside, many of the frequent rootwrap calls _do_ involve > creating/modifying network namespaces so we wouldn't see advantages for > these cases. I need to experiment further before having a proposal for > that part (just granting CAP_SYS_ADMIN too is too broad; user namespaces > help a lot, but they're very new and scary so not available everywhere). > > Thoughts? > > > ___ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?
Is ovs-vsctl gonna be happy with CAP_NET_ADMIN? On 12/10/2014 02:43 AM, Angus Lees wrote: [I tried to find any previous discussion of this and failed - I'd appreciate a pointer to any email threads / specs where this has already been discussed.] Currently neutron is given the ability to do just about anything to networking via rootwrap, sudo, and the IpFilter check (allow anything except 'netns exec'). This is completely in line with the role a typical neutron agent is expected to play on the local system. There are also recurring discussions/issues around the overhead of rootwrap, costs of sudo calls, etc - and projects such as rootwrap daemon underway to improve this. How crazy would it be to just give neutron CAP_NET_ADMIN (where required), and allow it to make network changes via ip (netlink) calls directly? We will still need rootwrap/sudo for other cases, but this should remove a lot of the separate process overhead for common operations, make us independent of iproute cli versions, and allow us to use a direct programmatic API (rtnetlink and other syscalls) rather than generating command lines and regex parsing output everywhere. For what it's worth, CAP_NET_ADMIN is not sufficient to allow 'netns exec' (requires CAP_SYS_ADMIN), so it preserves the IpFilter semantics. On the downside, many of the frequent rootwrap calls _do_ involve creating/modifying network namespaces so we wouldn't see advantages for these cases. I need to experiment further before having a proposal for that part (just granting CAP_SYS_ADMIN too is too broad; user namespaces help a lot, but they're very new and scary so not available everywhere). Thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Linux capabilities vs sudo/rootwrap?
[I tried to find any previous discussion of this and failed - I'd appreciate a pointer to any email threads / specs where this has already been discussed.] Currently neutron is given the ability to do just about anything to networking via rootwrap, sudo, and the IpFilter check (allow anything except 'netns exec'). This is completely in line with the role a typical neutron agent is expected to play on the local system. There are also recurring discussions/issues around the overhead of rootwrap, costs of sudo calls, etc - and projects such as rootwrap daemon underway to improve this. How crazy would it be to just give neutron CAP_NET_ADMIN (where required), and allow it to make network changes via ip (netlink) calls directly? We will still need rootwrap/sudo for other cases, but this should remove a lot of the separate process overhead for common operations, make us independent of iproute cli versions, and allow us to use a direct programmatic API (rtnetlink and other syscalls) rather than generating command lines and regex parsing output everywhere. For what it's worth, CAP_NET_ADMIN is not sufficient to allow 'netns exec' (requires CAP_SYS_ADMIN), so it preserves the IpFilter semantics. On the downside, many of the frequent rootwrap calls _do_ involve creating/modifying network namespaces so we wouldn't see advantages for these cases. I need to experiment further before having a proposal for that part (just granting CAP_SYS_ADMIN too is too broad; user namespaces help a lot, but they're very new and scary so not available everywhere). Thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
