10:09 a.m.
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.
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.
Cheers!
-Thomas
11:22 a.m.
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 :|
8:57 a.m.
On Mon, Jun 2, 2014 at 6:22 PM, Daniel P. Berrange <berrange(a)redhat.com> wrote:
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)
Please just make /proc/ and /sys writeable (or at least the setting
optional for paranoid folks).
If the userns was setup correctly by libvirt and a container user/root still
can do bad things this a plain kernel bug and needs fixing.
No need to paper over it in libvirt.
--
Thanks,
//richard
3818
days inactive
3826
days old
2 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Richard Weinberger -
Thomas Maddox