From: Rick Edgecombe <rick.p.edgecombe@intel.com>
To: kernel-hardening@lists.openwall.com, daniel@iogearbox.net,
keescook@chromium.org, catalin.marinas@arm.com,
will.deacon@arm.com, davem@davemloft.net, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, x86@kernel.org, arnd@arndb.de,
jeyu@kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
linux-s390@vger.kernel.org, sparclinux@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org,
jannh@google.com
Cc: kristen@linux.intel.com, dave.hansen@intel.com,
arjan@linux.intel.com, deneen.t.dock@intel.com,
Rick Edgecombe <rick.p.edgecombe@intel.com>
Subject: [PATCH RFC v3 0/3] Rlimit for module space
Date: Fri, 19 Oct 2018 13:47:20 -0700 [thread overview]
Message-ID: <20181019204723.3903-1-rick.p.edgecombe@intel.com> (raw)
If BPF JIT is on, there is no effective limit to prevent filling the entire
module space with JITed e/BPF filters. For classic BPF filters attached with
setsockopt SO_ATTACH_FILTER, there is no memlock rlimit check to limit the
number of insertions like there is for the bpf syscall.
This patch adds a per user rlimit for module space, as well as a system wide
limit for BPF JIT. In a previously reviewed patchset, Jann Horn pointed out the
problem that in some cases a user can get access to 65536 UIDs, so the effective
limit cannot be set low enough to stop an attacker and be useful for the general
case. A discussed alternative solution was a system wide limit for BPF JIT
filters. This much more simply resolves the problem of exhaustion and
de-randomizing in the case of non-CONFIG_BPF_JIT_ALWAYS_ON. If
CONFIG_BPF_JIT_ALWAYS_ON is on however, BPF insertions will fail if another user
exhausts the BPF JIT limit. In this case a per user limit is still needed. If
the subuid facility is disabled for normal users, this should still be ok
because the higher limit will not be able to be worked around that way.
The new BPF JIT limit can be set like this:
echo 5000000 > /proc/sys/net/core/bpf_jit_limit
So I *think* this patchset should resolve that issue except for the
configuration of CONFIG_BPF_JIT_ALWAYS_ON and subuid allowed for normal users.
Better module space KASLR is another way to resolve the de-randomizing issue,
and so then you would just be left with the BPF DOS in that configuration.
Jann also pointed out how, with purposely fragmenting the module space, you
could make the effective module space blockage area much larger. This is also
somewhat un-resolved. The impact would depend on how big of a space you are
trying to allocate. The limit has been lowered on x86_64 so that at least
typical sized BPF filters cannot be blocked.
If anyone with more experience with subuid/user namespaces has any suggestions
I'd be glad to hear. On an Ubuntu machine it didn't seem like a un-privileged
user could do this. I am going to keep working on this and see if I can find a
better solution.
Changes since v2:
- System wide BPF JIT limit (discussion with Jann Horn)
- Holding reference to user correctly (Jann)
- Having arch versions of modulde_alloc (Dave Hansen, Jessica Yu)
- Shrinking of default limits, to help prevent the limit being worked around
with fragmentation (Jann)
Changes since v1:
- Plug in for non-x86
- Arch specific default values
Rick Edgecombe (3):
modules: Create arch versions of module alloc/free
modules: Create rlimit for module space
bpf: Add system wide BPF JIT limit
arch/arm/kernel/module.c | 2 +-
arch/arm64/kernel/module.c | 2 +-
arch/mips/kernel/module.c | 2 +-
arch/nds32/kernel/module.c | 2 +-
arch/nios2/kernel/module.c | 4 +-
arch/parisc/kernel/module.c | 2 +-
arch/s390/kernel/module.c | 2 +-
arch/sparc/kernel/module.c | 2 +-
arch/unicore32/kernel/module.c | 2 +-
arch/x86/include/asm/pgtable_32_types.h | 3 +
arch/x86/include/asm/pgtable_64_types.h | 2 +
arch/x86/kernel/module.c | 2 +-
fs/proc/base.c | 1 +
include/asm-generic/resource.h | 8 ++
include/linux/bpf.h | 7 ++
include/linux/filter.h | 1 +
include/linux/sched/user.h | 4 +
include/uapi/asm-generic/resource.h | 3 +-
kernel/bpf/core.c | 22 +++-
kernel/bpf/inode.c | 16 +++
kernel/module.c | 152 +++++++++++++++++++++++-
net/core/sysctl_net_core.c | 7 ++
22 files changed, 233 insertions(+), 15 deletions(-)
--
2.17.1
next reply other threads:[~2018-10-19 20:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 20:47 Rick Edgecombe [this message]
2018-10-19 20:47 ` [PATCH v3 1/3] modules: Create arch versions of module alloc/free Rick Edgecombe
2018-10-19 20:47 ` [PATCH v3 2/3] modules: Create rlimit for module space Rick Edgecombe
2018-10-19 20:47 ` [PATCH v3 3/3] bpf: Add system wide BPF JIT limit Rick Edgecombe
2018-10-20 17:20 ` [PATCH RFC v3 0/3] Rlimit for module space Ard Biesheuvel
2018-10-22 23:06 ` Edgecombe, Rick P
2018-10-23 11:54 ` Ard Biesheuvel
2018-10-24 15:07 ` Jessica Yu
2018-10-24 16:04 ` Daniel Borkmann
2018-10-25 1:01 ` Edgecombe, Rick P
2018-10-25 14:18 ` Michal Hocko
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181019204723.3903-1-rick.p.edgecombe@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=arjan@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@intel.com \
--cc=davem@davemloft.net \
--cc=deneen.t.dock@intel.com \
--cc=jannh@google.com \
--cc=jeyu@kernel.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kristen@linux.intel.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-s390@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).