lkml.org 
[lkml]   [2019]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 0/3] userfaultfd: allow to forbid unprivileged users
    Hi Paolo,

    On Wed, Mar 13, 2019 at 03:12:28PM -0400, Paolo Bonzini wrote:
    >
    > > On Wed, Mar 13, 2019 at 09:22:31AM +0100, Paolo Bonzini wrote:
    > > Unless somebody suggests a consistent way to make hugetlbfs "just
    > > work" (like we could achieve clean with CRIU and KVM), I think Oracle
    > > will need a one liner change in the Oracle setup to echo into that
    > > file in addition of running the hugetlbfs mount.
    >
    > Hi Andrea, can you explain more in detail the risks of enabling
    > userfaultfd for unprivileged users?

    There's no more risk than in allowing mremap (direct memory overwrite
    after underflow) or O_DIRECT (dirtycow) for unprivileged users.

    If there was risk in allowing userfaultfd for unprivileged users,
    CAP_SYS_PTRACE would be mandatory and there wouldn't be an option to
    allow userfaultfd to all unprivileged users.

    This is just an hardening policy in kernel (for those that don't run
    everything under seccomp) that may even be removed later.

    Unlike mremap and O_DIRECT, because we've only an handful of
    (important) applications using userfaultfd so far, we can do like the
    bpf syscall:

    SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, size)
    {
    union bpf_attr attr = {};
    int err;

    if (sysctl_unprivileged_bpf_disabled && !capable(CAP_SYS_ADMIN))
    return -EPERM;

    Except we picked CAP_SYS_PTRACE because CRIU already has to run with
    such capability for other reasons.

    So this is intended as the "sysctl_unprivileged_bpf_disabled" trick
    applied to the bpf syscall, also applied to the userfaultfd syscall,
    nothing more nothing less.

    Then I thought we can add a tristate so an open of /dev/kvm would also
    allow the syscall to make things more user friendly because
    unprivileged containers ideally should have writable mounts done with
    nodev and no matter the privilege they shouldn't ever get an hold on
    the KVM driver (and those who do, like kubevirt, will then just work).

    There has been one complaint because userfaultfd can also be used to
    facilitate exploiting use after free bugs in other kernel code:

    https://cyseclabs.com/blog/linux-kernel-heap-spray

    This isn't a bug in userfaultfd, the only bug there is some kernel
    code doing an use after free in a reproducible place, userfaultfd only
    allows to stop copy-user where the exploits like copy-user to be
    stopped.

    This isn't particularly concerning, because you can achieve the same
    objective with FUSE. In fact even if you set CONFIG_USERFAULTFD=n in
    the kernel config and CONFIG_FUSE_FS=n, a security bug like that can
    still be exploited eventually. It's just less reproducible if you
    can't stop copy-user.

    Restricting userfaultfd to privileged processes, won't make such
    kernel bug become harmless, it'll just require more attempts to
    exploit as far as I can tell. To put things in prospective, the
    exploits for the most serious security bugs like mremap missing
    underflow check, dirtycow or the missing stack_guard_gap would not
    get any facilitation by userfaultfd.

    I also thought we were randomizing all slab heaps by now to avoid
    issues like above, I don't know if the randomized slab freelist oreder
    CONFIG_SLAB_FREELIST_RANDOM and also the pointer with
    CONFIG_SLAB_FREELIST_HARDENED precisely to avoid the exploits like
    above. It's not like you can disable those two options even if you set
    CONFIG_USERFAULTFD=n. I wonder if in that blog post the exploit was
    set on a kernel with those two options enabled.

    In any case not allowing non privileged processes to run the
    userfaultfd syscall will provide some hardening feature also against
    such kind of concern.

    Thanks,
    Andrea

    \
     
     \ /
      Last update: 2019-03-14 00:45    [W:2.044 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site