Open Stack

On Fri Feb 13 2015 at 10:35:49 PM Miguel Ángel Ajo <majopela at redhat.com>
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 mentioned rootwrap-daemon in my
original post:

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.

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.

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.

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

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).

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.
>

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.

 - Gus

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> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>  ____________________________________________________________
> ______________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 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/20150216/04976b01/attachment.html>