lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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