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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ