Kernel-hardening Archive on lore.kernel.org
 help / color / Atom feed
From: "Schaufler, Casey" <casey.schaufler@intel.com>
To: "kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	Kees Cook <keescook@chromium.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>,
	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: Wed, 3 Aug 2016 15:42:16 +0000
Message-ID: <99FC4B6EFCEFD44486C35F4C281DC6731F2B9D38@ORSMSX107.amr.corp.intel.com> (raw)
In-Reply-To: <20160803144116.GG6879@twins.programming.kicks-ass.net>

> -----Original Message-----
> From: Peter Zijlstra [mailto:peterz@infradead.org]
> Sent: Wednesday, August 03, 2016 7:41 AM
> To: Kees Cook <keescook@chromium.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; 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
> 
> On Tue, Aug 02, 2016 at 01:51:47PM -0700, Kees Cook 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.)
> 
> Could something like a new capability bit work?


Yes, it could, but we don't have a real good experience
with the advanced use of capabilities. The big distros and
the "OS"s have yet to adopt them seriously. It's the same
sort of issue, really. The granularity gets to you.

> I'm thinking that applications that have network connections already
> drop all possible capabilities (I know, unlikely to be true, but should
> be true for most stuff I hope). This would disable perf for remote code
> execution exploits, including web-browsers and the lot.
> 
> It would keep perf working for local stuff by default, although
> obviously with pam_cap you can limit this when and where needed.
> 
> For Android this could mean the JVM explicitly dropping the cap for its
> 'children' while retaining the use itself. And this would also keep perf
> working on the ADB shell stuff.
> 
> 
> And, I think this would allow a JIT executable to gain the cap using
> file caps, even when the user using it doesn't have it, which would keep
> things usable even in restricted environments.
> 
> 
> Or am I misunderstanding capabilities -- which is entirely possible.

  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 [this message]
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=99FC4B6EFCEFD44486C35F4C281DC6731F2B9D38@ORSMSX107.amr.corp.intel.com \
    --to=casey.schaufler@intel.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=corbet@lwn.net \
    --cc=ebiederm@xmission.com \
    --cc=jeffv@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    /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