From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967297AbcAZS16 (ORCPT ); Tue, 26 Jan 2016 13:27:58 -0500 Received: from mail-lb0-f175.google.com ([209.85.217.175]:34871 "EHLO mail-lb0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965748AbcAZS1w (ORCPT ); Tue, 26 Jan 2016 13:27:52 -0500 MIME-Version: 1.0 In-Reply-To: <56A7B664.6070509@gmail.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> <56A7B664.6070509@gmail.com> From: Andy Lutomirski Date: Tue, 26 Jan 2016 10:27:31 -0800 Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled To: "Austin S. Hemmelgarn" Cc: Serge Hallyn , "kernel-hardening@lists.openwall.com" , "Eric W. Biederman" , Kees Cook , Andrew Morton , Al Viro , Richard Weinberger , =?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?= , Dmitry Vyukov , David Howells , Miklos Szeredi , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn wrote: > 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. seccomp handles this issue quite nicely. > > 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. > Au contraire. If they have user ns access, then can sandbox their own programs. --Andy