Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1315327 > unrolled thread
| Started by | Kees Cook <keescook@chromium.org> |
|---|---|
| First post | 2016-01-22 23:40 +0100 |
| Last post | 2016-01-25 20:00 +0100 |
| Articles | 20 on this page of 41 — 12 participants |
Back to article view | Back to linux.kernel
[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: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Robert Święcki <robert@swiecki.net> - 2016-01-28 15:50 +0100
Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook <keescook@chromium.org> - 2016-01-26 17:40 +0100
Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled "Serge E. Hallyn" <serge.hallyn@ubuntu.com> - 2016-01-28 10:00 +0100
Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-01-28 14:00 +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 3 — ← Prev page 1 [2] 3 Next page →
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2016-01-26 06:10 +0100 |
| Message-ID | <qV438-6Ko-7@gated-at.bofh.it> |
| In reply to | #1317377 |
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]
| From | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2016-01-26 15:40 +0100 |
| Message-ID | <qVcWM-5sj-49@gated-at.bofh.it> |
| In reply to | #1317539 |
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]
| From | "Austin S. Hemmelgarn" <ahferroin7@gmail.com> |
|---|---|
| Date | 2016-01-26 15:50 +0100 |
| Message-ID | <qVd6q-5vL-13@gated-at.bofh.it> |
| In reply to | #1317980 |
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]
| From | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2016-01-26 16:00 +0100 |
| Message-ID | <qVdg6-5z6-27@gated-at.bofh.it> |
| In reply to | #1317993 |
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]
| From | Serge Hallyn <serge.hallyn@ubuntu.com> |
|---|---|
| Date | 2016-01-26 18:30 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVfBg-7mT-3@gated-at.bofh.it> |
| In reply to | #1318014 |
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]
| From | Josh Boyer <jwboyer@fedoraproject.org> |
|---|---|
| Date | 2016-01-26 21:00 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVhWq-uq-13@gated-at.bofh.it> |
| In reply to | #1318190 |
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]
| From | "Austin S. Hemmelgarn" <ahferroin7@gmail.com> |
|---|---|
| Date | 2016-01-26 21:20 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVifM-QQ-7@gated-at.bofh.it> |
| In reply to | #1318326 |
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]
| From | Serge Hallyn <serge.hallyn@ubuntu.com> |
|---|---|
| Date | 2016-01-26 18:20 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVfrz-7iQ-5@gated-at.bofh.it> |
| In reply to | #1317980 |
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]
| From | "Austin S. Hemmelgarn" <ahferroin7@gmail.com> |
|---|---|
| Date | 2016-01-26 19:20 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVgnD-7Zo-3@gated-at.bofh.it> |
| In reply to | #1318161 |
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]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-01-26 19:30 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVgxk-83o-7@gated-at.bofh.it> |
| In reply to | #1318219 |
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]
| From | "Austin S. Hemmelgarn" <ahferroin7@gmail.com> |
|---|---|
| Date | 2016-01-26 19:50 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVgQG-8cd-17@gated-at.bofh.it> |
| In reply to | #1318220 |
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]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2016-01-27 00:20 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVl3X-2ZP-1@gated-at.bofh.it> |
| In reply to | #1318220 |
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]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2016-01-27 00:20 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVl3Y-2ZP-13@gated-at.bofh.it> |
| In reply to | #1318161 |
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]
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Date | 2016-01-27 11:50 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVvPH-2dw-11@gated-at.bofh.it> |
| In reply to | #1318461 |
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]
| From | "Austin S. Hemmelgarn" <ahferroin7@gmail.com> |
|---|---|
| Date | 2016-01-27 13:40 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVxya-3tH-3@gated-at.bofh.it> |
| In reply to | #1318843 |
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]
| From | Robert Święcki <robert@swiecki.net> |
|---|---|
| Date | 2016-01-28 15:50 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVW3v-4OQ-5@gated-at.bofh.it> |
| In reply to | #1318843 |
>> 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. Another alternative is to create a custom kernel module which will disable the user namespace (by limiting to privileged users only, or disabling it altogether). IMO people tend to use distro kernels for convenience, and a suggestion of creating a chroot dir for every service exposed to users, or building a custom kernel module is an advice that not many sysadmins using distro kernels would take, even if they have concerns about the the increased attack surface enabled by CLONE_NEWUSER. Also, I don't think the willingness to disable the feature or limit it to the already privileged users will be something that only truly paranoid sysadmins/users would have. We've seen a fair amount of privilege escalation / DoS bugs that this kernel feature enabled in the recent 18 months or so, and they still seem to be found on a somewhat regular basis. Therefore this discussion and its outcome might be of interest to less paranoid folk as well. I agree with Kees that the "knob" will be mostly used by admins of web-servers (and similar services) as a protection against privilege escalation after getting low-priv code execution on the system. Therefore a sysctl enabled from /etc/sysctl.conf should work well here, even if it's set to the permissive mode by default at boot.
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2016-01-26 17:40 +0100 |
| Message-ID | <qVeOT-6K1-7@gated-at.bofh.it> |
| In reply to | #1317539 |
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]
| From | "Serge E. Hallyn" <serge.hallyn@ubuntu.com> |
|---|---|
| Date | 2016-01-28 10:00 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVQAO-Qb-11@gated-at.bofh.it> |
| In reply to | #1317539 |
On Mon, Jan 25, 2016 at 10:57:32PM -0600, Eric W. Biederman wrote: > 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. Ok, I'm sorry, but after thinking about this quite awhile, I think this is a bad idea. If I'm allowed to create exactly one, then (a) I won't be able to run two instances of chrome (does chrome use one userns per tab or per application?), yet (b) i can easily just not use chrome and use my allocation to run a vulnerability. IMO, having a (hopefully temporary, so cleanly separated out) sysctl, which perhaps goes so far as to kill all non-init user namespaces when set to -1, makes the most sense. I still think the harm due to having userspace not being able to rely on user namespaces will, long term, be worse than the security implications of having user namespaces always enabled.
[toc] | [prev] | [next] | [standalone]
| From | "Austin S. Hemmelgarn" <ahferroin7@gmail.com> |
|---|---|
| Date | 2016-01-28 14:00 +0100 |
| Subject | Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled |
| Message-ID | <qVUl4-3wq-19@gated-at.bofh.it> |
| In reply to | #1320443 |
On 2016-01-28 03:56, Serge E. Hallyn wrote: > On Mon, Jan 25, 2016 at 10:57:32PM -0600, Eric W. Biederman wrote: >> 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. > > Ok, I'm sorry, but after thinking about this quite awhile, I think this > is a bad idea. If I'm allowed to create exactly one, then (a) I won't > be able to run two instances of chrome (does chrome use one userns per > tab or per application?), yet (b) i can easily just not use chrome and > use my allocation to run a vulnerability. Ignore regular users WRT the ability to limit to one or two namespace instances, the advantage of being able to limit to one or two user namespaces for a given user is that it prevents daemons that use it for sand-boxing from being exploited to create more. If we go with Eric's suggestion, there is absolutely no reason on a regular desktop system that the users used for a graphical login would have to be limited. > > IMO, having a (hopefully temporary, so cleanly separated out) sysctl, > which perhaps goes so far as to kill all non-init user namespaces when > set to -1, makes the most sense. I still think the harm due to having > userspace not being able to rely on user namespaces will, long term, be > worse than the security implications of having user namespaces always > enabled. Userspace can't rely on them as it is right now. The default kernel config has them disabled, and a number of distros are refusing to ship kernels with them enabled at least in the short term, wheras a number are only shipping kernels with them enabled (I'd be willing to bet that part of what prompted this originally was Chrome). Just by virtue of this, you can't rely on them being there and need to gracefully handle the situation if they aren't. Adding a sysctl allowing them to be disabled completely on a kernel that has support built in would not make them all that much more unreliable than they already are.
[toc] | [prev] | [next] | [standalone]
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Date | 2016-01-25 20:00 +0100 |
| Message-ID | <qUUwO-8gR-21@gated-at.bofh.it> |
| In reply to | #1316061 |
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]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web