Kernel-hardening Archive on lore.kernel.org
 help / color / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kees Cook <keescook@chromium.org>,
	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>
Subject: Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open
Date: Wed, 03 Aug 2016 21:50:37 -0500
Message-ID: <87fuqldz7m.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20160803214437.GI6879@twins.programming.kicks-ass.net> (Peter Zijlstra's message of "Wed, 3 Aug 2016 23:44:37 +0200")

Peter Zijlstra <peterz@infradead.org> writes:

> On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote:
>> > Kees Cook <keescook@chromium.org> writes:
>> >
>> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra <peterz@infradead.org> 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?
>
> Someone would have to educate me on what a userns is and how that would
> help here.

userns is an abbreviation for user namespace.

How it might help is that it is an easy unescapable context for
processes.  Essentialy the idea is to limit the scope of the sysctl to a
container.

User namespaces run into flack because while tremendously simple in
themselves the code takes advantage of the fact that suid root
executables in a user namespace do not have privileges on anything
outside of the user namespace.  Which means that it is semantically safe
to allow operations like creating mount namespaces, mount filesystems,
creating network namespaces, manipulating the network stack etc.  All of
which allows unprivileged users (that can create network namespaces) to
exercise more kernel code and exercise those bugs.

Fundamentally user namespaces as objects you can create need limits on
the maximum number of user namespaces you can create to cawtch run away
processes.  Set the limit you can create to 0 and you get what Kees
wants.

In my pending patches that were not quite ready for the merge window, I
added a sysctl that described the maximum number of user namepaces that
could be created (default value threads-max), and implemented the sysctl
in a per user way.  Such that counts and limits were kept for every user
namespace.  In a nested user namespace (which are all of them except for
the initial user namspace) the count and limit would be checked in the
current user namepsace, then the count would be incremented in the parent
and verified the count was below the limit in the parent user namespace.

What this means in practice is user namespaces can be enabled by default
on a system, and yet you can easily disable them in a sandbox that was
built with a user namespace.

I named the new sysctls in my patch:
/proc/sys/userns/max_user_namespaces
/proc/sys/userns/max_pid_namespaces
/proc/sys/userns/max_net_namespaces
/proc/sys/userns/max_uts_namespaces
/proc/sys/userns/max_ipc_namespaces
/proc/sys/userns/max_cgroup_namespaces
/proc/sys/userns/max_mnt_namespaces

What Kees was suggesting was to add a similar sysctl say:
/proc/sys/userns/perf_event_enabled

And have the ability to disable perf events in each user namespaces.
While still being able to leave usage perf events enabled by default.

I don't know if any of that is a good fit for perf events.

For purposes of this discussion I assume we are limiting ourselves to
discussing userspace tracing, which semantically is 100% fine for
access by userspace.

Eric

  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
2016-08-03 21:44             ` Peter Zijlstra
2016-08-04  2:50               ` Eric W. Biederman [this message]
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=87fuqldz7m.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=corbet@lwn.net \
    --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 \
    --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