[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56A7BEDA.1060503@gmail.com>
Date: Tue, 26 Jan 2016 13:45:46 -0500
From: "Austin S. Hemmelgarn" <ahferroin7@...il.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Serge Hallyn <serge.hallyn@...ntu.com>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Kees Cook <keescook@...omium.org>, Andrew Morton
<akpm@...ux-foundation.org>, Al Viro <viro@...iv.linux.org.uk>,
Richard Weinberger <richard@....at>, Robert Święcki
<robert@...ecki.net>, Dmitry Vyukov <dvyukov@...gle.com>,
David Howells <dhowells@...hat.com>, Miklos Szeredi <mszeredi@...e.cz>,
Kostya Serebryany <kcc@...gle.com>, Alexander Potapenko <glider@...gle.com>,
Eric Dumazet <edumazet@...gle.com>, Sasha Levin <sasha.levin@...cle.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to
be disabled
On 2016-01-26 13:27, Andy Lutomirski wrote:
> On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
> <ahferroin7@...il.com> wrote:
>> On 2016-01-26 12:15, Serge Hallyn wrote:
>>>
>>> Quoting Josh Boyer (jwboyer@...oraproject.org):
>>>>
>>>> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman
>>>> <ebiederm@...ssion.com> wrote:
>>>>>
>>>>> Kees Cook <keescook@...omium.org> writes:
>>>>>
>>>>>> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
>>>>>> <ebiederm@...ssion.com> wrote:
>>>>>>>
>>>>>>> Kees Cook <keescook@...omium.org> 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" <ebiederm@...ssion.com>
>>>>>>>
>>>>>>> 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.
>
seccomp is a pain to set up given current tooling, and isn't supported
by most server software. Unless there's some tool out there to hook
arbitrary seccomp filters into an arbitrary program, then this isn't an
option for most people.
>>
>> 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.
I should clarify, by 'terminal server like usage' I meant thin client
setups, not Sun Ray or Windows style terminal servers. IOW, a file
server that provides a few extra services (DHCP, TFTP and similar) and
only allows shell access so users can move around their own files
directly on the server.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
