Kernel-hardening Archive on lore.kernel.org
 help / color / Atom feed
From: Daniel Micay <danielmicay@gmail.com>
To: kernel-hardening@lists.openwall.com, Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Jeff Vander Stoep <jeffv@google.com>
Subject: Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open
Date: Tue, 18 Oct 2016 17:15:01 -0400
Message-ID: <1476825301.4032.7.camel@gmail.com> (raw)
In-Reply-To: <CAGXu5jLnjWV5i3-6+wE2ME0fr4QcMsvtwQ2Q2AZNurxrxKBfRA@mail.gmail.com>


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

On Tue, 2016-10-18 at 13:48 -0700, Kees Cook wrote:
> On Mon, Oct 17, 2016 at 6:44 AM, Mark Rutland <mark.rutland@arm.com>
> wrote:
> > Hi,
> > 
> > Attempt to revive discussions below...
> > 
> > On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote:
> > > When kernel.perf_event_paranoid is set to 3 (or greater), disallow
> > > all access to performance events by users without CAP_SYS_ADMIN.
> > > 
> > > This new level of restriction is intended to reduce the attack
> > > surface of the kernel. Perf is a valuable tool for developers but
> > > is generally unnecessary and unused on production systems. Perf
> > > may
> > > open up an attack vector to vulnerable device-specific drivers as
> > > recently demonstrated in CVE-2016-0805, CVE-2016-0819,
> > > CVE-2016-0843, CVE-2016-3768, and CVE-2016-3843. This new level of
> > > restriction allows for a safe default to be set on production
> > > systems
> > > while leaving a simple means for developers to grant access [1].
> > > 
> > > This feature is derived from CONFIG_GRKERNSEC_PERF_HARDEN by Brad
> > > Spengler. It is based on a patch by Ben Hutchings [2]. Ben's
> > > patches
> > > have been modified and split up to address on-list feedback.
> > > 
> > > kernel.perf_event_paranoid=3 is the default on both Debian [2] and
> > > Android [3].
> > 
> > While people weren't particularly happy with this global toggle
> > approach, my understanding from face-to-face discussions at LSS2016
> > was
> > that people were happy with a more scoped restriction (e.g. using
> > capabilities or some other access control mechanism), but no-one had
> > the
> > time to work on that.
> > 
> > Does that match everyone's understanding, or am I mistaken?
> 
> That's correct: some kind of finer-grain control would be preferred to
> the maintainer, but no one has had time to work on it. (The =3 sysctl
> setting present in Android, Debian, and Ubuntu satisfies most people.)
> 
> -Kees

It's also worth noting that fine-grained control via a scoped mechanism
would likely only be used to implement *more restrictions* on Android,
not to make the feature less aggressive. It's desirable for perf events
to be disabled by default for non-root across the board on Android. The
part that's imperfect is that when a developer uses a profiling tool,
unprivileged usage is automatically enabled across the board until
reboot. Ideally, it would be enabled only for the scope where it's
needed. It would be very tricky to implement though, especially without
adding friction, and it would only have value for protecting devices
being used for development. It really doesn't seem to be worth the
trouble, especially since it doesn't persist on reboot. It's only a
temporary security hole and only for developer devices.

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

  reply index

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 14:45 Jeff Vander Stoep
2016-07-27 20:43 ` Kees Cook
2016-08-02  9:52 ` [kernel-hardening] " Peter Zijlstra
2016-08-02 13:04   ` Arnaldo Carvalho de Melo
2016-08-02 13:10     ` Daniel Micay
2016-08-02 13:16   ` Daniel Micay
2016-08-02 19:04   ` Kees Cook
2016-08-02 20:30     ` Peter Zijlstra
2016-08-02 20:51       ` Kees Cook
2016-08-02 21:06         ` Jeffrey Vander Stoep
2016-08-03  8:28         ` Ingo Molnar
2016-08-03 12:28           ` Daniel Micay
2016-08-03 12:53             ` Daniel Micay
2016-08-03 13:36             ` Peter Zijlstra
2016-08-03 14:41         ` Peter Zijlstra
2016-08-03 15:42           ` Schaufler, Casey
2016-08-03 17:25         ` Eric W. Biederman
2016-08-03 18:53           ` Kees Cook
2016-08-03 21:44             ` Peter Zijlstra
2016-08-04  2:50               ` Eric W. Biederman
2016-08-04  9:11                 ` Peter Zijlstra
2016-08-04 15:13                   ` Eric W. Biederman
2016-08-04 15:37                     ` Peter Zijlstra
2016-08-03 19:36           ` Daniel Micay
2016-08-04 10:28             ` Mark Rutland
2016-08-04 13:45               ` Daniel Micay
2016-08-04 14:11                 ` Peter Zijlstra
2016-08-04 15:44                   ` Daniel Micay
2016-08-04 15:55                     ` Peter Zijlstra
2016-08-04 16:10                     ` Mark Rutland
2016-08-04 16:32                       ` Daniel Micay
2016-08-04 17:09                         ` Mark Rutland
2016-08-04 17:36                           ` Daniel Micay
2016-08-02 21:16       ` Jeffrey Vander Stoep
2016-10-17 13:44 ` [kernel-hardening] " Mark Rutland
2016-10-17 14:54   ` Daniel Micay
2016-10-19  9:41     ` Mark Rutland
2016-10-19 15:16       ` Daniel Micay
2016-10-18 20:48   ` Kees Cook
2016-10-18 21:15     ` Daniel Micay [this message]
2016-10-19  9:56       ` Mark Rutland
2016-10-19 10:01       ` Peter Zijlstra
2016-10-19 10:26         ` Arnaldo Carvalho de Melo
2016-10-19 10:40           ` Peter Zijlstra
2016-10-19 15:39           ` Daniel Micay

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=1476825301.4032.7.camel@gmail.com \
    --to=danielmicay@gmail.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=jeffv@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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

Kernel-hardening Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernel-hardening/0 kernel-hardening/git/0.git

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

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.openwall.lists.kernel-hardening


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