From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757038AbcHCI2o (ORCPT ); Wed, 3 Aug 2016 04:28:44 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:36012 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755063AbcHCI2g (ORCPT ); Wed, 3 Aug 2016 04:28:36 -0400 Date: Wed, 3 Aug 2016 10:28:31 +0200 From: Ingo Molnar To: Kees Cook Cc: Peter Zijlstra , Jeff Vander Stoep , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , "linux-doc@vger.kernel.org" , "kernel-hardening@lists.openwall.com" , LKML , Jonathan Corbet , "Eric W. Biederman" Subject: Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open Message-ID: <20160803082830.GA3163@gmail.com> References: <1469630746-32279-1-git-send-email-jeffv@google.com> <20160802095243.GD6862@twins.programming.kicks-ass.net> <20160802203037.GC6879@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Kees Cook 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