linux-kernel - Re: [PATCH v3 2/6] userfaultfd: add /dev/userfaultfd for fine grained access control

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: <CAJHvVche7ZKOpO=8PY2frtJ5nHyzo=Yt+qT1OmYg8ZOUujkPfA@mail.gmail.com>
Date:   Tue, 14 Jun 2022 17:55:55 -0700
From:   Axel Rasmussen <axelrasmussen@...gle.com>
To:     Nadav Amit <namit@...are.com>
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>,
        Jonathan Corbet <corbet@....net>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Mike Rapoport <rppt@...nel.org>, 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-doc@...r.kernel.org>,
        linux-fsdevel <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 5:10 PM Nadav Amit <namit@...are.com> wrote:
>
> On Jun 13, 2022, at 3:38 PM, Axel Rasmussen <axelrasmussen@...gle.com> wrote:
>
> > On Mon, Jun 13, 2022 at 3:29 PM Peter Xu <peterx@...hat.com> wrote:
> >> On Mon, Jun 13, 2022 at 02:55:40PM -0700, Andrew Morton wrote:
> >>> On Wed,  1 Jun 2022 14:09:47 -0700 Axel Rasmussen <axelrasmussen@...gle.com> wrote:
> >>>
> >>>> To achieve this, add a /dev/userfaultfd misc device. This device
> >>>> provides an alternative to the userfaultfd(2) syscall for the creation
> >>>> of new userfaultfds. The idea is, any userfaultfds created this way will
> >>>> be able to handle kernel faults, without the caller having any special
> >>>> capabilities. Access to this mechanism is instead restricted using e.g.
> >>>> standard filesystem permissions.
> >>>
> >>> The use of a /dev node isn't pretty.  Why can't this be done by
> >>> tweaking sys_userfaultfd() or by adding a sys_userfaultfd2()?
> >
> > 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.
> >
> > One thing that could potentially make this cleaner is, as one LWN
> > commenter pointed out, we could have open() on /dev/userfaultfd just
> > return a new userfaultfd directly, instead of this multi-step process
> > of open /dev/userfaultfd, NEW ioctl, then you get a userfaultfd. When
> > I wrote this originally it wasn't clear to me how to get that to
> > happen - open() doesn't directly return the result of our custom open
> > function pointer, as far as I can tell - but it could be investigated.
>
> If this direction is pursued, I think that it would be better to set it as
> /proc/[pid]/userfaultfd, which would allow remote monitors (processes) to
> hook into userfaultfd of remote processes. I have a patch for that which
> extends userfaultfd syscall, but /proc/[pid]/userfaultfd may be cleaner.

Hmm, one thing I'm unsure about -

If a process is able to control another process' memory like this,
then this seems like exactly what CAP_SYS_PTRACE is intended to deal
with, right? So I'm not sure this case is directly related to the one
I'm trying to address.

This also seems distinct to me versus the existing way you'd do this,
which is open a userfaultfd and register a shared memory region, and
then fork(). Now you can control your child's memory with userfaultfd.
But, attaching to some other, previously-unrelated process with
/proc/[pid]/userfaultfd seems like a clear case for CAP_SYS_PTRACE.

>