Hi Evgeni, First of all, thank you for posting the detailed steps you used to reproduce a working config, which is by far the best explanation on how to set up LXC for running Debian 8 on top of Debian 8 I have seen yet.
To answer your questions, yes I've been using Jessie's libvirt package "as is". No idea why it doesn't work. However, by following your explanation, I was able to reproduce a working config, using user-mode networking and lxcbr0, on i386, with only minor adaptations and on ppc64, with one big difference: cgmanager has to be used there (see https://linuxcontainers.org/cgmanager/getting-started/) for LXC to run in unprivileged mode, with or without networking, be it using br0 or lxcbr0. Hence, this, in combination with your explanation, makes it work on both architectures I could test. About br0 v.s. lxcbr0: the main difference between them is the fact that the latter involves running dnsmasq in the background (and therefore has firewall implications, namely an iptables rule is added) to provide ip masquerading (that is, NAT) to the containers. Note: containerops.org/2013/11/19/lxc-networking provides in-depth coverage of the subject + also covers linux network namespaces in general. Regarding how to setup our setups: I think that the Debian wiki on LXC, https://wiki.debian.org/LXC, should be updated with your simplified method - save for the vagrant part of it - and eventually, my architecture-specific notes as well, as I remember reading in a 2.0.7-1-related post that powerpc compatibility was seen as an issue. As for your last comment, I agree that bridges, be it br0 or lxcbr0, have to be created by root; I was referring to using them as an unprivileged user. Last but not least, the security bug I had spotted was most likely equivalent to CVE-2017-5985, as I could not reproduce it now that it works again using a lxcbr0 bridge as well (setting the default route in an unprivileged container using user-mode networking does not affect the host anymore), when running lxc 2.0.7-2 from jessie-backports (which includes the fixes for the aforementioned CVE). I will post an update on oss-security with the security-relevant part of this thread. Stiepan Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [pkg-lxc-devel] Bug#857295: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership) Local Time: 26 March 2017 12:17 PM UTC Time: 26 March 2017 10:17 From: evg...@debian.org To: Stiepan <stie@itk.swiss>, 857...@bugs.debian.org Hi Stiepan, On Fri, Mar 24, 2017 at 10:51:24AM -0400, Stiepan wrote: > Using a bridge set up with libvirt (as in > http://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29) > doesn't work. Is that what the libvirt package does on Debian out-of-the-box? If so it works just fine for me on my laptop where I put the containers on the vibr0 created by libvirt. > Neither does using a bridge set up as indicated in > https://wiki.debian.org/LXC/SimpleBridge#Using_lxc-net (causes the same > errors as with libvirt). So I just fired a fresh jessie+backports Vagrant box and it worked fine (incl network in the container): $ vagrant init debian/jessie64 $ vagrant up $ vagrant ssh vagrant@jessie:~$ sudo nano /etc/apt/sources.list deb http://httpredir.debian.org/debian jessie-backports main vagrant@jessie:~$ sudo apt update vagrant@jessie:~$ sudo apt install lxc/jessie-backports lxcfs vagrant@jessie:~$ sudo nano /etc/default/lxc-net USE_LXC_BRIDGE="true" vagrant@jessie:~$ systemctl enable lxc-net vagrant@jessie:~$ systemctl restart lxc-net vagrant@jessie:~$ ip a s dev lxcbr0 3: lxcbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 scope global lxcbr0 valid_lft forever preferred_lft forever vagrant@jessie:~$ sudo sysctl -w kernel.unprivileged_userns_clone=1 vagrant@jessie:~$ exit # needed to trigger lxcfs' PAM module $vagrant ssh vagrant@jessie:~$ cat /proc/self/cgroup 8:perf_event:/ 7:blkio:/ 6:net_cls,net_prio:/ 5:freezer:/user/vagrant/0 4:devices:/ 3:cpu,cpuacct:/ 2:cpuset:/ 1:name=systemd:/user/vagrant/0 vagrant@jessie:~$ mkdir ~/.config/lxc/ -p vagrant@jessie:~$ nano ~/.config/lxc/default.conf xc.include = /etc/lxc/default.conf lxc.id_map = u 0 624288 65536 lxc.id_map = g 0 624288 65536 vagrant@jessie:~$ sudo nano /etc/lxc/lxc-usernet vagrant veth lxcbr0 10 vagrant@jessie:~$ lxc-create -n jessie -t download -- -d debian -r jessie -a amd64 vagrant@jessie:~$ nano .local/share/lxc/jessie/config lxc.network.type=veth lxc.network.flags=up lxc.network.link=lxcbr0 vagrant@jessie:~$ lxc-start -n jessie vagrant@jessie:~$ lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 jessie RUNNING 0 - - - > Using a classical / "plain old" / you-name-it bridge, set up as in > http://wiki.libvirt.org/page/Networking#Altering_the_interface_config, does > work. I don't see any technical difference between the plain br0 setup with this link and the ones created by lxc-net or libvirt. Can you point them out please? > By the way, the lxc_delete_network:3028... additional error I was seeing pops > up only when /etc/lxc/lxc-usernet is still set to use br0, whilst the LXC > container is > set to use virbr0 and hence can be ignored, sorry about that. When properly > configured (i.e. when both are configured to use virbr0, or lxcbr0), > container startup > simply fails with a "Failed to create the configured network" error, but > still fails, whereas when using classical br0, it works. Can you please provide the steps how to setup your setup from a plain jessie or stretch image? > So, if your bridge is set up as suggested in > https://wiki.debian.org/BridgeNetworkConnections' Manual bridge setup > section, using either brctl or > /etc/network/interfaces (for a persistent config), we have the same > configuration and it works, which is fine. Still, I thought that LXC enabled > using lxcbr0 bridges > in user mode, as lxc-user-nic's man page suggests is possible. Can you > confirm whether this is the case with the current version? lxc-user-nic is to attach a user-namespace-nic to an existing bridge, you can't create a bridge with it.
