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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 449FDC5DF60 for ; Tue, 5 Nov 2019 22:10:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DBD7821A4A for ; Tue, 5 Nov 2019 22:10:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="txaxdUHA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DBD7821A4A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 98AF96B0010; Tue, 5 Nov 2019 17:10:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9625D6B0269; Tue, 5 Nov 2019 17:10:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89F916B026C; Tue, 5 Nov 2019 17:10:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0023.hostedemail.com [216.40.44.23]) by kanga.kvack.org (Postfix) with ESMTP id 761AE6B0010 for ; Tue, 5 Nov 2019 17:10:56 -0500 (EST) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with SMTP id 2E77AF96 for ; Tue, 5 Nov 2019 22:10:56 +0000 (UTC) X-FDA: 76123619712.21.sand52_7c85116c6db31 X-HE-Tag: sand52_7c85116c6db31 X-Filterd-Recvd-Size: 5504 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Nov 2019 22:10:55 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id q28so16387995lfa.5 for ; Tue, 05 Nov 2019 14:10:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oHNoa42wrptLOIF/3dlMMyJwxrj4Pwhbf1WPBq8o3uM=; b=txaxdUHAhhP9SDZaT+2LCWEybyxTXeBjbSvIEpNO3NUlCNP11+juSvK4NTapgDIQsx bx4UA6EMOgVRpvfj9Ytg3Dbq2TH/brOOWOMH+2KBx/B/IHrQbQAjLifbp0FSTSQsO2Bd NiuZC+eFppZJoQE3ZUPlpHN1pT+rO6Z14hJeshOd2hCFXwk4GR///Yx4GRVniJ3VKONO Kt+mJci6Da3WvnYbEe8gDOsTV7j/2J9XBqJqDkJ51fvbH5UQdmpyyfw/VvxEU/blzMIM MaPDes1kjsPOjqDH4nLH7vZE3u4nXKFUCYPNkeargYEdaXpUvyyeDnNhBld+YwzcgZEF lFzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oHNoa42wrptLOIF/3dlMMyJwxrj4Pwhbf1WPBq8o3uM=; b=OzuDyE3iC5uDUc+2FPlXSgTCgVYNQ4vPWi6xzMXdd5fzWlE4uTZMkyKws/vW+bQnJk p12tz0Pgbb0rf7D/pdka4sLL7aVcuf3wC0VoSEx+PFIp+2/fpFGdgdxzMjWlUnuFvTfY I3Kwnj02xOOvPeaoMWyrzWvduW7nErTlH+pVPVI+vv5W6LyLE4S6ZSjJgmZZvaeZeqFr 6tDCDloOwfI2cODJ6KxexrMwV+TezsoFUf7O8XlaqlelNGxax3O+BWbty9oY9FWpeI2K FOUpAA4Ql+ge0Xv2W4RDFx2dl0kEuNQUJazi/kDgZrh3GZ6XU0f20mCJBJnaRk+G4Zly AKlg== X-Gm-Message-State: APjAAAVReVTusJWmVo0fVdz5/u6pY6Ts92+btDXgUYJcqiiP/wd7ljVb TFkfX53CtKMZXV7mk3P4Gw7w/9zXiox8e5nhd/e+NQ== X-Google-Smtp-Source: APXvYqzbkj8YH9eITFZzXyrVd6DZFMTF5o/g/z0Eip1PKIKK6ASKx4h4gD3fA7MnFeAp5hmlIjHyjgVN7N9W0POhIHg= X-Received: by 2002:ac2:5587:: with SMTP id v7mr135624lfg.79.1572991853663; Tue, 05 Nov 2019 14:10:53 -0800 (PST) MIME-Version: 1.0 References: <273986A1-A4BE-4FE5-B547-49CAA44C6FD3@amacapital.net> In-Reply-To: <273986A1-A4BE-4FE5-B547-49CAA44C6FD3@amacapital.net> From: Daniel Colascione Date: Tue, 5 Nov 2019 14:10:16 -0800 Message-ID: Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK To: Andy Lutomirski Cc: Andrea Arcangeli , Andy Lutomirski , Mike Rapoport , linux-kernel , Andrew Morton , Jann Horn , Linus Torvalds , Lokesh Gidra , Nick Kralevich , Nosh Minwalla , Pavel Emelyanov , Tim Murray , Linux API , linux-mm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 5, 2019 at 2:01 PM Andy Lutomirski wrote: > > On Nov 5, 2019, at 9:02 AM, Daniel Colascione wrote= : > > > > =EF=BB=BFOn Tue, Nov 5, 2019 at 8:56 AM Andrea Arcangeli wrote: > >> > >>> On Tue, Nov 05, 2019 at 08:39:26AM -0800, Daniel Colascione wrote: > >>> I'm not suggesting that we fail userfaultfd(2) without CAP_SYS_PTRACE= . > >>> That would, as you point out, break things. I'm talking about > >>> recording *whether* we had CAP_SYS_PTRACE in an internal flag in the > >>> uffd context when we create the thing --- and then, at ioctl time, > >>> checking that flag, not the caller's CAP_SYS_PTRACE, to see whether > >>> UFFD_FEATURE_EVENT_FORK should be made available. This way, the > >>> security check hinges on whether the caller *at create time* was > >>> privileged. > >> > >> Until now it wasn't clear to me you still wanted to do the permission > >> check in UFFDIO_API time, and you only intended to move the > >> "measurement" of the capability to the syscall. > >> > >> So you're suggesting to add more kernel complexity to code pending for > >> removal to achieve a theoretically more pure solution in the band-aid > >> required to defer the removal of the posix-breaking read > >> implementation of the uffd fork feature? > > > > And you're suggesting making a security check work weirdly unlike most > > other security checks because you hope it'll get removed one day? > > Temporary solutions aren't, and if something goes into the kernel at > > all, it's worth getting right. The general rule is that access checks > > happen at open time. The kernel has already been bitten by UFFD > > exempting itself from the normal rules (e.g., the > > read(2)-makes-a-file-descriptor thing) in the name of expediency. > > There shouldn't be any more exceptions. > > I don=E2=80=99t think ioctl() checking permission is particularly unusual= . In principle, it=E2=80=99s better than open for a retrofit =E2=80=94 open= didn=E2=80=99t capture this permission in the past, so adding it makes an = existing capability stronger than it was, which isn=E2=80=99t fantastic. All right, let's do it the way the OP's patch does it then.