[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJHvVcjAnewRATU3AAZK+TFpNbfiVATfd1tt_ok2k+X+3s3dBA@mail.gmail.com>
Date: Tue, 14 Jun 2022 13:23:52 -0700
From: Axel Rasmussen <axelrasmussen@...gle.com>
To: Jonathan Corbet <corbet@....net>
Cc: Peter Xu <peterx@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Charan Teja Reddy <charante@...eaurora.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"Dmitry V . Levin" <ldv@...linux.org>,
Gleb Fotengauer-Malinovskiy <glebfm@...linux.org>,
Hugh Dickins <hughd@...gle.com>, Jan Kara <jack@...e.cz>,
Mel Gorman <mgorman@...hsingularity.net>,
Mike Kravetz <mike.kravetz@...cle.com>,
Mike Rapoport <rppt@...nel.org>, Nadav Amit <namit@...are.com>,
Shuah Khan <shuah@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
zhangyi <yi.zhang@...wei.com>, linux-doc@...r.kernel.org,
linux-fsdevel@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Linuxkselftest <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH v3 2/6] userfaultfd: add /dev/userfaultfd for fine grained
access control
On Mon, Jun 13, 2022 at 4:23 PM Jonathan Corbet <corbet@....net> wrote:
>
> Axel Rasmussen <axelrasmussen@...gle.com> writes:
>
> > I think for any approach involving syscalls, we need to be able to
> > control access to who can call a syscall. Maybe there's another way
> > I'm not aware of, but I think today the only mechanism to do this is
> > capabilities. I proposed adding a CAP_USERFAULTFD for this purpose,
> > but that approach was rejected [1]. So, I'm not sure of another way
> > besides using a device node.
>
> I take it there's a reason why this can't be done with a security module
> - either a custom module or a policy in one of the existing modules?
> That sort of access control is just what security modules are supposed
> to be for, after all.
>
> Thanks,
>
> jon
Admittedly I haven't tried proposing a patch, but I suspect there
would be pushback against adding an entirely new LSM just for this
case, similarly to the reasons the CAP_USERFAULTFD approach was
rejected.
For existing LSMs, I think SELinux can be used to restrict access to
syscalls. But then again, it's fairly heavy weight / difficult to
configure, and I suspect migrating production servers which don't use
it today would be a nontrivial undertaking. At least to me it seems
unfortunate to say, there isn't an obvious "safe" way to use
userfaultfd, without enabling + configuring selinux. (That assumes by
"safe" we mean, without granting wider-than necessary access to
userfaultfd, or without granting uffd-using processes more permissions
[root or CAP_SYS_PTRACE] to do their job.) I suspect if we do that
then in practice many? most? users will just either run UFFD programs
as root, or toggle the sysctl to allow unprivileged UFFD usage.
Powered by blists - more mailing lists