From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933063AbcHCXri (ORCPT ); Wed, 3 Aug 2016 19:47:38 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:52997 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758479AbcHCXrg (ORCPT ); Wed, 3 Aug 2016 19:47:36 -0400 From: ebiederm@xmission.com (Eric W. Biederman) 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 References: <1469630746-32279-1-git-send-email-jeffv@google.com> <20160802095243.GD6862@twins.programming.kicks-ass.net> <20160802203037.GC6879@twins.programming.kicks-ass.net> Date: Wed, 03 Aug 2016 12:25:24 -0500 In-Reply-To: (Kees Cook's message of "Tue, 2 Aug 2016 13:51:47 -0700") Message-ID: <87shulix2z.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bV07j-0004eu-QE;;;mid=<87shulix2z.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18Z6WzGXGMtt635qTu6gC4QLC7kOSEytW0= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa06 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject * 0.0 T_TooManySym_03 6+ unique symbols in subject X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: **;Kees Cook X-Spam-Relay-Country: X-Spam-Timing: total 599 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.1 (0.5%), b_tie_ro: 2.2 (0.4%), parse: 1.24 (0.2%), extract_message_metadata: 20 (3.4%), get_uri_detail_list: 2.6 (0.4%), tests_pri_-1000: 6 (1.1%), tests_pri_-950: 1.17 (0.2%), tests_pri_-900: 0.99 (0.2%), tests_pri_-400: 24 (4.0%), check_bayes: 23 (3.8%), b_tokenize: 7 (1.1%), b_tok_get_all: 8 (1.4%), b_comp_prob: 2.4 (0.4%), b_tok_touch_all: 2.9 (0.5%), b_finish: 0.69 (0.1%), tests_pri_0: 264 (44.0%), check_dkim_signature: 0.47 (0.1%), check_dkim_adsp: 3.0 (0.5%), tests_pri_500: 275 (45.9%), poll_dns_idle: 269 (45.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sigh. Kees we have already had this conversation about user namespaces and apparently you missed the point. As I have said before the problem with a system wide off switch is what happens when you have a single application that needs to use the feature. Without care your system wide protection disappears. That is very brittle design. What I see as much more palatable is a design that allows for features to be turned off in sandboxes. So please if you are going to worry about disabling large swaths of the kernel to reduce the attack surface please come up with designs that are not brittle in allowing users to use a feature nor are they brittle in keeping the feature disabled where you want it disabled. One of the strengths of linux is applications of features the authors of the software had not imagined. Your proposals seem to be trying to put the world a tiny little box where if someone had not imagined and preapproved a use of a feature it should not happen. Let's please avoid implementing totalitarianism to avoid malicious code exploiting bugs in the kernel. I am not interested in that future. Especially when dealing with disabling code to reduce attack surface, when then are no known attacks what we are actually dealing with is a small percentage probability reduction that a malicious attacker will be able to exploit the attack. Remember security is as much about availability as it is about integrity. You keep imagining features that are great big denial of service attacks on legitimate users. Kees Cook writes: > On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra 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. Eric