Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp1076129ybm; Fri, 29 May 2020 21:02:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNvMye8+kUILrFjJFjj9mKVNma4TCr1ptuY9TmqsuIj9cGCCpZkFwwzZzDAM0v4D+SUpmq X-Received: by 2002:a17:906:f74a:: with SMTP id jp10mr4249648ejb.43.1590811374804; Fri, 29 May 2020 21:02:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590811374; cv=none; d=google.com; s=arc-20160816; b=HWwx0DwUTQW7jis9GelQ7OxPyv4g49rUVs/N5XqOtL3IunmomULfQljk6Qb3cbTmO6 2r/fOf581vOZGge5urngrW74j41H6+gtHxFEdsR0jx5RiWVGO+/r8NvW3Un03u7XArUb P9dtYON16/wplyRghB0S0URMbZUM6EfGZuSDVmNHNG943tzBtHn0xBAPU0tWhJXBLmGG 8svmon5JPp/0Y+46iaih+Jp3T2oYUhi6SeJiDFyH5reN014Ort4EaScAJ1+8V7ze/zlg whWXkak90/t64+c7XSOK83uNcWiiz1MFIspno7AUQIMi2/+qVxHz0rTePPL8RIakJsZq Qawg== 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:from:date:dkim-signature; bh=4hjG9hz3EH+3drDgKCvmYmzuw/OQvSsB0LXZfpCBTlU=; b=PuvFwY1uEVC6GEg2Ji8BY56vf855k69MivSowuO3X70TQD0Q/jRCTWF42vgPpMBz7L S2iSjwravf4SdLy+MfYO0wUC5merOso4rgKyk0ualpAltIvhCmeoqevt4v2FbNzlapdu /e78WlV9bx3lais8dlu3apCMqehIQVymHgxfnfMxv2nODQwiZX/Hcb/Xyzrw9jdrl2r2 Dt/GuLWLD8x9MshiSneseak8AMyqKVDgcg+XbbcMq/HUute61MhbO+FnYeZfHQKdMVp+ WoeH3puK83foGigmsy8QNU4WxS9gz1ftx0ftNeRsyjwdmhpZkNivx7n2VOnXbn2olqL8 cyDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sargun.me header.s=google header.b=Kv2etjco; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e12si7252621edc.122.2020.05.29.21.01.54; Fri, 29 May 2020 21:02:54 -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=@sargun.me header.s=google header.b=Kv2etjco; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728714AbgE3D6X (ORCPT + 99 others); Fri, 29 May 2020 23:58:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728297AbgE3D6W (ORCPT ); Fri, 29 May 2020 23:58:22 -0400 Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12B95C08C5CA for ; Fri, 29 May 2020 20:58:21 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id h10so1498128iob.10 for ; Fri, 29 May 2020 20:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sargun.me; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=4hjG9hz3EH+3drDgKCvmYmzuw/OQvSsB0LXZfpCBTlU=; b=Kv2etjcoo7zuA1LfGWyV3Eb9+nadY2RNQ8JjdQ6A0NpvSsZQ/98XpCWAkjYjc6bZFH tef0ccBNVBYDBlVDfXqeQbgqFSVYW5+Bt0f7lzShARHkrKoFA+bO5WTrnhmN3Ux46iDw qysLrJg/8nTV15VlwTmEqbzIW3709dZ5/A8F8= 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:user-agent; bh=4hjG9hz3EH+3drDgKCvmYmzuw/OQvSsB0LXZfpCBTlU=; b=nd6v8ZUD1htsVlhcvpvGQjawy+JvkRP16b7IH7Lnd6kbv2lo2WnVG/K3f2AgCRta4b o1b09KrEdGUuC5pL7iDE1iqVRwfkkb+I0PkLdmqPQ+JMfL3I6x1eT6MvAlZnd49XnY2C 5gjajNKCKY2xWOh2KXtyItHf2xyGTvfYxG4ZRCbMSiBOtzm8j1/7EnFuRBrhnykJfZcP eOmC1I4BP/rw9c14qMpMzJrhC2s5YV2dvOgaNwZW74tp2Prqzqy5DY+k7NpzYRdKoN4n VU62gWaoLEnoifA5dRKaflSH3dS9qDP149lH8NE0C0FPZ8cxohb1TQyVuLTnIf0E+7Ft eTXQ== X-Gm-Message-State: AOAM530xfNrtEdYlPoNLgvyhY99q2n+oWKxQ4cT+sG//qfwsM6waXwNm zh5Y41WDryQVVyXIPwHD5O9lVA== X-Received: by 2002:a02:a805:: with SMTP id f5mr10863154jaj.130.1590811100116; Fri, 29 May 2020 20:58:20 -0700 (PDT) Received: from ircssh-2.c.rugged-nimbus-611.internal (80.60.198.104.bc.googleusercontent.com. [104.198.60.80]) by smtp.gmail.com with ESMTPSA id a13sm5954875ill.51.2020.05.29.20.58.19 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 29 May 2020 20:58:19 -0700 (PDT) Date: Sat, 30 May 2020 03:58:18 +0000 From: Sargun Dhillon To: Kees Cook Cc: christian.brauner@ubuntu.com, containers@lists.linux-foundation.org, cyphar@cyphar.com, jannh@google.com, jeffv@google.com, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, palmer@google.com, rsesek@google.com, tycho@tycho.ws, Matt Denton , Al Viro Subject: Re: [PATCH v2 2/3] seccomp: Introduce addfd ioctl to seccomp user notifier Message-ID: <20200530035817.GA20457@ircssh-2.c.rugged-nimbus-611.internal> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202005291926.E9004B4@keescook> 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 > > I mean, yes, that's certainly better, but it just seems a shame that > everyone has to do the get_unused/put_unused dance just because of how > SCM_RIGHTS does this weird put_user() in the middle. > > 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) > > So: > > (updated to skip sock updates on failure; thank you Christian!) > > int file_receive(int fd, unsigned long flags, struct file *file) > { > struct socket *sock; > int ret; > > ret = security_file_receive(file); > if (ret) > return ret; > > /* Install the file. */ > if (fd == -1) { > ret = get_unused_fd_flags(flags); > if (ret >= 0) > fd_install(ret, get_file(file)); > } else { > ret = replace_fd(fd, file, flags); > } > > /* Bump the sock usage counts. */ > if (ret >= 0) { > sock = sock_from_file(addfd->file, &err); > if (sock) { > sock_update_netprioidx(&sock->sk->sk_cgrp_data); > sock_update_classid(&sock->sk->sk_cgrp_data); > } > } > > return ret; > } > > scm_detach_fds() > ... > for (i=0, cmfptr=(__force int __user *)CMSG_DATA(cm); i i++, cmfptr++) > { > int new_fd; > > err = file_receive(-1, MSG_CMSG_CLOEXEC & msg->msg_flags > ? O_CLOEXEC : 0, fp[i]); > if (err < 0) > break; > new_fd = err; > Isn't the "right" way to do this to allocate a bunch of file descriptors, and fill up the user buffer with them, and then install the files? This seems to like half-install the file descriptors and then error out. I know that's the current behaviour, but that seems like a bad idea. Do we really want to perpetuate this half-broken state? I guess that some userspace programs could be depending on this -- and their recovery semantics could rely on this. I mean this is 10+ year old code. > err = put_user(err, cmfptr); > if (err) { > /* > * If we can't notify userspace that it got the > * fd, we need to unwind and remove it again. > */ > replace_fd(new_fd, NULL, 0); > break; > } > } > ... > > > > -- > Kees Cook