Received: by 10.192.165.156 with SMTP id m28csp1129830imm; Wed, 11 Apr 2018 13:00:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx49JKiLXUtdNXPHpe4BucLjr8e3WoCRDPp1z/A6ksKeL1XHpGBUDveeVVT8Cp+m7EJ/ZSvJi X-Received: by 2002:a17:902:887:: with SMTP id 7-v6mr6584661pll.319.1523476852452; Wed, 11 Apr 2018 13:00:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523476852; cv=none; d=google.com; s=arc-20160816; b=zuY0CzqnZX0rEsDHzfAmNTt/Pviq4GxQK5SN0sTLN+J8PU8XeHT5ZbLvqcaQLyyYU3 pzADzCTdCD9cDqgDhQmFvKlcm4BHe/KsoS7IlqLS4vl2CJumEgUO5Kn7AOoqSVV6VY+V fxRF7hxp2RD4XwO5Fb4l/ywo7LVLvCsErBRh9P4Y6X1LkebasxA7YuWE48iBvW1D+EX1 ia1bPQyvLHUN1BHDF3025ITObg55kpAXKuE/3Qwu2STxZgSs5YYvznOl4D/bUCGwfoLu UR8S/JdgM38FS4JtLINfftmgs0KPRe5/n4lZPoECP3o9pmAIazWODWJhLRYIYYnu9xtu Lhfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:date:from:arc-authentication-results; bh=B9SaUXP3ECVbgB+C/ju/43ncI82OsWJ6d0WxiCT6OzQ=; b=uGBHUAGXAxm//TvPACT92fMZpoaj5BINXnwga9GdzSp+BoVhgWJ9gQnEivrB5L9nNN eJK+8ZEiJoddH7mPNv5YNLAmrY9I8VgWz1BmZlmMUAiAHItJLdoQB/Y2OqY1LGmgpZS2 M6i5Gfs4xh80H6Eztlh5NISIjjyzSIOmnEwNnaU7zIo/duy+E6Lela6SmkMXBhoZfW3z 4nRBs0BGV353XvlK1NkTI4ZoZjimnkoV4/NadU0Sw+FHUEjyVSCs8Aa3styDHrmRxsPv DMgLlTGHfSMsQ5hPgjZGLo76QQPPJGlv1pmhQhx86YGjfhHyM+GgH4RnpuY/TJTIEYtu gylA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l17si1186645pgc.681.2018.04.11.13.00.14; Wed, 11 Apr 2018 13:00:52 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756398AbeDKS5X (ORCPT + 99 others); Wed, 11 Apr 2018 14:57:23 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:51842 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756384AbeDKS5U (ORCPT ); Wed, 11 Apr 2018 14:57:20 -0400 Received: from mail-wm0-f69.google.com ([74.125.82.69]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1f6Kvn-0001Zf-0k for linux-kernel@vger.kernel.org; Wed, 11 Apr 2018 18:57:19 +0000 Received: by mail-wm0-f69.google.com with SMTP id p18so1543155wmh.2 for ; Wed, 11 Apr 2018 11:57:19 -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:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=B9SaUXP3ECVbgB+C/ju/43ncI82OsWJ6d0WxiCT6OzQ=; b=PIPwjB7WQsFNab5qypg3veoITkVez+6vr3hIv3GSfAZC8xRQ7mOZDucsRcsttfyYeQ q6EDQJlwrMy1oHJ9/WSck4tu/gR4SBmcnnhFCYqRc2RZQcggyCsbitAAZFuAW8xJVqUp wtaCcR3q9EkLRi3xt1Ivg9a63NWbxfDZtsvm/JNMUkKu2Ba7IH/tTVHahqJ2wQoapnnt snpxX0Mnx579ZzykBvxMCN9Cy6qQseC3DpigBXZCGt8OequHQUnToDoO2UjaNbFTv5S2 HmC3IFLhGdQmu9uLJ3XIJCPnhFDMcZslIngcubJ0FKb3ClwsKT6DP+gb5K6pm0KKYuav 86oQ== X-Gm-Message-State: ALQs6tAtwnq3o/zeFTV4uUuBhB03umI02JYuR0xmDZIDGFMK7QeTOikd iXrH6qKx6Cs9+B/2g5TnQqxAnZ5HmROAaNYZVit+WcF/jcedek3H9onHgw4qVbVxysyMc09B7RO D3dvhmVSOsRiADutkU6isrfe9aGCak2QktrlfiM5zOw== X-Received: by 10.223.164.142 with SMTP id g14mr4161183wrb.18.1523473038623; Wed, 11 Apr 2018 11:57:18 -0700 (PDT) X-Received: by 10.223.164.142 with SMTP id g14mr4161168wrb.18.1523473038363; Wed, 11 Apr 2018 11:57:18 -0700 (PDT) Received: from gmail.com ([2a02:8070:8895:9700:29d3:13fa:afa8:ff34]) by smtp.gmail.com with ESMTPSA id 62sm2427112wrg.34.2018.04.11.11.57.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 11 Apr 2018 11:57:17 -0700 (PDT) From: Christian Brauner X-Google-Original-From: Christian Brauner Date: Wed, 11 Apr 2018 20:57:16 +0200 To: "Eric W. Biederman" Cc: Kirill Tkhai , davem@davemloft.net, gregkh@linuxfoundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, avagin@virtuozzo.com, serge@hallyn.com Subject: Re: [PATCH net-next] netns: filter uevents correctly Message-ID: <20180411185715.GA15862@gmail.com> References: <20180405144130.GB26043@gmail.com> <87in953ryi.fsf@xmission.com> <20180409154627.GA15157@gmail.com> <878t9wx8xw.fsf@xmission.com> <20180410143515.GA14186@gmail.com> <87in8zumpd.fsf@xmission.com> <20180411090907.GA20340@gmail.com> <87tvshlms1.fsf@xmission.com> <20180411170333.GA4319@gmail.com> <87efjllhcx.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87efjllhcx.fsf@xmission.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 11, 2018 at 01:37:18PM -0500, Eric W. Biederman wrote: > Christian Brauner writes: > > > On Wed, Apr 11, 2018 at 11:40:14AM -0500, Eric W. Biederman wrote: > >> Christian Brauner writes: > >> > Yeah, agreed. > >> > But I think the patch is not complete. To guarantee that no non-initial > >> > user namespace actually receives uevents we need to: > >> > 1. only sent uevents to uevent sockets that are located in network > >> > namespaces that are owned by init_user_ns > >> > 2. filter uevents that are sent to sockets in mc_list that have opened a > >> > uevent socket that is owned by init_user_ns *from* a > >> > non-init_user_ns > >> > > >> > We account for 1. by only recording uevent sockets in the global uevent > >> > socket list who are owned by init_user_ns. > >> > But to account for 2. we need to filter by the user namespace who owns > >> > the socket in mc_list. So in addition to that we also need to slightly > >> > change the filter logic in kobj_bcast_filter() I think: > >> > > >> > diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c > >> > index 22a2c1a98b8f..064d7d29ace5 100644 > >> > --- a/lib/kobject_uevent.c > >> > +++ b/lib/kobject_uevent.c > >> > @@ -251,7 +251,8 @@ static int kobj_bcast_filter(struct sock *dsk, struct sk_buff *skb, void *data) > >> > return sock_ns != ns; > >> > } > >> > > >> > - return 0; > >> > + /* Check if socket was opened from non-initial user namespace. */ > >> > + return sk_user_ns(dsk) != &init_user_ns; > >> > } > >> > #endif > >> > > >> > > >> > But correct me if I'm wrong. > >> > >> You are worrying about NETLINK_LISTEN_ALL_NSID sockets. That has > >> permissions and an explicit opt-in to receiving packets from multiple > >> network namespaces. > > > > I don't think that's what I'm talking about unless that is somehow the > > default for NETLINK_KOBJECT_UEVENT sockets. What I'm worried about is > > doing > > > > unshare -U --map-root > > > > then opening a NETLINK_KOBJECT_UEVENT socket and starting to listen to > > uevents. Imho, this should not be possible because I'm in a > > non-init_user_ns. But currently I'm able to - even with the patch to > > come - since the uevent socket in the kernel was created when init_net > > was created and hence is *owned* by the init_user_ns which means it is > > in the list of uevent sockets. Here's a demo of what I mean: > > > > https://asciinema.org/a/175632 > > Why do you care about this case? It's not so much that I care about this case since any workload that wants to run a separate udevd will have to unshare the network namespace and the user namespace for it to make complete sense. What I do care about is that the two of us are absolutely in the clear about what semantics we are going to expose to userspace and it seems that we were talking past each other wrt to this "corner case". For userspace, it needs to be very clear that the intention is to filter by *owning user namespace of the network namespace a given task resides in* and not by user namespace of the task per se. This is what this corner case basically shows, I think. Christian > > Everyone is allowed to listen to the uevent netlink sockets with or > without user namespaces. So there are no permission issues, and > this is not even a data information leak. > > If you don't want programs in your user namespace to have access you > will be able to unshare the network namespace. > > Eric