[libvirt] IPv6 in Libvirt LXC

[Daniel P. Berrange]

On Mon, Jun 02, 2014 at 03:09:08PM +0000, Thomas Maddox wrote:
> Hey all,
> 
> According to a discussion last week in the Nova-Libvirt subgroup meeting,
> it was advised, by danpb, that I bring this issue up on the Libvirt mailing
> list for discussion and resolution. So, here goes -
> 
> I'm currently using config drive from Nova to generate network configurations
> for LXC guests that are spun up via Libvirt. Unfortunately, when doing some
> IPv6 testing, I ran into a snag (with a couple work arounds detailed below).
> Due to the read-only mount of /proc/sys (http://libvirt.org/drvlxc.html#fsmounts),
> I am unable to get expected behavior from IPv6 static network configurations.
> I did some poking around and found this bug from a couple years ago that pretty
> well outlines the problem:
>
> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/964882.
> 
> I wasn't sure how we might go about correcting this, but it seems like something
> we'll need to address in Libvirt. Maybe with the user namespaces working, we can
> begin to provide some read/write mounts instead of read-only with clear
> documentation on the security implications? =] When using static IPv6 addressing
> it was attempting the following command: 'sysctl -q -e -w net.ipv6.conf.eth0.autoconf=0'.
> I tested to see whether the host and the guest share this value. I was able to
> change it in the host without it being reflected in the guest.

That sounds promising. I guess we need to check whether that isolation applies
to every tunable underneath net.* or just the tunables that are tied to specific
network interfaces. eg net.*.eth0.*  Hopefully it would be the former, but I'm
afraid it could well be the latter....

> The work arounds I've tried that seemed to allow IPv6 to get configured properly:
> 
> 1. Use the post-up hook on an IPv4 static configuration to configure IPv6 via
>    ifconfig/routes (example: http://paste.openstack.org/show/82446/).
> 2. Patch Libvirt to include a /proc/sys/net mount as read/write.

This would be reasonable todo, assuming the entire subtree of
/proc/sys/net was actually isolated from the host by the network
namespace.

The remounting of /proc/sys readonly is a psuedo-security measure. In the
absence of user namespaces it does not actually protect against a malicious
user with root in the container, since they can just re-mount it read-write
again. So when user namespaces are *not* active, we could easily just make
/proc/sys/net (or even the entire of /proc/sys) read-write, without lowering
the real security protection.

When user namesplaces *are* active, the remapping of UID/GID==0  to a
non-0 value will prevent the root user in the container from changing
anything in /proc/sys even if we have it entirely read-write. So merely
changing /proc/sys/net to read-write won't fix your problem when user
namespaces are active.

IIUC, we'd need to recursively chown the files under /proc/sys/net to
give them the remapped UID/GID of the root user in the container, in
order that they can be used.

So overall I think we'd have to do

 - Make either /proc/sys/net or /proc/sys read-write

 - If userns is active, recursive chown /proc/sys/net (or a subset of
   files in it that we explicitly want to grant access to)

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|