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