netdev - Re: [PATCH net] netlink: don't send unknown nsid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Jun 2017 10:40:24 +0200
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Flavio Leitner <fbl@...close.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net] netlink: don't send unknown nsid

Le 02/06/2017 à 00:44, Flavio Leitner a écrit :
> On Thu, Jun 01, 2017 at 10:42:13PM +0200, Nicolas Dichtel wrote:
>> Le 01/06/2017 à 19:02, Flavio Leitner a écrit :
[snip]
>>> On the other hand, with the original patch, if the socket and the
>>> device are in the same netns, we don't need to report any ID.  Previous
>>> kernels did that, so we are not breaking anything.  When the netns
>>> differs, then we either should report the real ID or an error.
>>>
>> I don't understand. With or without my last patch, the kernel sends netlink
>> messages of other netns than the netns where the socket is opened, only if an
>> nsid is assigned.
> 
> "only if an nsid is assigned" that's the issue.
It was design like that because it's not legitimate to unconditionally listen
all netns of the system. Isolation between namespaces must be respected
(scenarii with containers, etc.).
When a nsid is assigned to a peer netns, it's a way to say "ok, I know this
netns and I have access to it".

> 
> Let me ask this instead: How do you think userspace should behave when
> netnsid allocation fails?
> 
There is two ways to assign a nsid:
 - manually with netlink ('ip netns set'). In this case, the error is reported
   to userspace via netlink.
 - automatically when a x-netns interface is created. The link-nsid is also
   reported to userspace. If the allocation failed, NETNSA_NSID_NOT_ASSIGNED is
   reported. And if you were able to create this x-netns interface, it means
   that you have access to this peer netns, thus you can try to assign the nsid
   manually.
So, in both cases, userland knows that something went wrong.

Do you have another scenario in mind?


Nicolas