From mboxrd@z Thu Jan  1 00:00:00 1970
From: ebiederm@xmission.com (Eric W. Biederman)
Subject: Re: [PATCH net-next] netns: filter uevents correctly
Date: Fri, 06 Apr 2018 11:48:40 -0500
Message-ID: <878ta01dsn.fsf@xmission.com>
References: <20180404194857.29375-1-christian.brauner@ubuntu.com>
        <442e89b8-e947-6eeb-1bcb-fa28f22a25f0@virtuozzo.com>
        <20180405140709.GA1697@gmail.com>
        <941de2b9-332f-75fc-f8ac-4059a9b5426f@virtuozzo.com>
        <20180405144130.GB26043@gmail.com> <87in953ryi.fsf@xmission.com>
        <20180406130704.GB9263@gmail.com> <874lko2y22.fsf@xmission.com>
        <20180406160757.GA16281@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>, davem@davemloft.net,
        gregkh@linuxfoundation.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, avagin@virtuozzo.com,
        serge@hallyn.com
To: Christian Brauner <christian.brauner@canonical.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20180406160757.GA16281@gmail.com> (Christian Brauner's message
        of "Fri, 6 Apr 2018 18:07:59 +0200")
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

Christian Brauner <christian.brauner@canonical.com> writes:

>> At a practical level there should be no receivers.  Plus performance
>> issues.  At least my memory is that any unprivileged user on the system
>> is allowed to listen to those events.
>
> Any unprivileged user is allowed to listen to uevents if they have
> net_broadcast in the user namespace the uevent socket was opened in;
> unless I'm misreading.

I believe you are.

This code in do_one_broadcast.

	if (!net_eq(sock_net(sk), p->net)) {
		if (!(nlk->flags & NETLINK_F_LISTEN_ALL_NSID))
			return;

		if (!peernet_has_id(sock_net(sk), p->net))
			return;

		if (!file_ns_capable(sk->sk_socket->file, p->net->user_ns,
				     CAP_NET_BROADCAST))
			return;
	}

Used to just be:
	if (!net_eq(sock_net(sk), p->net))
        	return;

Which makes sense when you have a shared hash table and a shared mc_list
between network namespaces.

There is a non-container use of network namespaces where you just need
different contexts were ip addresses can overlap etc.  In that
configuration where a single program is mananging multiple network
namespaces being able to listen to rtnetlink events in all of them is an
advantage.

For that case a special socket option NETLINK_F_LISTEN_ALL_NSID was
added that allowed one socket to listen for events from multiple network
namespaces.

If we rework the code in af_netlink.c that matters.  However for just
understanding uevents you can assume there are no sockets with
NETLINK_F_LISTEN_ALL_NSID set.

Eric