Kernel-hardening Archive on
 help / color / Atom feed
From: Kees Cook <>
To: "Eric W. Biederman" <>
Cc: Peter Zijlstra <>,
	Jeff Vander Stoep <>,
	Ingo Molnar <>,
	Arnaldo Carvalho de Melo <>,
	Alexander Shishkin <>,
	"" <>,
	LKML <>,
	Jonathan Corbet <>
Subject: Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open
Date: Wed, 3 Aug 2016 11:53:41 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Aug 3, 2016 at 10:25 AM, Eric W. Biederman
<> wrote:
> Sigh.
> Kees we have already had this conversation about user namespaces and
> apparently you missed the point.

Well, I didn't miss the point: that's why I CCed you. :) This is
nearly the same discussion (though in this case there is already a
sysctl, hence this thread).

> As I have said before the problem with a system wide off switch is what
> happens when you have a single application that needs to use the
> feature.  Without care your system wide protection disappears.
> That is very brittle design.

Yeah, the use-cases tend to be "never", "always", "this process", and
"this user". The way Android would like to be handling the permission,
though, gets back to another thing we talked about briefly when
discussing userns: revocation. Android wants to turn the entire
permission on and off across the entire system, so things like
capabilities or privileged fds or something don't quite fit that

> What I see as much more palatable is a design that allows for
> features to be turned off in sandboxes.
> So please if you are going to worry about disabling large swaths of
> the kernel to reduce the attack surface please come up with designs
> that are not brittle in allowing users to use a feature nor are they
> brittle in keeping the feature disabled where you want it disabled.

Yup, Linus asked for this too. I haven't come up with anything
particularly great yet. :P

> One of the strengths of linux is applications of features the authors of
> the software had not imagined.  Your proposals seem to be trying to put
> the world a tiny little box where if someone had not imagined and
> preapproved a use of a feature it should not happen.   Let's please
> avoid implementing totalitarianism to avoid malicious code exploiting
> bugs in the kernel.  I am not interested in that future.

To be clear: I'm interested in giving system owners greater control
over what's exposed. That's not about limiting access everywhere. And
I'm interested in making sure that the upstream kernel actually
provides what end-users want. In the most extreme version of this is
when distros carry kernel patches to get it done (this was true with
userns and is true again here with perf). This IS a desired features,
and it exists in the world. I want to avoid the confusion that arises
from people running patched kernels: upstream developers don't realize
what state their features are in when they reach end users,
documentation doesn't match, etc etc.

However, I do accept that the existing mechanisms that have served
Linux over the years (sysctls, capabilities, etc) are woefully
insufficient in many of these cases.

> Especially when dealing with disabling code to reduce attack surface,
> when then are no known attacks what we are actually dealing with
> is a small percentage probability reduction that a malicious attacker
> will be able to exploit the attack.

But there are bugs. We just haven't found them. Based on the past
research by Jon Corbet (and again recently by me) we're sitting on at
least 1 new critical bug that we won't find for the next 5 years (and
we've got at least 1 more each that are on average 1, 2, 3, and 4
years old that we haven't found yet either).

> Remember security is as much about availability as it is about
> integrity.  You keep imagining features that are great big denial of
> service attacks on legitimate users.

That's not my goal: legitimate users should have access. That's up to
system owners. But I'd like to provide ways for system owners to keep
illegitimate users from having access. :)

> Kees Cook <> writes:
>> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra <> wrote:
>> Let me take this another way instead. What would be a better way to
>> provide a mechanism for system owners to disable perf without an LSM?
>> (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as
>> wide a coverage as possible.)
> I vote for sandboxes.  Perhaps seccomp.  Perhaps a per userns sysctl.
> Perhaps something else.

Peter, did you happen to see Eric's solution to this problem for
namespaces? Basically, a per-userns sysctl instead of a global sysctl.
Is that something that would be acceptable here?


Kees Cook
Brillo & Chrome OS Security

  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
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 [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel-hardening Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index kernel-hardening

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone