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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 13DD2C5DF62 for ; Tue, 5 Nov 2019 22:01:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B667521929 for ; Tue, 5 Nov 2019 22:01:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="VGc5idT9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B667521929 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 525326B0003; Tue, 5 Nov 2019 17:01:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D5956B0005; Tue, 5 Nov 2019 17:01:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EBE36B0006; Tue, 5 Nov 2019 17:01:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2A9ED6B0003 for ; Tue, 5 Nov 2019 17:01:57 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id BD38D45C1 for ; Tue, 5 Nov 2019 22:01:56 +0000 (UTC) X-FDA: 76123597032.13.dog76_2e01db91ce50e X-HE-Tag: dog76_2e01db91ce50e X-Filterd-Recvd-Size: 5642 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf23.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Nov 2019 22:01:56 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id 15so2322901pgh.5 for ; Tue, 05 Nov 2019 14:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=A7ntIP7Pv94+JyCxBKyO+PR3oB2uhF7aSLknMJuGR54=; b=VGc5idT9oHFqNsyfeJQtiLGXaEfzZs+LnizeeHBN1hf2vJvDrjEssRXM+KqyPON/w4 XnbKdYccr81lAD6e/iN+6l/Dq4tPu19pl0UnJ7fciIZ9/6AONcHVukjFewb4PchiDh17 7ZPZihF1wJOMYKdIhjYSl5xVnwOnB1EbvZ1sv1e3OAKgQ5U7yKAERlW6szd40jmA1zkn AdFoPGkYJ3soBf432/rLYCS2v3QEXbCMHLpbH+eSaEQajYxFxt/RFcs7NZkkeYCP0Mmz kSc179mn0fGmgKGYJOb0sxsR7zgDRZPjOIBYL/0etkwTHLQn3m8fO5gAB5AGU8D5TsRQ sfiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=A7ntIP7Pv94+JyCxBKyO+PR3oB2uhF7aSLknMJuGR54=; b=XdD5hTiJCGbP4YebJcMfG0u+lQdVTTrUDtKNqeOimwjWqxOb2iaQHws7ArIJfASz/x 8NBBXkJJuBquO18lwqOEJrFjC9DEgAeMXef9j4Ihf3m9cwIXcoa0yvFPnQM5ttSPrB6N vRUGARkmIkyLd+JZqtZ5aKvEbzVRdfIp1v/pU1D6k1dUn5/EK4LdiJbKUfGnwmXacH9Y e8nYRBVDD/eh7oIZzwwYpvO/1U8pllKMd7/TudbKI8fSimM7GpEpXWr6ffku8n9v/ox7 O5WASRQNk8NPhstPdjdP05yQZ10DZTxvhhQo3BM4HjbbYQjjvOICl0hlOPzPp9wxGpEN 3/jA== X-Gm-Message-State: APjAAAXfnQxPJ/n+TLNjqngXzlGeKUOF4MeeNFENcVXVm5TioCOEBtCv Fj2cgptAWjmr4WGIGuQameojbA== X-Google-Smtp-Source: APXvYqwUsPTDc+K+TskpjrNDhdQDKgpFn5VDt8mFWt45sM9wmJoBE2TnjPt+6qS429LWFbbmYiLhVA== X-Received: by 2002:a65:49cf:: with SMTP id t15mr33651193pgs.144.1572991314644; Tue, 05 Nov 2019 14:01:54 -0800 (PST) Received: from ?IPv6:2600:1010:b05d:f15:cda1:50c9:611b:faf7? ([2600:1010:b05d:f15:cda1:50c9:611b:faf7]) by smtp.gmail.com with ESMTPSA id a33sm20535517pgb.57.2019.11.05.14.01.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Nov 2019 14:01:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK Date: Tue, 5 Nov 2019 14:01:51 -0800 Message-Id: <273986A1-A4BE-4FE5-B547-49CAA44C6FD3@amacapital.net> References: 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 In-Reply-To: To: Daniel Colascione X-Mailer: iPhone Mail (17A878) 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 Nov 5, 2019, at 9:02 AM, Daniel Colascione wrote: >=20 > =EF=BB=BFOn Tue, Nov 5, 2019 at 8:56 AM Andrea Arcangeli wrote: >>=20 >>> 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. >>=20 >> 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. >>=20 >> 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? >=20 > 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. I= n principle, it=E2=80=99s better than open for a retrofit =E2=80=94 open did= n=E2=80=99t capture this permission in the past, so adding it makes an exist= ing capability stronger than it was, which isn=E2=80=99t fantastic.=