From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750914AbcAZFH3 (ORCPT ); Tue, 26 Jan 2016 00:07:29 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:55383 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbcAZFHX (ORCPT ); Tue, 26 Jan 2016 00:07:23 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Kees Cook Cc: Andy Lutomirski , Andrew Morton , Al Viro , Richard Weinberger , Robert =?utf-8?B?xZp3acSZY2tp?= , Dmitry Vyukov , David Howells , Miklos Szeredi , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin , "linux-doc\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "kernel-hardening\@lists.openwall.com" References: <1453502345-30416-1-git-send-email-keescook@chromium.org> <8737tp0zhr.fsf@x220.int.ebiederm.org> <87bn89sbc2.fsf@x220.int.ebiederm.org> Date: Mon, 25 Jan 2016 22:57:32 -0600 In-Reply-To: (Kees Cook's message of "Mon, 25 Jan 2016 14:34:32 -0800") Message-ID: <87zivtj5tv.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-AID: U2FsdGVkX19hJao1P3T2b1R8sIkHOoCjFC8YbCDUVHE= X-SA-Exim-Connect-IP: 97.121.81.63 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 XMNoVowels Alpha-numberic number with no vowels * 0.0 TVD_RCVD_IP Message was received from an IP address * 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 * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.1 XMSolicitRefs_0 Weightloss drug X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Kees Cook X-Spam-Relay-Country: X-Spam-Timing: total 366 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 7 (1.8%), b_tie_ro: 3.5 (1.0%), parse: 1.66 (0.5%), extract_message_metadata: 19 (5.2%), get_uri_detail_list: 3.0 (0.8%), tests_pri_-1000: 8 (2.2%), tests_pri_-950: 1.35 (0.4%), tests_pri_-900: 1.12 (0.3%), tests_pri_-400: 28 (7.5%), check_bayes: 26 (7.1%), b_tokenize: 9 (2.3%), b_tok_get_all: 9 (2.4%), b_comp_prob: 2.8 (0.8%), b_tok_touch_all: 3.3 (0.9%), b_finish: 0.73 (0.2%), tests_pri_0: 290 (79.1%), check_dkim_signature: 0.60 (0.2%), check_dkim_adsp: 3.6 (1.0%), tests_pri_500: 7 (2.0%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -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 Kees Cook writes: > On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman > wrote: >> Kees Cook writes: >>> >>> Well, I don't know about less weird, but it would leave a unneeded >>> hole in the permission checks. >> >> To be clear the current patch has my: >> >> Nacked-by: "Eric W. Biederman" >> >> The code is buggy, and poorly thought through. Your lack of interest in >> fixing the bugs in your patch is distressing. > > I'm not sure where you see me having a "lack of interest". The > existing cap-checking sysctls have a corner-case bug, which is > orthogonal to this change. That certainly doesn't sound like you have any plans to change anything there. >> So broken code, not willing to fix. No. We are not merging this sysctl. > > I think you're jumping to conclusions. :) I think I am the maintainer. What you are proposing is very much something that is only of interst to people who are not using user namespaces. It is fatally flawed as a way to avoid new attack surfaces for people who don't care as the sysctl leaves user namespaces enabled by default. It is fatally flawed as remediation to recommend to people to change if a new user namespace related but is discovered. Any running process that happens to be created while user namespace creation was enabled will continue to exist. Effectively a reboot will be required as part of a mitigation. Many sysadmins will get that wrong. I can't possibly see your sysctl as proposed achieving it's goals. A person has to be entirely too aware of subtlety and nuance to use it effectively. > This feature is already implemented by two distros, and likely wanted > by others. We cannot ignore that. The sysctl default doesn't change > the existing behavior, so this doesn't get in your way at all. Can you > please respond to my earlier email where I rebutted each of your > arguments against it? Just saying "no" and putting words in my mouth > isn't very productive. Calling people who make mistakes insane is not a rebuttal. In security usability matters, and your sysctl has low usability. Further you seem to have missed something crucial in your understanding. As was explained earlier the sysctl was added to ubuntu to allow early adopters to experiment not as a long term way of managing user namespaces. What sounds like a generally useful feature that would cover your use case and many others is a per user limit on the number of user namespaces users may create. Eric