Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1455691
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open |
| Date | 2016-08-03 10:30 +0200 |
| Message-ID | <s1ZIR-8a-5@gated-at.bofh.it> (permalink) |
| References | <rZyjM-F9-13@gated-at.bofh.it> <s1FqO-3dN-11@gated-at.bofh.it> <s1OX7-1dt-5@gated-at.bofh.it> <s1OX7-1dt-7@gated-at.bofh.it> <s1OX7-1dt-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
* Kees Cook <keescook@chromium.org> wrote: > > I see 0 up-sides of this approach and, as per the above, a whole bunch of very > > serious downsides. > > > > A global (esp. default inhibited) knob is too coarse and limiting. > > I haven't suggested it be default inhibit in the upstream Kconfig. And > having this knob already with the 0, 1, and 2 settings seems > incomplete to me without this highest level of restriction that 3 > would provide. That seems rather arbitrary to me. :) The default has no impact on the "it's too coarse and limiting" negative property of this patch, which is the show-stopper aspect. Please fix that aspect instead of trying to argue around it. This isn't some narrow debugging mechanism we can turn on/off globally and forget about, this is a wide scope performance measurement and event logging infrastructure that is being utilized not just by developers but by apps and runtimes as well. > 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.) Because in practice what will happen is that if the only option is to do something drastic for sekjurity, IT departments will do it - while if there's a more flexible mechanism that does not throw out the baby with the bath water that is going to be used. This is as if 20 years ago you had submitted a patch to the early Linux TCP/IP networking code to be on/off via a global sysctl switch and told people that "in developer mode you can have networking, talk to your admin". We'd have told you: "this switch is too coarse and limiting, please implement something better, like a list of routes which defines which IP ranges are accessible, and a privileged range of listen sockets ports and some flexible kernel side filtering mechanism to inhibit outgoing/incoming connections". Global sysctls are way too coarse. Thanks, Ingo
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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