Comment 0 for bug 1654676

The documentation for lxc-user-nic claims:

      It ensures that the calling
      user is privileged over the network namespace to which the interface
      will be attached.

Actually, the code only verifies that a process of the calling user is running in the network namespace to which the interface will be attached. To verify this:

 - As root, create a new bridge "lxcbr0".
 - As root, add an entry like "user veth lxcbr0 10" to /etc/lxc/lxc-usernet.
 - As the user specified in /etc/lxc/lxc-usernet, run the following command:
       /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic foo bar $$ veth lxcbr0 foobar
 - Run "ip link show foobar". The output shows that a network interface with the
   name "foobar" was created in the init namespace (in which the user is not
   privileged).

I suspect that it would also be possible to trick lxc-user-nic into operating on namespaces the caller can't access by reassigning the PID while lxc-user-nic is running, between the access check and the netlink calls - this is probably quite hard to fix, considering that the netlink interface just uses a PID to identify the target namespace.

I haven't found any way to actually exploit this; however, it seems interesting that this can e.g. be used to create network interfaces whose names contain special characters like dollar, semicolon and backtick. I'm not sure how dangerous that is - I'm reporting it as a security bug for now, but if you feel that this has no security impact, feel free to derestrict it.

One way to fix this might be to temporarily drop privileges (setresuid(ruid, ruid, 0)) in rename_in_ns() after the first setns() call. This way, the renaming could only succeed if the caller is actually privileged in the network namespace.

release: Ubuntu 16.10
version: lxc-common: 2.0.6-0ubuntu1~ubuntu16.10.1