Received: by 10.213.65.68 with SMTP id h4csp1111574imn; Wed, 4 Apr 2018 12:50:50 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+yvMPZi6TtHDlwe5qzhdXxdeBwamB72IxhGO41bpE1sGgwHQtFt0nVzWHh6/JmrFRtvbwn X-Received: by 10.98.141.78 with SMTP id z75mr14961626pfd.174.1522871450906; Wed, 04 Apr 2018 12:50:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522871450; cv=none; d=google.com; s=arc-20160816; b=MkMHH2YzEPb2eF0VjVx2f3Aj7GfKKbPbctjzjnTP3FrS/hoKZU40DbdsnAB+d9lpAe GnAImRIf87ybRQmImUK5zz/zbvXcnf0nQh+PXjokQLPjfa+rkb4oSn+Q32WBWcjMTMTi TdvWwOMSvlG8SUoH59ZPnJQ6hRL/JyvQ5d7xE49ol3wbp9dlrfxvMmhzx5CvpcRrkjG0 cB5mQ2v4W3KbWTjYYFfiHbstmX888ERBSLfC/HOWRHPHtHd3BXTpozHVAA1kN+FYuLyl tsLSHPuwT7bjeNVbNsM8H0wmcLp3tHKz77DkSPRgcfigViQ6/QpHnuySd9PRUHYHOBPJ sO3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=uVJpCRcUupMReUqVtPdh0PhAMceqFm/akBEN7vKMyAA=; b=X2upvwt/cljbjtaZlk8qi905WvTd9f5TI+POc0pG6YFD5mj7gyyqjlSwrZVhGKikwO OHryEKbMyPtnK+UayOOZPj6SvLItQP69ePbOGs5bkchO6B6eDaVjsHjA9XVzRfQFqKw5 Yh7zIGVKP8MVoe12qM1o5vPbMyzxx90UpbowKM7h6l9HtQZKS9Ea4FBKzRhLSackbn/n uHpZyWZoJrDEr/YpxerToVWf4x1qDOHXRGwm0DVwPCzeamK8JeVhUg+YSYDHn6dBgS0z UP2+jUQpJj//v+WfmmQS800/7wRlKxuzn3nGiFmxqfZz5PcnjRofRVAPWOF79u7OGEJ6 GPZQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d21-v6si3746676pll.557.2018.04.04.12.50.37; Wed, 04 Apr 2018 12:50:50 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751723AbeDDTtb (ORCPT + 99 others); Wed, 4 Apr 2018 15:49:31 -0400 Received: from mail-wr0-f179.google.com ([209.85.128.179]:46818 "EHLO mail-wr0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751419AbeDDTt3 (ORCPT ); Wed, 4 Apr 2018 15:49:29 -0400 Received: by mail-wr0-f179.google.com with SMTP id d1so24607872wrj.13; Wed, 04 Apr 2018 12:49:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=uVJpCRcUupMReUqVtPdh0PhAMceqFm/akBEN7vKMyAA=; b=L0fuSzXPYcSy7fAO0Rq0h3PlpZ3YlSj1pDXHdEZhC+skRhYmxqKu14R8IKnmboEmac fPj2e51FjdM6+5IpvPp1f25ZwuVHM5kVjf7ifZxz6XRfiXlYJEz9Dl98zuwRjF1A1JG2 umdYQ138kyfsyhm+B2LneiAfKZD358ixp3agmbx4+zogyClUfnp8FVfnycOGvOoCgbT4 woi8hTyMLLa399wwWqjd7m3Ze8qrrLNoooIzqO8Zutb7dNXyInazZKWrf3Z6DbvSOau9 IcftgRWkvvvtTyaKcfAfCmNAt3JRSnZgCzEH/9P3qFQwU9nmTsPiHg+JXrdbZhf0rgP9 dsUA== X-Gm-Message-State: AElRT7Fz1iMGae9i8jWIb5zppslZXpNYfSXcRTpnLv6B+PZQoclsfdnw kYYipuZQj8qLySeuUcxSPy0= X-Received: by 10.223.227.73 with SMTP id n9mr13478027wrj.134.1522871368032; Wed, 04 Apr 2018 12:49:28 -0700 (PDT) Received: from localhost.localdomain ([2a02:8070:8895:9700:f846:923f:cd5e:df8b]) by smtp.gmail.com with ESMTPSA id j41sm4105641wre.57.2018.04.04.12.49.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Apr 2018 12:49:27 -0700 (PDT) From: Christian Brauner To: ebiederm@xmission.com, davem@davemloft.net, gregkh@linuxfoundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Cc: avagin@virtuozzo.com, ktkhai@virtuozzo.com, serge@hallyn.com, Christian Brauner Subject: [PATCH net-next] netns: filter uevents correctly Date: Wed, 4 Apr 2018 21:48:57 +0200 Message-Id: <20180404194857.29375-1-christian.brauner@ubuntu.com> X-Mailer: git-send-email 2.15.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org commit 07e98962fa77 ("kobject: Send hotplug events in all network namespaces") enabled sending hotplug events into all network namespaces back in 2010. Over time the set of uevents that get sent into all network namespaces has shrunk. We have now reached the point where hotplug events for all devices that carry a namespace tag are filtered according to that namespace. Specifically, they are filtered whenever the namespace tag of the kobject does not match the namespace tag of the netlink socket. One example are network devices. Uevents for network devices only show up in the network namespaces these devices are moved to or created in. However, any uevent for a kobject that does not have a namespace tag associated with it will not be filtered and we will *try* to broadcast it into all network namespaces. The original patchset was written in 2010 before user namespaces were a thing. With the introduction of user namespaces sending out uevents became partially isolated as they were filtered by user namespaces: net/netlink/af_netlink.c: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)) j return; } The file_ns_capable() check will check whether the caller had CAP_NET_BROADCAST at the time of opening the netlink socket in the user namespace of interest. This check is fine in general but seems insufficient to me when paired with uevents. The reason is that devices always belong to the initial user namespace so uevents for kobjects that do not carry a namespace tag should never be sent into another user namespace. This has been the intention all along. But there's one case where this breaks, namely if a new user namespace is created by root on the host and an identity mapping is established between root on the host and root in the new user namespace. Here's a reproducer: sudo unshare -U --map-root udevadm monitor -k # Now change to initial user namespace and e.g. do modprobe kvm # or rmmod kvm will allow the non-initial user namespace to retrieve all uevents from the host. This seems very anecdotal given that in the general case user namespaces do not see any uevents and also can't really do anything useful with them. Additionally, it is now possible to send uevents from userspace. As such we can let a sufficiently privileged (CAP_SYS_ADMIN in the owning user namespace of the network namespace of the netlink socket) userspace process make a decision what uevents should be sent. This makes me think that we should simply ensure that uevents for kobjects that do not carry a namespace tag are *always* filtered by user namespace in kobj_bcast_filter(). Specifically: - If the owning user namespace of the uevent socket is not init_user_ns the event will always be filtered. - If the network namespace the uevent socket belongs to was created in the initial user namespace but was opened from a non-initial user namespace the event will be filtered as well. Put another way, uevents for kobjects not carrying a namespace tag are now always only sent to the initial user namespace. The regression potential for this is near to non-existent since user namespaces can't really do anything with interesting devices. Signed-off-by: Christian Brauner --- lib/kobject_uevent.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c index 15ea216a67ce..cb98cddb6e3b 100644 --- a/lib/kobject_uevent.c +++ b/lib/kobject_uevent.c @@ -251,7 +251,15 @@ static int kobj_bcast_filter(struct sock *dsk, struct sk_buff *skb, void *data) return sock_ns != ns; } - return 0; + /* + * The kobject does not carry a namespace tag so filter by user + * namespace below. + */ + if (sock_net(dsk)->user_ns != &init_user_ns) + return 1; + + /* Check if socket was opened from non-initial user namespace. */ + return sk_user_ns(dsk) != &init_user_ns; } #endif -- 2.15.1