From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934559AbcAZSK3 (ORCPT ); Tue, 26 Jan 2016 13:10:29 -0500 Received: from mail-ig0-f196.google.com ([209.85.213.196]:34800 "EHLO mail-ig0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932586AbcAZSK0 (ORCPT ); Tue, 26 Jan 2016 13:10:26 -0500 Subject: Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled To: Serge Hallyn , 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> <87zivtj5tv.fsf@x220.int.ebiederm.org> <20160126171523.GA13715@ubuntumail> Cc: "Eric W. Biederman" , Kees Cook , Andy Lutomirski , Andrew Morton , Al Viro , Richard Weinberger , =?UTF-8?Q?Robert_=c5=9awi=c4=99cki?= , Dmitry Vyukov , David Howells , Miklos Szeredi , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" From: "Austin S. Hemmelgarn" Message-ID: <56A7B664.6070509@gmail.com> Date: Tue, 26 Jan 2016 13:09:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160126171523.GA13715@ubuntumail> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 160126-1, 2016-01-26), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016-01-26 12:15, Serge Hallyn wrote: > Quoting Josh Boyer (jwboyer@fedoraproject.org): >> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman >> wrote: >>> 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. >> >> What you're saying is true for the "oh crap" case of a new userns >> related CVE being found. However, there is the case where sysadmins >> know for a fact that a set of machines should not allow user >> namespaces to be enabled. Currently they have 2 choices, 1) use their > > Hi - can you give a specific example of this? (Where users really should > not be able to use them - not where they might not need them) I think > it'll help the discussion tremendously. Because so far the only good > arguments I've seen have been about actual bugs in the user namespaces, > which would not warrant a designed-in permanent disable switch. If > there are good use cases where such a disable switch will always be > needed (and compiling out can't satisfy) that'd be helpful. In general, if a particular daemon provides a network service and does not use user namespaces for sand-boxing, it should not be allowed to use user namespaces, because those then become something else to potentially land an exploit through. ntpd, postfix, and most other regularly used network servers fall into this category. If you're hosting a shared system providing terminal server like usage where the users actually have shell access, then they probably should not be able to use user namespaces on the server. In essence, if there are cases where you know for certain that users do not need user namespaces, they should not be allowed to use them.