Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1456236

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

From Peter Zijlstra <peterz@infradead.org>
Newsgroups linux.kernel
Subject Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open
Date 2016-08-04 11:20 +0200
Message-ID <s2mYN-6W6-27@gated-at.bofh.it> (permalink)
References (4 earlier) <s1OX7-1dt-3@gated-at.bofh.it> <s2a1z-6N7-19@gated-at.bofh.it> <s2a1z-6N7-17@gated-at.bofh.it> <s2cZr-dY-33@gated-at.bofh.it> <s2hFL-3m8-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Aug 03, 2016 at 09:50:37PM -0500, Eric W. Biederman wrote:

> 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.

Right, so its basically a 'root' namespace. Not sure how this would
help, or cover the use-cases with perf through.

Do they really only care about the sandbox? I can imagine this being
sufficient for Android as that could do these userns thingies for each
app or whatnot. But does this cover the case Debian disabled perf for?
I'm not sure I've ever seen it described _why_ they did it.

So far I'm still liking the new capability bit better, assuming I
understood those right.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 1/2] security, perf: allow further restriction of perf_event_open Jeff Vander Stoep <jeffv@google.com> - 2016-07-27 16:50 +0200
  Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-07-27 22:50 +0200
  Re: [PATCH 1/2] security, perf: allow further restriction of  perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-02 12:50 +0200
    Re: [PATCH 1/2] security, perf: allow further restriction of  perf_event_open Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-08-02 15:20 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-02 16:20 +0200
    Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-02 15:30 +0200
    Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-08-02 23:00 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Ingo Molnar <mingo@kernel.org> - 2016-08-03 10:30 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-03 14:30 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-03 15:00 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-03 15:40 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-03 16:50 +0200
        RE: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open "Schaufler, Casey" <casey.schaufler@intel.com> - 2016-08-03 17:50 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-08-03 21:30 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 00:40 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ebiederm@xmission.com (Eric W. Biederman) - 2016-08-04 05:40 +0200
            Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 11:20 +0200
              Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ebiederm@xmission.com (Eric W. Biederman) - 2016-08-04 17:30 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 17:40 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-03 22:00 +0200
        Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Mark Rutland <mark.rutland@arm.com> - 2016-08-04 12:40 +0200
          Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 15:50 +0200
            Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 16:20 +0200
              Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 17:50 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-04 18:00 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Mark Rutland <mark.rutland@arm.com> - 2016-08-04 18:20 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 18:40 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Mark Rutland <mark.rutland@arm.com> - 2016-08-04 19:20 +0200
                Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow  further restriction of perf_event_open Daniel Micay <danielmicay@gmail.com> - 2016-08-04 19:40 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open ebiederm@xmission.com (Eric W. Biederman) - 2016-08-04 01:50 +0200
    Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Peter Zijlstra <peterz@infradead.org> - 2016-08-02 23:00 +0200
      Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Jeffrey Vander Stoep <jeffv@google.com> - 2016-08-02 23:20 +0200
    Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further  restriction of perf_event_open Kees Cook <keescook@chromium.org> - 2016-08-02 23:40 +0200

csiph-web