Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1315327 > unrolled thread

[PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled  Kees Cook <keescook@chromium.org> - 2016-01-22 23:40 +0100
    [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin Kees Cook <keescook@chromium.org> - 2016-01-22 23:40 +0100
      Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin ebiederm@xmission.com (Eric W. Biederman) - 2016-01-23 04:30 +0100
        Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of  proc_dointvec_minmax_sysadmin Jann Horn <jann@thejh.net> - 2016-01-23 23:30 +0100
          Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin ebiederm@xmission.com (Eric W. Biederman) - 2016-01-24 02:40 +0100
            Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of  proc_dointvec_minmax_sysadmin Al Viro <viro@ZenIV.linux.org.uk> - 2016-01-24 02:50 +0100
              Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of  proc_dointvec_minmax_sysadmin Jann Horn <jann@thejh.net> - 2016-01-24 03:00 +0100
                Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin ebiederm@xmission.com (Eric W. Biederman) - 2016-01-24 07:20 +0100
                  Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of  proc_dointvec_minmax_sysadmin Jann Horn <jann@thejh.net> - 2016-01-24 07:40 +0100
                    Re: [kernel-hardening] Re: [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin ebiederm@xmission.com (Eric W. Biederman) - 2016-01-24 08:00 +0100
    Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Richard Weinberger <richard@nod.at> - 2016-01-22 23:50 +0100
    Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled ebiederm@xmission.com (Eric W. Biederman) - 2016-01-23 04:20 +0100
      Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-24 22:00 +0100
        Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER  to be disabled Serge Hallyn <serge.hallyn@ubuntu.com> - 2016-01-26 08:40 +0100
      Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Andy Lutomirski <luto@amacapital.net> - 2016-01-24 23:30 +0100
        Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-25 20:00 +0100
          Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled ebiederm@xmission.com (Eric W. Biederman) - 2016-01-25 21:00 +0100
            Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-25 23:40 +0100
              Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Andy Lutomirski <luto@amacapital.net> - 2016-01-26 00:40 +0100
              Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER  to be disabled Daniel Micay <danielmicay@gmail.com> - 2016-01-26 03:30 +0100
              Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled ebiederm@xmission.com (Eric W. Biederman) - 2016-01-26 06:10 +0100
                Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Josh Boyer <jwboyer@fedoraproject.org> - 2016-01-26 15:40 +0100
                  Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-26 15:50 +0100
                    Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Josh Boyer <jwboyer@fedoraproject.org> - 2016-01-26 16:00 +0100
                      Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER  to be disabled Serge Hallyn <serge.hallyn@ubuntu.com> - 2016-01-26 18:30 +0100
                        Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled Josh Boyer <jwboyer@fedoraproject.org> - 2016-01-26 21:00 +0100
                          Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-26 21:20 +0100
                  Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER  to be disabled Serge Hallyn <serge.hallyn@ubuntu.com> - 2016-01-26 18:20 +0100
                    Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-26 19:20 +0100
                      Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled Andy Lutomirski <luto@amacapital.net> - 2016-01-26 19:30 +0100
                        Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-26 19:50 +0100
                        Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled Kees Cook <keescook@chromium.org> - 2016-01-27 00:20 +0100
                    Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled Kees Cook <keescook@chromium.org> - 2016-01-27 00:20 +0100
                      Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled ebiederm@xmission.com (Eric W. Biederman) - 2016-01-27 11:50 +0100
                        Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to  be disabled "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-27 13:40 +0100
                Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-26 17:40 +0100
        Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-25 20:00 +0100
          Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Andy Lutomirski <luto@amacapital.net> - 2016-01-25 20:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1317539

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.

> 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

[toc] | [prev] | [next] | [standalone]

#1317980

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
distro kernel as-is, which may not meet their goal of having userns
disabled, or 2) rebuild their kernel to disable it, which may
invalidate any support contracts they have.

I tend to agree with you on the lack of value around runtime
mitigation, but allowing an admin to toggle this as a blatant on/off
switch on reboot does have value.

>> 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.

Where that number may be zero?  I don't see how that is really any
better than a sysctl.  Could you elaborate?

josh

[toc] | [prev] | [next] | [standalone]

#1317993

On 2016-01-26 09:38, Josh Boyer wrote:
> 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
> distro kernel as-is, which may not meet their goal of having userns
> disabled, or 2) rebuild their kernel to disable it, which may
> invalidate any support contracts they have.
>
> I tend to agree with you on the lack of value around runtime
> mitigation, but allowing an admin to toggle this as a blatant on/off
> switch on reboot does have value.
>
>>> 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.
>
> Where that number may be zero?  I don't see how that is really any
> better than a sysctl.  Could you elaborate?
It's a better option because it would allow better configurability. 
Take for example a single user desktop system with some network daemons. 
  On such a system, the actual login used for the graphical environment 
by the user should be allowed at least a few user namespaces, because 
some software depends on them for security (Chrome for example, as well 
as some distro's build systems), but system users should be limited to 
at most one if they need it, and ideally zero, so that remote exploits 
couldn't give access to a user namespace.

Conversely, on a server system, it's not unreasonable to completely 
disable user namespaces for almost everything, except for giving one to 
services that use them properly for sand-boxing.

I will state though that I only feel this is a better solution given 
that two criteria are met:
1. You can set 0 as the limit.
2. You can configure this without needing some special software (this in 
particular means that seccomp is not an option).

[toc] | [prev] | [next] | [standalone]

#1318014

On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> wrote:
> On 2016-01-26 09:38, Josh Boyer wrote:
>>
>> 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
>> distro kernel as-is, which may not meet their goal of having userns
>> disabled, or 2) rebuild their kernel to disable it, which may
>> invalidate any support contracts they have.
>>
>> I tend to agree with you on the lack of value around runtime
>> mitigation, but allowing an admin to toggle this as a blatant on/off
>> switch on reboot does have value.
>>
>>>> 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.
>>
>>
>> Where that number may be zero?  I don't see how that is really any
>> better than a sysctl.  Could you elaborate?
>
> It's a better option because it would allow better configurability. Take for
> example a single user desktop system with some network daemons.  On such a
> system, the actual login used for the graphical environment by the user
> should be allowed at least a few user namespaces, because some software
> depends on them for security (Chrome for example, as well as some distro's
> build systems), but system users should be limited to at most one if they
> need it, and ideally zero, so that remote exploits couldn't give access to a
> user namespace.
>
> Conversely, on a server system, it's not unreasonable to completely disable
> user namespaces for almost everything, except for giving one to services
> that use them properly for sand-boxing.

OK, so better granularity.  Fine.

> I will state though that I only feel this is a better solution given that
> two criteria are met:
> 1. You can set 0 as the limit.
> 2. You can configure this without needing some special software (this in
> particular means that seccomp is not an option).

I'd have to add 3. You can set a global default for all users that can
be overridden on a per user basis.

Otherwise you play whack-a-mole with every new user or daemon that
adds its own uid.

josh

[toc] | [prev] | [next] | [standalone]

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

Quoting Josh Boyer (jwboyer@fedoraproject.org):
> On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
> > On 2016-01-26 09:38, Josh Boyer wrote:
> >>
> >> 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
> >> distro kernel as-is, which may not meet their goal of having userns
> >> disabled, or 2) rebuild their kernel to disable it, which may
> >> invalidate any support contracts they have.
> >>
> >> I tend to agree with you on the lack of value around runtime
> >> mitigation, but allowing an admin to toggle this as a blatant on/off
> >> switch on reboot does have value.
> >>
> >>>> 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.
> >>
> >>
> >> Where that number may be zero?  I don't see how that is really any
> >> better than a sysctl.  Could you elaborate?
> >
> > It's a better option because it would allow better configurability. Take for
> > example a single user desktop system with some network daemons.  On such a
> > system, the actual login used for the graphical environment by the user
> > should be allowed at least a few user namespaces, because some software
> > depends on them for security (Chrome for example, as well as some distro's
> > build systems), but system users should be limited to at most one if they
> > need it, and ideally zero, so that remote exploits couldn't give access to a
> > user namespace.
> >
> > Conversely, on a server system, it's not unreasonable to completely disable
> > user namespaces for almost everything, except for giving one to services
> > that use them properly for sand-boxing.
> 
> OK, so better granularity.  Fine.
> 
> > I will state though that I only feel this is a better solution given that
> > two criteria are met:
> > 1. You can set 0 as the limit.
> > 2. You can configure this without needing some special software (this in
> > particular means that seccomp is not an option).
> 
> I'd have to add 3. You can set a global default for all users that can
> be overridden on a per user basis.
> 
> Otherwise you play whack-a-mole with every new user or daemon that
> adds its own uid.

Given that you want per-user, does a per-uid rlimit, which could be -1
(unlimited) by default, inherited for all uids mapped into a namespace
owned by the uid, and which can be set (only reduced) by pam on login,
make sense?

I'm still not actually seeing the value of this apart from another knob
to prevent kernel memory abuse.  But at least it does kill two birds
with one stone (also satisfying people who want it turned off altogether).
Is there a third use case for limiting number of user namespaces per uid?

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jan 26, 2016 at 12:20 PM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> Quoting Josh Boyer (jwboyer@fedoraproject.org):
>> On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
>> <ahferroin7@gmail.com> wrote:
>> > On 2016-01-26 09:38, Josh Boyer wrote:
>> >>
>> >> 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
>> >> distro kernel as-is, which may not meet their goal of having userns
>> >> disabled, or 2) rebuild their kernel to disable it, which may
>> >> invalidate any support contracts they have.
>> >>
>> >> I tend to agree with you on the lack of value around runtime
>> >> mitigation, but allowing an admin to toggle this as a blatant on/off
>> >> switch on reboot does have value.
>> >>
>> >>>> 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.
>> >>
>> >>
>> >> Where that number may be zero?  I don't see how that is really any
>> >> better than a sysctl.  Could you elaborate?
>> >
>> > It's a better option because it would allow better configurability. Take for
>> > example a single user desktop system with some network daemons.  On such a
>> > system, the actual login used for the graphical environment by the user
>> > should be allowed at least a few user namespaces, because some software
>> > depends on them for security (Chrome for example, as well as some distro's
>> > build systems), but system users should be limited to at most one if they
>> > need it, and ideally zero, so that remote exploits couldn't give access to a
>> > user namespace.
>> >
>> > Conversely, on a server system, it's not unreasonable to completely disable
>> > user namespaces for almost everything, except for giving one to services
>> > that use them properly for sand-boxing.
>>
>> OK, so better granularity.  Fine.
>>
>> > I will state though that I only feel this is a better solution given that
>> > two criteria are met:
>> > 1. You can set 0 as the limit.
>> > 2. You can configure this without needing some special software (this in
>> > particular means that seccomp is not an option).
>>
>> I'd have to add 3. You can set a global default for all users that can
>> be overridden on a per user basis.
>>
>> Otherwise you play whack-a-mole with every new user or daemon that
>> adds its own uid.
>
> Given that you want per-user, does a per-uid rlimit, which could be -1
> (unlimited) by default, inherited for all uids mapped into a namespace
> owned by the uid, and which can be set (only reduced) by pam on login,
> make sense?

To clarify, I don't actively want per-user.  Eric suggested it and I'm
thinking through it from a theoretical perspective.  I'd likely be
fine with a big ban-hammer that sysadmins can set, but that doesn't
mean I'm opposed to something more flexible if it makes sense.

I'm not sure if rlimit makes sense in the way you describe it.  I
don't care about uids within an existing user namespace really.  That
is icing on the cake.  I was looking for something that would disallow
uids to create user namespaces to begin with (so inheritance wouldn't
matter).  If rlimit is that mechanism, then I guess.  Seems like an
odd fit though, particularly if you tie it to pam.

> I'm still not actually seeing the value of this apart from another knob
> to prevent kernel memory abuse.  But at least it does kill two birds
> with one stone (also satisfying people who want it turned off altogether).
> Is there a third use case for limiting number of user namespaces per uid?

Not that I can think of.

josh

[toc] | [prev] | [next] | [standalone]

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

On 2016-01-26 14:56, Josh Boyer wrote:
> On Tue, Jan 26, 2016 at 12:20 PM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
>> Quoting Josh Boyer (jwboyer@fedoraproject.org):
>>> On Tue, Jan 26, 2016 at 9:46 AM, Austin S. Hemmelgarn
>>> <ahferroin7@gmail.com> wrote:
>>>> On 2016-01-26 09:38, Josh Boyer wrote:
>>>>>
>>>>> 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
>>>>> distro kernel as-is, which may not meet their goal of having userns
>>>>> disabled, or 2) rebuild their kernel to disable it, which may
>>>>> invalidate any support contracts they have.
>>>>>
>>>>> I tend to agree with you on the lack of value around runtime
>>>>> mitigation, but allowing an admin to toggle this as a blatant on/off
>>>>> switch on reboot does have value.
>>>>>
>>>>>>> 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.
>>>>>
>>>>>
>>>>> Where that number may be zero?  I don't see how that is really any
>>>>> better than a sysctl.  Could you elaborate?
>>>>
>>>> It's a better option because it would allow better configurability. Take for
>>>> example a single user desktop system with some network daemons.  On such a
>>>> system, the actual login used for the graphical environment by the user
>>>> should be allowed at least a few user namespaces, because some software
>>>> depends on them for security (Chrome for example, as well as some distro's
>>>> build systems), but system users should be limited to at most one if they
>>>> need it, and ideally zero, so that remote exploits couldn't give access to a
>>>> user namespace.
>>>>
>>>> Conversely, on a server system, it's not unreasonable to completely disable
>>>> user namespaces for almost everything, except for giving one to services
>>>> that use them properly for sand-boxing.
>>>
>>> OK, so better granularity.  Fine.
>>>
>>>> I will state though that I only feel this is a better solution given that
>>>> two criteria are met:
>>>> 1. You can set 0 as the limit.
>>>> 2. You can configure this without needing some special software (this in
>>>> particular means that seccomp is not an option).
>>>
>>> I'd have to add 3. You can set a global default for all users that can
>>> be overridden on a per user basis.
>>>
>>> Otherwise you play whack-a-mole with every new user or daemon that
>>> adds its own uid.
>>
>> Given that you want per-user, does a per-uid rlimit, which could be -1
>> (unlimited) by default, inherited for all uids mapped into a namespace
>> owned by the uid, and which can be set (only reduced) by pam on login,
>> make sense?
>
> To clarify, I don't actively want per-user.  Eric suggested it and I'm
> thinking through it from a theoretical perspective.  I'd likely be
> fine with a big ban-hammer that sysadmins can set, but that doesn't
> mean I'm opposed to something more flexible if it makes sense.
>
> I'm not sure if rlimit makes sense in the way you describe it.  I
> don't care about uids within an existing user namespace really.  That
> is icing on the cake.  I was looking for something that would disallow
> uids to create user namespaces to begin with (so inheritance wouldn't
> matter).  If rlimit is that mechanism, then I guess.  Seems like an
> odd fit though, particularly if you tie it to pam.
The PAM connection would be a side effect of it being an rlimit, not 
something by itself.  It's not used on a lot of smaller systems because 
Linux is not used as much as a time sharing system, but part of the 
purpose of PAM was to be able to set rlimits and similar things on new 
sessions before the user could do anything.  This is still used today, 
and /etc/security/limits.conf can be found on any modern Linux system 
which uses PAM.

[toc] | [prev] | [next] | [standalone]

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

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.

thanks,
-serge

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
<ahferroin7@gmail.com> 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
>>> <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.

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

[toc] | [prev] | [next] | [standalone]

#1318253 — Re: [kernel-hardening] 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@gmail.com> 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
>>>> <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.
>
> 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.

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jan 26, 2016 at 10:27 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> On 2016-01-26 12:15, Serge Hallyn wrote:
>>>
>>> Quoting Josh Boyer (jwboyer@fedoraproject.org):
>>>> 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.

The open-ended cases of web servers and shell access aren't cleanly
handled by seccomp. And we're talking about protecting them as soon as
this knob exists, not after each program or service grows its own
sandboxing solution.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

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

On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> Quoting Josh Boyer (jwboyer@fedoraproject.org):
>> 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.

My example is a machine in a colo rack serving web pages. A site gets
attacked, and www-data uses user namespaces to continue their attack
to gain root privileges.

The admin of such a machine could have disabled userns months earlier
and limited the scope of the attack.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

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

Kees Cook <keescook@chromium.org> writes:

> On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
>> Quoting Josh Boyer (jwboyer@fedoraproject.org):
>>> 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.
>
> My example is a machine in a colo rack serving web pages. A site gets
> attacked, and www-data uses user namespaces to continue their attack
> to gain root privileges.
>
> The admin of such a machine could have disabled userns months earlier
> and limited the scope of the attack.

Of course for the paranoid there is already a mechanism to do this.
/sbin/chroot.

No new user namespaces are allowed to be created inside of a chroot.

Eric

[toc] | [prev] | [next] | [standalone]

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

On 2016-01-27 05:27, Eric W. Biederman wrote:
> Kees Cook <keescook@chromium.org> writes:
>
>> On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
>>> Quoting Josh Boyer (jwboyer@fedoraproject.org):
>>>> 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.
>>
>> My example is a machine in a colo rack serving web pages. A site gets
>> attacked, and www-data uses user namespaces to continue their attack
>> to gain root privileges.
>>
>> The admin of such a machine could have disabled userns months earlier
>> and limited the scope of the attack.
>
> Of course for the paranoid there is already a mechanism to do this.
> /sbin/chroot.
>
> No new user namespaces are allowed to be created inside of a chroot.
I would like to point out that this is undocumented outside of the 
kernel source code on every Linux system I've seen.  And, it's not 
hugely obvious from looking at the source code unless you have some 
experience with kernel programming.

Also, being able to limit to exactly one (or possibly two depending on 
the application's usage of them) user namespace would be useful, as that 
would allow sand-boxing without the ability to create any more through 
some exploit.

[toc] | [prev] | [next] | [standalone]

#1318123

On Mon, Jan 25, 2016 at 8: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.

Again, not sure why you think that. My primary role in kernel
development is fixing or helping coordinate fixing of security issues
and features. I already acknowledged the issue (it is a corner case,
and no one seems to debate that). I'm working based on priorities; I
have a long list of things to do. :)

>>> 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.

Sure, no debate there. In fact, I'm certain you're 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 disagree. The same kinds of issues exist with any of the *_restrict
sysctls: if you turn them on later, things that happened before are
still going to be a problem. You'll have already leaked a kernel base
address, etc. This would be no different.

I'm open to having this sysctl kill all CLONE_NEWUSERed process trees,
if you think that'll be more useful?

> 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.

Again, I disagree. There are plenty of people who want to have user ns
disabled. This gives them the knob to do so.

>> 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

I said this:

>> Any admin that decides to just turn off CLONE_NEWUSER in the middle of
>> still using it is insane. I don't think this breeds any false sense of
>> security as most sysctls are set at boot time.

I was arguing that admins that use the sysctl are not going to be the
admins that are using containers already. I didn't mean it as "making
a mistake is insane" but rather "it would appear that a person using
both would be seeking opposing goals".

> usability matters, and your sysctl has low usability.

Unsurprisingly, we disagree here too. This sysctl serves as an attack
surface reduction tool. I never saw it as a way to evict existing
containers.

> 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.

It's not about management: the audience of the sysctl is only those
that are not using user namespaces. Providing attack surface reduction
tools to admins is a net win for Linux security as a whole. We both
want the same thing: a safer Linux environment. There's no debate that
having user ns exposes a larger attack surface than not having it.
Being able to disable it for people not interested in using user ns
means a reduction in their attack surface.

> 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.

That sounds fine to me. Are you thinking of a new RLIMIT, or something
else? I don't need a sysctl, I just want a way to effectively disable
user ns.

-Kees


-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1317204

On Sun, Jan 24, 2016 at 2:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Kees Cook <keescook@chromium.org> writes:
>>
>>> There continues to be unexpected side-effects and security exposures
>>> via CLONE_NEWUSER. For many end-users running distro kernels with
>>> CONFIG_USER_NS enabled, there is no way to disable this feature when
>>> desired. As such, this creates a sysctl to restrict CLONE_NEWUSER so
>>> admins not running containers or Chrome can avoid the risks of this
>>> feature.
>>
>> I don't actually think there do continue to be unexpected side-effects
>> and security exposures with CLONE_NEWUSER.  It takes a while for all of
>> the fixes to trickle out to distros.  At most what I have seen recently
>> are problems with other kernel interfaces being amplified with user
>> namespaces.  AKA the current mess with devpts, and the unexpected
>> issues with bind mounts in mount namespaces.
>>
>
>>
>> So to keep this productive.  Please tell me about the threat model
>> you envision, and how you envision knobs in the kernel being used to
>> counter those threats.
>
> I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN
> over /any/ network namespace and to thus access the network
> configuration API to be a huge risk.  For example, unprivileged users
> can program iptables.  I'll eat my hat if there are no privilege
> escalations in there.  (They can't request module loading, but still.)

Should I consider this an Ack for the patch? :)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1317208

On Mon, Jan 25, 2016 at 10:51 AM, Kees Cook <keescook@chromium.org> wrote:
> On Sun, Jan 24, 2016 at 2:22 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Kees Cook <keescook@chromium.org> writes:
>>>
>>>> There continues to be unexpected side-effects and security exposures
>>>> via CLONE_NEWUSER. For many end-users running distro kernels with
>>>> CONFIG_USER_NS enabled, there is no way to disable this feature when
>>>> desired. As such, this creates a sysctl to restrict CLONE_NEWUSER so
>>>> admins not running containers or Chrome can avoid the risks of this
>>>> feature.
>>>
>>> I don't actually think there do continue to be unexpected side-effects
>>> and security exposures with CLONE_NEWUSER.  It takes a while for all of
>>> the fixes to trickle out to distros.  At most what I have seen recently
>>> are problems with other kernel interfaces being amplified with user
>>> namespaces.  AKA the current mess with devpts, and the unexpected
>>> issues with bind mounts in mount namespaces.
>>>
>>
>>>
>>> So to keep this productive.  Please tell me about the threat model
>>> you envision, and how you envision knobs in the kernel being used to
>>> counter those threats.
>>
>> I consider the ability to use CLONE_NEWUSER to acquire CAP_NET_ADMIN
>> over /any/ network namespace and to thus access the network
>> configuration API to be a huge risk.  For example, unprivileged users
>> can program iptables.  I'll eat my hat if there are no privilege
>> escalations in there.  (They can't request module loading, but still.)
>
> Should I consider this an Ack for the patch? :)

Only if you explain why you need the CAP_SYS_ADMIN check.  :)

IOW, I think you could change that one line of code and have a less
weird version of the patch that would work just fine.

--Andy


-- 
Andy Lutomirski
AMA Capital Management, LLC

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web