[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership
From:       "Serge E. Hallyn" <serge () hallyn ! com>
Date:       2017-03-28 14:49:04
Message-ID: 20170328144904.GA12627 () mail ! hallyn ! com
[Download RAW message or body]

On Tue, Mar 28, 2017 at 06:45:34AM -0400, Stiepan wrote:
> Thanks to the 2.0.7-2 update by Evgeni Golov and his crystal-clear instructions on how to use \
> lxcbr0 with this version, I could confirm that the issue with the host's routing table being \
> affected by changes in the containers' routing tables is not there anymore when using that \
> version (lxc 2.0.7-2 from jessie-backports), which includes the fixes to CVE-2017-5985 which \
> were brought in LXC 2.0.7 (upstream). 
> This was thus basically a variation of said CVE, which probably doesn't need to be separately \
> numbered as such, the core problem at stake being the same: network namespace ownership was \
> not respected by a setuid-root program enabling the user to configure networks as non-root, \
> which is now solved. This leads me to a suggestion to the upstream developers: couldn't the \
> same be achieved using specific network-related capabilities, instead of setuid-root, thereby \
> further reducing the risk of lxc-user-nic being exploited and hence, reducing overall attack \
> surface (in unprivileged mode)? I have read in https://wiki.ubuntu.com/UserNamespace that the \
> approach of using "targeted capabilities" was then considered. This is probably the closest \
> to what I am suggesting (specifically for lxc-user-nic - the current approach with 1-1 uid \
> mappings seems fine for network-unrelated things).

The targeted capabilities wouldn't help here, because in fact
lxc-user-nic requires privilege against the parent namespace.

-serge


[prev in list] [next in list] [prev in thread] [next in thread]