[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1466211114.849.66.camel@gmail.com>
Date: Fri, 17 Jun 2016 20:51:54 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc: kernel-hardening@...ts.openwall.com, Kees Cook <keescook@...omium.org>,
Ingo Molnar <mingo@...nel.org>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, linux-doc@...r.kernel.org, Jiri Olsa
<jolsa@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Namhyung Kim
<namhyung@...nel.org>, David Ahern <dsahern@...il.com>, LKML
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] security,perf: Allow further
restriction of perf_event_open
On Fri, 2016-06-17 at 17:00 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jun 17, 2016 at 12:16:47PM -0400, Daniel Micay escreveu:
> > On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote:
> > > This Changelog is completely devoid of information. _WHY_ are you
> > > doing this?
>
> > Attack surface reduction. It's possible to use seccomp-bpf for some
> > limited cases, but it's not flexible enough. There are lots of
> > information leaks and local privilege escalation vulnerabilities via
> > perf events, yet on most Linux installs it's not ever being used. So
> > turning it off by default on those installs is an easy win. The
> > holes
> > are reduced to root -> kernel (and that's not a meaningful boundary
> > in
> > mainline right now - although as is the case here, Debian has a
> > bunch of
> > securelevel patches for that).
>
> Is ptrace also disabled on such systems, or any of the other more
> recent
> syscalls? The same arguments could probably be used to disable those:
> reduce attack surface, possibly the new ones have bugs as they are
> relatively new and it takes a long time for new syscalls to be more
> generally used, if we go on disabling them in such a way, they will
> probably never get used :-\
ptrace is allowed for third party apps within their SELinux domain, but
they all run as different users (so the kernel attack surface is there).
It's now disabled for privileged platform apps and most other domains. A
bit backwards, but removing it for third party apps would break
compatibility so it would have to be done at an API level bump. At
least, without deciding it is worth the cost like hidepid=2 in Android N
(which exposes no mechanism for exceptions in 3rd party apps, only the
base system).
If seccomp-bpf didn't imply such high system call overhead outside of
x86_64, Android would probably be walling off some new system calls. It
needs 2-phase lookup similar to x86 on ARM. Android kernels do avoid
enabling lots of kernel functionality from System V IPC to USERNS
though. New features wouldn't end up enabled if they were behind config
options without an explicit choice.
> Wouldn't the recent bump in perf_event_paranoid to 2 enough? I.e. only
> allow profiling of user tasks?
Most of the vulnerabilities are still exposed at 2. That prevents
leaking information about the kernel WITHOUT vulnerabilities though, and
would be an improvement when perf is disabled - but that doesn't really
matter much (Android kernel debugging and profiling would also still
work with 2).
> Or is there something more specific that we should disable/constrain
> to
> reduce such surface contact without using such a big hammer?
It's desired to have it globally disabled by default. Could use seccomp-
bpf to globally disable it, but that's a bigger hammer because it can't
be globally turned off without a reboot (could only profile newly
spawned processes after disabling it). Since it's only going to be
enabled by developers, trying to make it more fine-grained wouldn't
really pay off.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
