[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 3 Aug 2016 10:28:31 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Jeff Vander Stoep <jeffv@...gle.com>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
LKML <linux-kernel@...r.kernel.org>,
Jonathan Corbet <corbet@....net>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: Re: [PATCH 1/2] security, perf: allow further
restriction of perf_event_open
* Kees Cook <keescook@...omium.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
