Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp999457ybx; Tue, 5 Nov 2019 08:43:24 -0800 (PST) X-Google-Smtp-Source: APXvYqyApZIw7q9EzblpcEgXKofOIQVjhVO3s+dr0oe6RHIuX+xWLRyYocDrTNvlHCAu/NSHd1Ng X-Received: by 2002:a17:906:3285:: with SMTP id 5mr29409232ejw.143.1572972204771; Tue, 05 Nov 2019 08:43:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572972204; cv=none; d=google.com; s=arc-20160816; b=EDQN04RlirCylAmmja2RcDW9qJtFYLVKTfyvpqfg1hrIujyz2tQsQJUpmiMflXcb7r A94PjYJtvCUQ3Rv7rjOfjA/WtTm9hlb/H0KEeqTLKbav5X/Pi2vDnoEp6cSqifhJHiHV gSmfu4vfF2byriwHaTDr3ATpt2oD8cWHBI00mr2GlvjRJAuaKOzmOjzxKKsaHYY2gixY VPkBSMkBoJObbS8et5bgqIVRFZR33yS3tSTMzQgj8bFPuPhA825mGRP+2E2GBbzacLYI WgNvUL1j5nauNMUb8Y6I6qT6/t62cvSMZ1SfgXyrZuJ/wIJyqtzxmU2j5YEPLq5hPUfV PFfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fZq9/Aaey+SN0l5GZyRu+H8Ix+9Q121u+Zli7RR28cM=; b=Y/zWQyTLqFiJzf79vlooM/NT/He7G2c+1bW3gnCoiFtsTTQtWEP6VEsIiCHllYzcxh ltnz/kCIVyd+/YQ2E3jvHAKhUi9qbyKGk4SL7IszuXfwtmp/2vRFFZg8dYX17yL8YZpn 5Pyu+wgAJyF9TGny0KTaPaPYHAXw5VFb37E7/jeoUS8SLwZB6kKdweB647Pi93yeZv52 vIjn5t5OjO7xjJl/A+UjVDqpLJM6P9Qcbs19XgeTHR4DbXKMARQiOiRZ8ooOf13M6tMu c5yseJtXdrK+4R0vf5MpyFPn8UVv4ZHxB8WFgLZifnUxTXqO3BWn3OGv9qBw/Kby64PD LU2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dpE3RFax; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c31si9650902edb.56.2019.11.05.08.43.00; Tue, 05 Nov 2019 08:43:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=dpE3RFax; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390273AbfKEQkF (ORCPT + 99 others); Tue, 5 Nov 2019 11:40:05 -0500 Received: from mail-lf1-f65.google.com ([209.85.167.65]:36661 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390159AbfKEQkE (ORCPT ); Tue, 5 Nov 2019 11:40:04 -0500 Received: by mail-lf1-f65.google.com with SMTP id a6so12243600lfo.3 for ; Tue, 05 Nov 2019 08:40:03 -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; bh=fZq9/Aaey+SN0l5GZyRu+H8Ix+9Q121u+Zli7RR28cM=; b=dpE3RFaxGC2yX2g7QtFyT4MP1J4SEpPTm67DT/BUSSOJJeXrGc9iwGkOymna6/w9uD lLIBtKOpUDSqsi/miR1szIUzurpCjB4jV7rVtVe4gTLBVuAbmc2srBL57cbBW5dVz5Wy 2LstfRmABNveD5zGcn6Rna+1QQq8xqfD8uuCctL5tkHR0yCqBdyh8gqj3OI5VWRMoXMr HEju8amylItNdnUR8tZtFpc3BJ/lfi+REgf6BdEYyCYn0PRbQg+XIKPOcsoSnljyC3js HbDZ3DlGcYOmBx7lu8ovKuDJjXc5E2UxG7WzJuWyWi6O8nCKdymnpgiPrYQMxKbuFhyT rK4w== 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; bh=fZq9/Aaey+SN0l5GZyRu+H8Ix+9Q121u+Zli7RR28cM=; b=RimOKO9K72JPgUjwoe5h3dzjGnQhikD40ge8Osq3yhpRIaIBI3t1atywQOanhoZaew I8yrj1On4ONJNfAvXllwWWPdjD69oZcyhDjXN2GKGY7RjgOnA98fLdyruSMOMGJQR0Vj /h1pXG0lL5T6WC0f5kWw6OPyOseHqKJ0MYACz3d+0SRZ/AV4DzD6jRVtFagRV+Zzh9Js //+1EBOEPSef7yZvKWgv9PBASq+CGSno11dGQqD+AyFHw7iO3pWoaZYHaYPHtEZSrok8 dKO61za5i61sdDAgHk7WqRUz34mdxqpEJaj2tE9hQzaoERp0EnJc81EjDCtvt3C4M1Fx Dx8A== X-Gm-Message-State: APjAAAWRYUIK7vQedyKbJFJYk/2FY66l63WSB9+CD+u+zRsTF6j9Bbqf 69ZQ+R5a1Sbkl0fxRZ2BgyY4GOPBAIobvteLRohrQg== X-Received: by 2002:ac2:561b:: with SMTP id v27mr21936445lfd.186.1572972002286; Tue, 05 Nov 2019 08:40:02 -0800 (PST) MIME-Version: 1.0 References: <1572967777-8812-1-git-send-email-rppt@linux.ibm.com> <1572967777-8812-2-git-send-email-rppt@linux.ibm.com> <20191105163316.GI30717@redhat.com> In-Reply-To: <20191105163316.GI30717@redhat.com> From: Daniel Colascione Date: Tue, 5 Nov 2019 08:39:26 -0800 Message-ID: Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK To: Andrea Arcangeli Cc: 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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 5, 2019 at 8:33 AM Andrea Arcangeli wrote: > > On Tue, Nov 05, 2019 at 08:06:49AM -0800, Daniel Colascione wrote: > > Sure, but the same argument applies to all the other permission checks > > that we do at open time, not at ioctl time. For better or for worse, > > the DAC-ish model used in most places is that access checks happen at > > file object creation time and anyone who has the FD can perform those > > operations later. Confusing the model by doing *some* permission > > checks at open time and *some* permission checks at usage time makes > > the system harder to understand. > > The only case that requires change is if userland requested the > UFFD_FEATURE_EVENT_FORK feature (which AFIK only CRIU does) and that > request is done in the UFFDIO_API call not during the syscall. > > Doing the check in the syscall would then break all non privileged > users like if we'd set /proc/sys/vm/unprivileged_userfaultfd to > zero. 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.