Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp962034ybg; Wed, 3 Jun 2020 19:31:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx6NGDYingVDQLDXeqyBiRHZg8BVd/WLcki+nwLEe5NXAkMI9kTOrhpNYMYdxaujrrRCxkd X-Received: by 2002:a17:906:4b18:: with SMTP id y24mr1996427eju.366.1591237901534; Wed, 03 Jun 2020 19:31:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591237901; cv=none; d=google.com; s=arc-20160816; b=lpyFaUfARDYjG2CWCkmdqCQymVcM2dLb/70CT63wCR/oX71bXbQnQSG7mIvV/2Mx/9 RwmMItKcKWbnUHtm51fv3DnmwkGT3GhcpDVNiT5GNI19XCbpE52/oVEooRyHSo2Ph5fl iCCRck7Z/phPRarRrZryZp2+c1d3iZbh10UdUGwcMqUcqy9uHhBKBWQ67RbyiDGA20FB u6otYwm1W4qux7XEICiaW74Dhr8tocNqPvaYQ81wZh+KlqYyx5OjjeluXXrECVqjcqhW cfqjkgTzCK4NF30rqDH004XkY36guKw+jzFxHWnXazTA+KhRhAGBzTdh7BgrCwDrhRHo xI1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Yipjb/nJ+PoPYGY3bQlr0vEC5GDtsZwp9TVgxD0rnGk=; b=lR7rD4UXbTHCQjXKNUksToSrR4iYFudqDyLxj3SZ4iYDt1BGY2N+dobqE6jfpiWAI1 WLy5xG/wL/78YvUs+j3tlOhBfgolhdrGW7QP1VkzFNdLW83R7FJkIzIh6g5Tya8jWaKe UkNYI4PNt1RiWTT7AFzvLDprLcrDKnAM8Mn0ctLxv3kxAiD8AS6+J7w4mKjwEKaBZQul mfcAAy/1qM8MuCJIScHNvvsYL5e+2w54qYx3wczEZ8fH56DH8+yJETHhxpRtf7ZHEalW sOwGLlxr6K5xogBNybccBhWA6dOqHbKVxD+BzV2iuUxVAyoNLqb2olAz/dvUAwaEXeME I4ng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Qn2BQw97; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t15si883860edy.62.2020.06.03.19.31.17; Wed, 03 Jun 2020 19:31:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Qn2BQw97; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726860AbgFDCXA (ORCPT + 99 others); Wed, 3 Jun 2020 22:23:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53754 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726260AbgFDCXA (ORCPT ); Wed, 3 Jun 2020 22:23:00 -0400 Received: from mail-pj1-x1042.google.com (mail-pj1-x1042.google.com [IPv6:2607:f8b0:4864:20::1042]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFD0EC08C5C1 for ; Wed, 3 Jun 2020 19:22:59 -0700 (PDT) Received: by mail-pj1-x1042.google.com with SMTP id nm22so411994pjb.4 for ; Wed, 03 Jun 2020 19:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Yipjb/nJ+PoPYGY3bQlr0vEC5GDtsZwp9TVgxD0rnGk=; b=Qn2BQw97F7bIZrtjDlecVedaFxpvLQXfHqx5ZIkhrdMftq1Uzxuvb3gxbs04al8f6z dUNJTwOCuq0f5AzUIWaq/boxSUbsE7CQq5poZsErcM9jbnlKvwg3ugwzZmw6UY051thR aeypVbCcCPa33vgHBqM+4kc/3K8/7P1pLFmH0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Yipjb/nJ+PoPYGY3bQlr0vEC5GDtsZwp9TVgxD0rnGk=; b=eNnU0vicC6qql6vTPBop6JDUMdHhq0v2N2kooHLxXcKafZlRiyAHZyejuX8ZBEMI4K fRj7eI8sHOITyYeRre6X8H8gBE0W12FjT8nuOPvuFh19ZYgtChPqSVSQjmiVcD92lAOS Hl90fqWwNfYUL6ky5rvb8y9d222bSo/uRDqtqcOVGPer1/NKs+Ucr+p91Dhk5H+Qo/BT c1SNp22gUGUEC5zUO75/Gle5+MTL1X8AnDCx3MwoDWCXP/7aNGMC91iqoXLUBL14cNLr EA8Xxm5Iq1LEtgKZbh9RUiBvV/dQbnEEhwZjb/ztgc6wdG4yuFoPEdTtvTG1HkEdSguJ Q/Xw== X-Gm-Message-State: AOAM533vfl6qXUMqBksTaK+mfgeI/ypTD0Im8q4RI1+V9LJNPpaTgn+3 4TzsqsNRFEMe+GiB6CWTozk3Mg== X-Received: by 2002:a17:90a:4d4e:: with SMTP id l14mr3326764pjh.10.1591237379271; Wed, 03 Jun 2020 19:22:59 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y6sm3106283pfp.144.2020.06.03.19.22.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jun 2020 19:22:58 -0700 (PDT) Date: Wed, 3 Jun 2020 19:22:57 -0700 From: Kees Cook To: Christian Brauner Cc: Sargun Dhillon , linux-kernel@vger.kernel.org, Tycho Andersen , Matt Denton , Jann Horn , Chris Palmer , Aleksa Sarai , Robert Sesek , containers@lists.linux-foundation.org, Giuseppe Scrivano , Greg Kroah-Hartman , Al Viro , Daniel Wagner , "David S . Miller" , John Fastabend , Tejun Heo , stable@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v3 1/4] fs, net: Standardize on file_receive helper to move fds across processes Message-ID: <202006031845.F587F85A@keescook> References: <20200603011044.7972-1-sargun@sargun.me> <20200603011044.7972-2-sargun@sargun.me> <20200604012452.vh33nufblowuxfed@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200604012452.vh33nufblowuxfed@wittgenstein> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 04, 2020 at 03:24:52AM +0200, Christian Brauner wrote: > On Tue, Jun 02, 2020 at 06:10:41PM -0700, Sargun Dhillon wrote: > > Previously there were two chunks of code where the logic to receive file > > descriptors was duplicated in net. The compat version of copying > > file descriptors via SCM_RIGHTS did not have logic to update cgroups. > > Logic to change the cgroup data was added in: > > commit 48a87cc26c13 ("net: netprio: fd passed in SCM_RIGHTS datagram not set correctly") > > commit d84295067fc7 ("net: net_cls: fd passed in SCM_RIGHTS datagram not set correctly") > > > > This was not copied to the compat path. This commit fixes that, and thus > > should be cherry-picked into stable. > > > > This introduces a helper (file_receive) which encapsulates the logic for > > handling calling security hooks as well as manipulating cgroup information. > > This helper can then be used other places in the kernel where file > > descriptors are copied between processes > > > > I tested cgroup classid setting on both the compat (x32) path, and the > > native path to ensure that when moving the file descriptor the classid > > is set. > > > > Signed-off-by: Sargun Dhillon > > Suggested-by: Kees Cook > > Cc: Al Viro > > Cc: Christian Brauner > > Cc: Daniel Wagner > > Cc: David S. Miller > > Cc: Jann Horn , > > Cc: John Fastabend > > Cc: Tejun Heo > > Cc: Tycho Andersen > > Cc: stable@vger.kernel.org > > Cc: cgroups@vger.kernel.org > > Cc: linux-fsdevel@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > --- > > fs/file.c | 35 +++++++++++++++++++++++++++++++++++ > > include/linux/file.h | 1 + > > net/compat.c | 10 +++++----- > > net/core/scm.c | 14 ++++---------- > > 4 files changed, 45 insertions(+), 15 deletions(-) > > > > diff --git a/fs/file.c b/fs/file.c > > index abb8b7081d7a..5afd76fca8c2 100644 > > --- a/fs/file.c > > +++ b/fs/file.c > > @@ -18,6 +18,9 @@ > > #include > > #include > > #include > > +#include > > +#include > > +#include > > > > unsigned int sysctl_nr_open __read_mostly = 1024*1024; > > unsigned int sysctl_nr_open_min = BITS_PER_LONG; > > @@ -931,6 +934,38 @@ int replace_fd(unsigned fd, struct file *file, unsigned flags) > > return err; > > } > > > > +/* > > + * File Receive - Receive a file from another process > > + * > > + * This function is designed to receive files from other tasks. It encapsulates > > + * logic around security and cgroups. The file descriptor provided must be a > > + * freshly allocated (unused) file descriptor. > > + * > > + * This helper does not consume a reference to the file, so the caller must put > > + * their reference. > > + * > > + * Returns 0 upon success. > > + */ > > +int file_receive(int fd, struct file *file) > > This is all just a remote version of fd_install(), yet it deviates from > fd_install()'s semantics and naming. That's not great imho. What about > naming this something like: > > fd_install_received() > > and move the get_file() out of there so it has the same semantics as > fd_install(). It seems rather dangerous to have a function like > fd_install() that consumes a reference once it returned and another > version of this that is basically the same thing but doesn't consume a > reference because it takes its own. Seems an invitation for confusion. > Does that make sense? We have some competing opinions on this, I guess. What I really don't like is the copy/pasting of the get_unused_fd_flags() and put_unused_fd() needed by (nearly) all the callers. If it's a helper, it should help. Specifically, I'd like to see this: int file_receive(int fd, unsigned long flags, struct file *file, int __user *fdptr) { struct socket *sock; int err; err = security_file_receive(file); if (err) return err; if (fd < 0) { /* Install new fd. */ int new_fd; err = get_unused_fd_flags(flags); if (err < 0) return err; new_fd = err; /* Copy fd to any waiting user memory. */ if (fdptr) { err = put_user(new_fd, fdptr); if (err < 0) { put_unused_fd(new_fd); return err; } } fd_install(new_fd, get_file(file)); fd = new_fd; } else { /* Replace existing fd. */ err = replace_fd(fd, file, flags); if (err) return err; } /* Bump the cgroup usage counts. */ sock = sock_from_file(fd, &err); if (sock) { sock_update_netprioidx(&sock->sk->sk_cgrp_data); sock_update_classid(&sock->sk->sk_cgrp_data); } return fd; } If everyone else *really* prefers keeping the get_unused_fd_flags() / put_unused_fd() stuff outside the helper, then I guess I'll give up, but I think it is MUCH cleaner this way -- all 4 users trim down lots of code duplication. -- Kees Cook