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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1D763C00144 for ; Mon, 1 Aug 2022 17:13:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AC548E0001; Mon, 1 Aug 2022 13:13:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 934D86B0072; Mon, 1 Aug 2022 13:13:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AE0B8E0001; Mon, 1 Aug 2022 13:13:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 64D8D6B0071 for ; Mon, 1 Aug 2022 13:13:51 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1EDA3AB239 for ; Mon, 1 Aug 2022 17:13:51 +0000 (UTC) X-FDA: 79751671062.25.DCE6D21 Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf17.hostedemail.com (Postfix) with ESMTP id AE5B440052 for ; Mon, 1 Aug 2022 17:13:49 +0000 (UTC) Received: by mail-io1-f46.google.com with SMTP id q14so8896643iod.3 for ; Mon, 01 Aug 2022 10:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=RMpq00zmLmRyLkH3ymS8AD8nFPc9nuPS5SpA8DGRQjc=; b=CzbG8jn3lmpWwZNf2DkfRaHkYPFhpnngD3tqdI3rzFaOFYHZNMm6okjhZb6FbHgpBV MvAiCTK6W4xcrO1x5Yjhl019C5+KjcritcRqSFhQaKoMajPDUHQeWFPDkHYMGeRgY8Vu Vlq+9AkYHWni1BvEapZhFKQ5KeDvskzMF4zzTqigIUCnuDP933nMxj/APjQzuu+RArVP gqfUWjMDhjWL2VnCff9414QnqJgVQzUNvnp9EqGeJ9Iz8m8BDzpuJNlFQ+ROha+Bnafo tluUwY6NGaRCfpXGufNKvA0sFeRiZ78FJK3XduIgR/UnkVscDBe9pPntr4MQx346BtAD SBjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=RMpq00zmLmRyLkH3ymS8AD8nFPc9nuPS5SpA8DGRQjc=; b=PsYBwnDOAGN0iGhKv0VzyqSNZgTy/Iaclh5fss0Y7iTPqIM77vc0TvzfQpXT0SK04T gDLuI4TOq2IFOsc0DRcp5aC9l175pyl8zic57ed/GE2lMO6pLgiVg4TGKa29FshXYjO6 v3jGxHojoOLlLPXxFzriAp7Ro+SWf3ho2ac1mtcPTb/w4PYtTgmtS9i7DmFeQJnorPbT qoE8ws3BsenmuQZtUU2rqHtuFBCNuQ86cuA2ik3C7JR3Dat8/wQFs84SGhFeiphlt3V4 vC1WEkzWz93fL7ddVorhrsLxU0ofRg+uITO4Qqw6D69HMgP21xMjRRcBwyVVwIdRT9dn KpWA== X-Gm-Message-State: AJIora+9e19ZdVjf205/gdb9hfFPBIOnn5fI1JXwxxSdHiZ6QAs64/ZN s9X3xQ2ix4O9rWrBAzi3grc8Ud0heucgbEEAZ4I7wA== X-Google-Smtp-Source: AGRyM1us0RojN6/riPQbz3AQEf91WYt9XAWKjIH70t+mubW2Sqp7fsmB2PQ5cQkQI2b+gMYBSBcGhDrF0ZlLMZgjF94= X-Received: by 2002:a05:6602:2f03:b0:678:9c7c:97a5 with SMTP id q3-20020a0566022f0300b006789c7c97a5mr5833295iow.32.1659374028847; Mon, 01 Aug 2022 10:13:48 -0700 (PDT) MIME-Version: 1.0 References: <20220719195628.3415852-1-axelrasmussen@google.com> <7EF50BE4-84EA-4D57-B58C-6697F1B74904@vmware.com> In-Reply-To: <7EF50BE4-84EA-4D57-B58C-6697F1B74904@vmware.com> From: Axel Rasmussen Date: Mon, 1 Aug 2022 10:13:12 -0700 Message-ID: Subject: Re: [PATCH v4 0/5] userfaultfd: add /dev/userfaultfd for fine grained access control To: Nadav Amit Cc: "Schaufler, Casey" , Alexander Viro , Andrew Morton , Dave Hansen , "Dmitry V . Levin" , Gleb Fotengauer-Malinovskiy , Hugh Dickins , Jan Kara , Jonathan Corbet , Mel Gorman , Mike Kravetz , Mike Rapoport , Peter Xu , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , zhangyi , "linux-doc@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kselftest@vger.kernel.org" , Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659374029; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RMpq00zmLmRyLkH3ymS8AD8nFPc9nuPS5SpA8DGRQjc=; b=Kp8wel12/yRJmDa/QBHdIev2TlCqovvgC9qhBB7O3EC47zrJoeBDD91AVkZusYiIVv+yEk VDCls3Nq3j4mRDXoUEzzTnlqMYi7HkTTUSNij0bjcGdedT9OK8N+gTHg2oikV5NjWOXyLZ bevvZkZN4JoJCPZ6QpF8Eqxcgk+svJw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=CzbG8jn3; spf=pass (imf17.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659374029; a=rsa-sha256; cv=none; b=eCbhMIMwSZ/t9O6BFUK/SVqVC7cgeO7n/RgISj9wxofSo+vMK6vVLB5jLIvarZCq8YbjZJ m2amscFA4a+K6gLz9TjVaL2jLQd2fCzvxOtDOZgUn7qtvcKiWstOd148g8EMbxDsOflU3G 8byO33s95DfHFdvZUC4ratrjIcXrKrs= X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=CzbG8jn3; spf=pass (imf17.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: c7oua1qodb3chmp6hm35pafpab8hs15u X-Rspamd-Queue-Id: AE5B440052 X-Rspamd-Server: rspam10 X-HE-Tag: 1659374029-703183 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: I finished up some other work and got around to writing a v5 today, but I ran into a problem with /proc/[pid]/userfaultfd. Files in /proc/[pid]/* are owned by the user/group which started the process, and they don't support being chmod'ed. For the userfaultfd device, I think we want the following semantics: - For UFFDs created via the device, we want to always allow handling kernel mode faults - For security, the device should be owned by root:root by default, so unprivileged users don't have default access to handle kernel faults - But, the system administrator should be able to chown/chmod it, to grant access to handling kernel faults for this process more widely. It could be made to work like that but I think it would involve at least: - Special casing userfaultfd in proc_pid_make_inode - Updating setattr/getattr for /proc/[pid] to meaningfully store and then retrieve uid/gid different from the task's, again probably special cased for userfautlfd since we don't want this behavior for other files It seems to me such a change might raise eyebrows among procfs folks. Before I spend the time to write this up, does this seem like something that would obviously be nack'ed? On Wed, Jul 20, 2022 at 4:21 PM Nadav Amit wrote: > > On Jul 20, 2022, at 4:04 PM, Axel Rasmussen wr= ote: > > > =E2=9A=A0 External Email > > > > On Wed, Jul 20, 2022 at 3:16 PM Schaufler, Casey > > wrote: > >>> -----Original Message----- > >>> From: Axel Rasmussen > >>> Sent: Tuesday, July 19, 2022 12:56 PM > >>> To: Alexander Viro ; Andrew Morton > >>> ; Dave Hansen > >>> ; Dmitry V . Levin ; G= leb > >>> Fotengauer-Malinovskiy ; Hugh Dickins > >>> ; Jan Kara ; Jonathan Corbet > >>> ; Mel Gorman ; Mike > >>> Kravetz ; Mike Rapoport ; > >>> Amit, Nadav ; Peter Xu ; > >>> Shuah Khan ; Suren Baghdasaryan > >>> ; Vlastimil Babka ; zhangyi > >>> > >>> Cc: Axel Rasmussen ; linux- > >>> doc@vger.kernel.org; linux-fsdevel@vger.kernel.org; linux- > >>> kernel@vger.kernel.org; linux-mm@kvack.org; linux- > >>> kselftest@vger.kernel.org > >>> Subject: [PATCH v4 0/5] userfaultfd: add /dev/userfaultfd for fine gr= ained > >>> access control > >> > >> I assume that leaving the LSM mailing list off of the CC is purely > >> accidental. Please, please include us in the next round. > > > > Honestly it just hadn't occurred to me, but I'm more than happy to CC > > it on future revisions. > > > >>> This series is based on torvalds/master. > >>> > >>> The series is split up like so: > >>> - Patch 1 is a simple fixup which we should take in any case (even by= itself). > >>> - Patches 2-6 add the feature, configurable selftest support, and doc= s. > >>> > >>> Why not ...? > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> - Why not /proc/[pid]/userfaultfd? The proposed use case for this is = for one > >>> process to open a userfaultfd which can intercept another process' pa= ge > >>> faults. This seems to me like exactly what CAP_SYS_PTRACE is for, tho= ugh, > >>> so I > >>> think this use case can simply use a syscall without the powers > >>> CAP_SYS_PTRACE > >>> grants being "too much". > >>> > >>> - Why not use a syscall? Access to syscalls is generally controlled b= y > >>> capabilities. We don't have a capability which is used for userfaultf= d access > >>> without also granting more / other permissions as well, and adding a = new > >>> capability was rejected [1]. > >>> > >>> - It's possible a LSM could be used to control access instead. I susp= ect > >>> adding a brand new one just for this would be rejected, > >> > >> You won't know if you don't ask. > > > > Fair enough - I wonder if MM folks (Andrew, Peter, Nadav especially) > > would find that approach more palatable than /proc/[pid]/userfaultfd? > > Would it make sense from our perspective to propose a userfaultfd- or > > MM-specific LSM for controlling access to certain features? > > > > I remember +Andrea saying Red Hat was also interested in some kind of > > access control mechanism like this. Would one or the other approach be > > more convenient for you? > > To reiterate my position - I think that /proc/[pid]/userfaultfd is very > natural and can be easily extended to support cross-process access of > userfaultfd. The necessary access controls are simple in any case. For > cross-process access, they are similar to those that are used for other > /proc/[pid]/X such as pagemap. > > I have little experience with LSM and I do not know how real deployments = use > them. If they are easier to deploy and people prefer them over some > pseudo-file, I cannot argue against them. > >