LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Daniel Micay <danielmicay@gmail.com>
To: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
Cc: kernel-hardening@lists.openwall.com,
	Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-doc@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Namhyung Kim <namhyung@kernel.org>,
	David Ahern <dsahern@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open
Date: Fri, 17 Jun 2016 20:51:54 -0400
Message-ID: <1466211114.849.66.camel@gmail.com> (raw)
In-Reply-To: <20160617200050.GL13337@kernel.org>


[-- Attachment #1: Type: text/plain, Size: 3097 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 15:19 [PATCH 0/2] Document and extend kernel.perf_event_paranoid Ben Hutchings
2016-01-11 15:21 ` [PATCH 1/2] Documentation,perf: Document the perf sysctls Ben Hutchings
2016-01-11 15:23 ` [PATCH 2/2] security,perf: Allow further restriction of perf_event_open Ben Hutchings
2016-04-13 16:12   ` [kernel-hardening] " Kees Cook
2016-06-04 20:56     ` Jeffrey Vander Stoep
     [not found]     ` <CABXk95BE3wpgq-Y08G+Z3ZJbxJwgiuVvtQGaV4n-tD6GKNiFKg@mail.gmail.com>
2016-06-16 22:27       ` Kees Cook
2016-06-17  6:54         ` Peter Zijlstra
2016-06-17 16:16           ` Daniel Micay
2016-06-17 20:00             ` Arnaldo Carvalho de Melo
2016-06-18  0:51               ` Daniel Micay [this message]
2016-06-17  5:56   ` Alexander Shishkin
2016-06-17 12:18     ` Ben Hutchings
2016-06-17 15:24     ` [kernel-hardening] " Daniel Micay
2016-01-19 21:35 ` [PATCH RESEND] perf: Document the perf sysctls Ben Hutchings
2016-01-21 14:25   ` Arnaldo Carvalho de Melo
2016-02-03 10:08   ` [tip:perf/core] perf tools: " tip-bot for Ben Hutchings

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=1466211114.849.66.camel@gmail.com \
    --to=danielmicay@gmail.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=arnaldo.melo@gmail.com \
    --cc=dsahern@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=tglx@linutronix.de \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git