I understand, but it's unexpected, therefore noteworthy. 


Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Christian Brauner
Sent: Sunday, January 29, 2017 3:55 PM
To: <email address hidden>
Reply To: Bug 1654676
Subject: Re: [Bug 1654676] Re: lxc-user-nic does not ensure that target netns is caller-owned

On Sun, Jan 29, 2017 at 8:44 PM, Serge Hallyn
<email address hidden> wrote:
> Thanks, Christian. Is there a reason why you don't set fret to -1 if
> the final setns fails?

If the setns() back to the original namespace fails but everything
else succeeded I didn't take it to be a security issue. lxc-user-nic
is pretty short-lived and we don't perform any interesting operations
in the namespace after rename_in_ns() succeeded. We rather exit right
away:

/* Now rename the link. */
if (rename_in_ns(pid, cnic, &vethname) < 0) {
usernic_error("%s", "Failed to rename the link.\n");
exit(EXIT_FAILURE);
}

/* Write the name of the interface pair to the stdout - like
* eth0:veth9MT2L4.
*/
fprintf(stdout, "%s:%s\n", vethname, nicname);
exit(EXIT_SUCCESS);

-- 
You received this bug notification because you are a member of Ubuntu
Container Security team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1654676

Title:
lxc-user-nic does not ensure that target netns is caller-owned

Status in lxc package in Ubuntu:
New

Bug description:
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 a b $$ 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1654676/+subscriptions