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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list