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

2015-02-15 Thread Angus Lees
On Sat Feb 14 2015 at 1:14:09 AM Thierry Carrez wrote: > Angus Lees wrote: > > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and > > wrote a proof-of-concept privsep daemon for > > neutron: https://review.openstack.org/#/c/155631 > > Nice work! Trying to check where the sec

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

2015-02-15 Thread Angus Lees
On Fri Feb 13 2015 at 10:35:49 PM Miguel Ángel Ajo wrote: > 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 > > Thanks for replying. I should have mention

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

2015-02-13 Thread Thierry Carrez
Angus Lees wrote: > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and > wrote a proof-of-concept privsep daemon for > neutron: https://review.openstack.org/#/c/155631 Nice work! Trying to check where the security model is actually weaker than the one provided by rootwrap her

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

2015-02-13 Thread Miguel Ángel Ajo
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

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

2015-02-13 Thread Angus Lees
On Fri Feb 13 2015 at 5:45:36 PM Eric Windisch 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', pe

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

2015-02-12 Thread Eric Windisch
ᐧ > > 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

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

2015-02-12 Thread Angus Lees
On Fri Feb 13 2015 at 4:05:33 PM Robert Collins wrote: > > On 13 Feb 2015 17:42, "Angus Lees" wrote: > > > > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and > wrote a proof-of-concept privsep daemon for neutron: > https://review.openstack.org/#/c/155631 > > There's nothi

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

2015-02-12 Thread Robert Collins
On 13 Feb 2015 17:42, "Angus Lees" wrote: > > So inspired by the "Rootwrap on root-intensive nodes" thread, I went and wrote a proof-of-concept privsep daemon for neutron: https://review.openstack.org/#/c/155631 > There's nothing neutron-specific in the core mechanism and it could easily be moved

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

2015-02-12 Thread Angus Lees
So inspired by the "Rootwrap on root-intensive nodes" thread, I went and wrote a proof-of-concept privsep daemon for neutron: https://review.openstack.org/#/c/155631 There's nothing neutron-specific in the core mechanism and it could easily be moved out into a common (oslo) library and reused acros