From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E4CDC433DF for ; Mon, 1 Jun 2020 19:59:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 746AC206E2 for ; Mon, 1 Jun 2020 19:59:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Z+kO0Tqj" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728325AbgFAT7j (ORCPT ); Mon, 1 Jun 2020 15:59:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726667AbgFAT7i (ORCPT ); Mon, 1 Jun 2020 15:59:38 -0400 Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0586C061A0E for ; Mon, 1 Jun 2020 12:59:36 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id 131so3938704pfv.13 for ; Mon, 01 Jun 2020 12:59:36 -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=/ODX5Ijz16QtBmZcvs8Sw5gVm8csvu2kr6ZBZyPx21Y=; b=Z+kO0TqjatiyHbw5hfuBT9IkC+93DFVLHHgYsiaDDt0rwy0nUqdauKdDsONuLtQaza ihVUdqQ2tiGXgPHAkV349CZsv0tYJ2Fvb4rCSNhJ+vmPFkNR/ZlmQ0zFOv0i3pBCNwqH klWKXblqHUNUy1gqq8CydGMqxhbAPA5B/INsk= 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=/ODX5Ijz16QtBmZcvs8Sw5gVm8csvu2kr6ZBZyPx21Y=; b=bpzDVtna4NPn+yMP2s6e0NkQHzkBZLJnsIwYprSmwcqMlAX7xHijQmA2nAvROEo/le 9x7oYkoO/wttpqLWtuEiUyiXJDdsus/bfaOeUfGCHrrA5a2OMNDhOsc0490gRmQfLZIC u3toVavtjI7LhggzdsBcCvW8XYo05loRfzLXRVX4H/p7qnIrImvF28nt3uMlHy2kEDrS ERrQV5TWFaSoSFEEbBM8jw85cOWPPPHTQc6btWbf3BrLGcAsGTVj8tBS2MEEX362hshY WXAiq6l4RR04GtqGjEDUwOwO5fB2f7QQPH0kxBxIA5ixu4G6wGD5AJQ9EDaRiFbOtXSH qsdg== X-Gm-Message-State: AOAM532o46jOOqCbSyxcIeW1NrST9tH8C6dQm/tziMSfx5/xDgAlwAA5 SwJsicq8odQVbss58h00XcpgXQ== X-Google-Smtp-Source: ABdhPJxrEQLuZ1/KCzkfx7bv9ugLFw4ywO5Q4IymFJcw28Jw/7xnEycKw9GiJDjeg0ch7bMSxzi+Pw== X-Received: by 2002:a65:6810:: with SMTP id l16mr19827256pgt.390.1591041576555; Mon, 01 Jun 2020 12:59:36 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id y6sm256763pjw.15.2020.06.01.12.59.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2020 12:59:35 -0700 (PDT) Date: Mon, 1 Jun 2020 12:59:34 -0700 From: Kees Cook To: Sargun Dhillon Cc: Al Viro , Christian Brauner , Linux Containers , Aleksa Sarai , Jann Horn , Jeffrey Vander Stoep , Linux API , LKML , Chris Palmer , Robert Sesek , Tycho Andersen , Matt Denton Subject: Re: [PATCH v2 2/3] seccomp: Introduce addfd ioctl to seccomp user notifier Message-ID: <202006011259.07FAF4AA@keescook> References: <20200528110858.3265-1-sargun@sargun.me> <20200528110858.3265-3-sargun@sargun.me> <202005282345.573B917@keescook> <20200530011054.GA14852@ircssh-2.c.rugged-nimbus-611.internal> <202005291926.E9004B4@keescook> <20200530140837.GM23230@ZenIV.linux.org.uk> <202005300834.6419E818A7@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 01, 2020 at 12:02:10PM -0700, Sargun Dhillon wrote: > On Sat, May 30, 2020 at 9:07 AM Kees Cook wrote: > > > > On Sat, May 30, 2020 at 03:08:37PM +0100, Al Viro wrote: > > > On Fri, May 29, 2020 at 07:43:10PM -0700, Kees Cook wrote: > > > > > > > Can anyone clarify the expected failure mode from SCM_RIGHTS? Can we > > > > move the put_user() after instead? I think cleanup would just be: > > > > replace_fd(fd, NULL, 0) > > > > > > Bollocks. > > > > > > Repeat after me: descriptor tables can be shared. There is no > > > "cleanup" after you've put something there. > > > > Right -- this is what I was trying to ask about, and why I didn't like > > the idea of just leaving the fd in the table on failure. But yeah, there > > is a race if the process is about to fork or something. > > > > So the choice here is how to handle the put_user() failure: > > > > - add the put_user() address to the new helper, as I suggest in [1]. > > (exactly duplicates current behavior) > > - just leave the fd in place (not current behavior: dumps a fd into > > the process without "agreed" notification). > > - do a double put_user (once before and once after), also in [1]. > > (sort of a best-effort combo of the above two. and SCM_RIGHTS is > > hardly fast-pth). > > > > -Kees > > > > [1] https://lore.kernel.org/linux-api/202005282345.573B917@keescook/ > > > > -- > > Kees Cook > > I'm going to suggest we stick to the approach of doing[1]: > 1. Allocate FD > 2. put_user > 3. "Receive" and install file into FD > > That is the only way to preserve the current behaviour in which userspace > is notified about *every* FD that is received via SCM_RIGHTS. The > scm_detach_fds code as it reads today does effectively what is above, > in that the fd is not installed until *after* the put user. Therefore > if put_user > gets an EFAULT or ENOMEM, it falls through to the MSG_CTRUNC bit. > > The approach suggested[2] has a "change" in behaviour, in that (all in > file_receive): > 1. Allocate FD > 2. Receive file > 3. put_user > > Based on what Al Viro said, I don't think we can simply add step #4, > being "just" uninstall the FD. > > [1]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2179418.html > [2]: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2179453.html Agreed. Thanks! -- Kees Cook