Kernel-hardening Archive on lore.kernel.org
 help / color / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Jeff Vander Stoep <jeffv@google.com>,
	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>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open
Date: Tue, 2 Aug 2016 12:04:34 -0700
Message-ID: <CAGXu5j+q4qWFspRCPEd5-MM05Sh_r6VYSQhP7gcAuRMygeZwjg@mail.gmail.com> (raw)
In-Reply-To: <20160802095243.GD6862@twins.programming.kicks-ass.net>

On Tue, Aug 2, 2016 at 2:52 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 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.
>
> We have bugs we fix them, we don't kill complete infrastructure because
> of them.

I understand that point of view, but it isn't what things look like
for the average end-user of Linux. The lifetime on bugs is very long,
even in upstream (see both Jon Corbet and my talks about this: an
average of 5 years from introduction to fix), and gets drawn out even
further by vendors with slow (or missing) update processes. Being able
to remove attack surface is a fundamental first step of security
defense, and things like perf, user namespaces, and similar APIs,
expose a lot of attack surface when they are enabled. And the evidence
for this attack surface being a real-world risk is in the history of
security vulnerabilities (that we know about!) in these various APIs.

Now, obviously, these API have huge value, otherwise they wouldn't
exist in the first place, and they wouldn't be built into end-user
kernels if they were universally undesirable. But that's not the
situation: the APIs are needed, but they lack the appropriate knobs to
control their availability. And this isn't just about Android: regular
distro kernels (like Debian, who also uses this patch) tend to build
in everything so people can use whatever they want. But for admins
that want to reduce their systems' attack surface, there needs to be
ways to disable things like this.

>> 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].
>
> So the problem I have with this is that it will completely inhibit
> development of things like JITs that self-profile to re-compile
> frequently used code.

This is a good example of a use-case where this knob would be turned
down. But for many many other use-cases, when presented with a
pre-built kernel, there isn't a way to remove the attack surface.

> I would much rather have an LSM hook where the security stuff can do
> more fine grained control of things. Allowing some apps perf usage while
> denying others.

I'm not against an LSM, but I think it's needless complexity when
there is already a knob for this but it just doesn't go "high" enough.
:)

-Kees

-- 
Kees Cook
Brillo & Chrome OS Security

  parent reply index

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 14:45 [kernel-hardening] " 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 [this message]
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
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=CAGXu5j+q4qWFspRCPEd5-MM05Sh_r6VYSQhP7gcAuRMygeZwjg@mail.gmail.com \
    --to=keescook@chromium.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=ebiederm@xmission.com \
    --cc=jeffv@google.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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