Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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
>> <ebiederm@xmission.com> wrote:
>>> Kees Cook <keescook@chromium.org> writes:
>>>
>>>> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
>>>> <ebiederm@xmission.com> wrote:
>>>>> Kees Cook <keescook@chromium.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@xmission.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.

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.