Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <firstname.lastname@example.org>
To: Nick Kralevich <email@example.com>
Cc: Lokesh Gidra <firstname.lastname@example.org>,
Jeffrey Vander Stoep <email@example.com>,
Andrea Arcangeli <firstname.lastname@example.org>,
Suren Baghdasaryan <email@example.com>,
Kees Cook <firstname.lastname@example.org>,
Daniel Colascione <email@example.com>,
Jonathan Corbet <firstname.lastname@example.org>,
Alexander Viro <email@example.com>,
Luis Chamberlain <firstname.lastname@example.org>,
Iurii Zaikin <email@example.com>,
Mauro Carvalho Chehab <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Andy Shevchenko <firstname.lastname@example.org>,
Vlastimil Babka <email@example.com>,
Mel Gorman <firstname.lastname@example.org>,
Sebastian Andrzej Siewior <email@example.com>,
Peter Xu <firstname.lastname@example.org>, Mike Rapoport <email@example.com>,
Jerome Glisse <firstname.lastname@example.org>, Shaohua Li <email@example.com>,
firstname.lastname@example.org, LKML <email@example.com>,
Linux FS Devel <firstname.lastname@example.org>,
Tim Murray <email@example.com>,
Minchan Kim <firstname.lastname@example.org>,
Sandeep Patil <email@example.com>,
firstname.lastname@example.org, Daniel Colascione <email@example.com>,
Kalesh Singh <firstname.lastname@example.org>
Subject: Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only
Date: Fri, 24 Jul 2020 09:40:07 -0400 [thread overview]
Message-ID: <email@example.com> (raw)
On Thu, Jul 23, 2020 at 05:13:28PM -0700, Nick Kralevich wrote:
> On Thu, Jul 23, 2020 at 10:30 AM Lokesh Gidra <firstname.lastname@example.org> wrote:
> > From the discussion so far it seems that there is a consensus that
> > patch 1/2 in this series should be upstreamed in any case. Is there
> > anything that is pending on that patch?
> That's my reading of this thread too.
> > > > Unless I'm mistaken that you can already enforce bit 1 of the second
> > > > parameter of the userfaultfd syscall to be set with seccomp-bpf, this
> > > > would be more a question to the Android userland team.
> > > >
> > > > The question would be: does it ever happen that a seccomp filter isn't
> > > > already applied to unprivileged software running without
> > > > SYS_CAP_PTRACE capability?
> > >
> > > Yes.
> > >
> > > Android uses selinux as our primary sandboxing mechanism. We do use
> > > seccomp on a few processes, but we have found that it has a
> > > surprisingly high performance cost  on arm64 devices so turning it
> > > on system wide is not a good option.
> > >
> > >  https://lore.kernel.org/linux-security-module/202006011116.3F7109A@keescook/T/#m82ace19539ac595682affabdf652c0ffa5d27dad
> As Jeff mentioned, seccomp is used strategically on Android, but is
> not applied to all processes. It's too expensive and impractical when
> simpler implementations (such as this sysctl) can exist. It's also
> significantly simpler to test a sysctl value for correctness as
> opposed to a seccomp filter.
Given that selinux is already used system-wide on Android, what is wrong
with using selinux to control userfaultfd as opposed to seccomp?
> > > >
> > > >
> > > > If answer is "no" the behavior of the new sysctl in patch 2/2 (in
> > > > subject) should be enforceable with minor changes to the BPF
> > > > assembly. Otherwise it'd require more changes.
> It would be good to understand what these changes are.
> > > > Why exactly is it preferable to enlarge the surface of attack of the
> > > > kernel and take the risk there is a real bug in userfaultfd code (not
> > > > just a facilitation of exploiting some other kernel bug) that leads to
> > > > a privilege escalation, when you still break 99% of userfaultfd users,
> > > > if you set with option "2"?
> I can see your point if you think about the feature as a whole.
> However, distributions (such as Android) have specialized knowledge of
> their security environments, and may not want to support the typical
> usages of userfaultfd. For such distributions, providing a mechanism
> to prevent userfaultfd from being useful as an exploit primitive,
> while still allowing the very limited use of userfaultfd for userspace
> faults only, is desirable. Distributions shouldn't be forced into
> supporting 100% of the use cases envisioned by userfaultfd when their
> needs may be more specialized, and this sysctl knob empowers
> distributions to make this choice for themselves.
> > > > Is the system owner really going to purely run on his systems CRIU
> > > > postcopy live migration (which already runs with CAP_SYS_PTRACE) and
> > > > nothing else that could break?
> This is a great example of a capability which a distribution may not
> want to support, due to distribution specific security policies.
> > > >
> > > > Option "2" to me looks with a single possible user, and incidentally
> > > > this single user can already enforce model "2" by only tweaking its
> > > > seccomp-bpf filters without applying 2/2. It'd be a bug if android
> > > > apps runs unprotected by seccomp regardless of 2/2.
> Can you elaborate on what bug is present by processes being
> unprotected by seccomp?
> Seccomp cannot be universally applied on Android due to previously
> mentioned performance concerns. Seccomp is used in Android primarily
> as a tool to enforce the list of allowed syscalls, so that such
> syscalls can be audited before being included as part of the Android
> -- Nick
> Nick Kralevich | email@example.com
next prev parent reply other threads:[~2020-07-24 13:40 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 0:26 [PATCH 0/2] Control over userfaultfd kernel-fault handling Daniel Colascione
2020-04-23 0:26 ` [PATCH 1/2] Add UFFD_USER_MODE_ONLY Daniel Colascione
2020-07-24 14:28 ` Michael S. Tsirkin
2020-07-24 14:46 ` Lokesh Gidra
2020-07-26 10:09 ` Michael S. Tsirkin
2020-04-23 0:26 ` [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only Daniel Colascione
2020-05-06 19:38 ` Peter Xu
2020-05-07 19:15 ` Jonathan Corbet
2020-05-20 4:06 ` Andrea Arcangeli
2020-05-08 16:52 ` Michael S. Tsirkin
2020-05-08 16:54 ` Michael S. Tsirkin
2020-05-20 4:59 ` Andrea Arcangeli
2020-05-20 18:03 ` Kees Cook
2020-05-20 19:48 ` Andrea Arcangeli
2020-05-20 19:51 ` Andrea Arcangeli
2020-05-20 20:17 ` Lokesh Gidra
2020-05-20 21:16 ` Andrea Arcangeli
2020-07-17 12:57 ` Jeffrey Vander Stoep
2020-07-23 17:30 ` Lokesh Gidra
2020-07-24 0:13 ` Nick Kralevich
2020-07-24 13:40 ` Michael S. Tsirkin [this message]
2020-08-06 0:43 ` Nick Kralevich
2020-08-06 5:44 ` Michael S. Tsirkin
2020-08-17 22:11 ` Lokesh Gidra
2020-09-04 3:34 ` Andrea Arcangeli
2020-09-05 0:36 ` Lokesh Gidra
2020-09-19 18:14 ` Nick Kralevich
2020-07-24 14:01 ` [PATCH 0/2] Control over userfaultfd kernel-fault handling Michael S. Tsirkin
2020-07-24 14:41 ` Lokesh Gidra
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [PATCH 2/2] Add a new sysctl knob: unprivileged_userfaultfd_user_mode_only' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).