From: Josh Boyer <jwboyer@fedoraproject.org> To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com>, "Kees Cook" <keescook@chromium.org>, "Andy Lutomirski" <luto@amacapital.net>, "Andrew Morton" <akpm@linux-foundation.org>, "Al Viro" <viro@zeniv.linux.org.uk>, "Richard Weinberger" <richard@nod.at>, "Robert Święcki" <robert@swiecki.net>, "Dmitry Vyukov" <dvyukov@google.com>, "David Howells" <dhowells@redhat.com>, "Miklos Szeredi" <mszeredi@suse.cz>, "Kostya Serebryany" <kcc@google.com>, "Alexander Potapenko" <glider@google.com>, "Eric Dumazet" <edumazet@google.com>, "Sasha Levin" <sasha.levin@oracle.com>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com> Subject: Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Date: Tue, 26 Jan 2016 09:56:26 -0500 [thread overview] Message-ID: <CA+5PVA5pUu_jr70ntvBhzSdXo52ypUueofdnoRdRh+ehCR9j4g@mail.gmail.com> (raw) In-Reply-To: <56A786DA.90204@gmail.com> 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
WARNING: multiple messages have this Message-ID (diff)
From: Josh Boyer <jwboyer@fedoraproject.org> To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com>, "Kees Cook" <keescook@chromium.org>, "Andy Lutomirski" <luto@amacapital.net>, "Andrew Morton" <akpm@linux-foundation.org>, "Al Viro" <viro@zeniv.linux.org.uk>, "Richard Weinberger" <richard@nod.at>, "Robert Święcki" <robert@swiecki.net>, "Dmitry Vyukov" <dvyukov@google.com>, "David Howells" <dhowells@redhat.com>, "Miklos Szeredi" <mszeredi@suse.cz>, "Kostya Serebryany" <kcc@google.com>, "Alexander Potapenko" <glider@google.com>, "Eric Dumazet" <edumazet@google.com>, "Sasha Levin" <sasha.levin@oracle.com>, "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "kernel-hardening@lists.openwall.com" <kernel-hardening@lists.openwall.com> Subject: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Date: Tue, 26 Jan 2016 09:56:26 -0500 [thread overview] Message-ID: <CA+5PVA5pUu_jr70ntvBhzSdXo52ypUueofdnoRdRh+ehCR9j4g@mail.gmail.com> (raw) In-Reply-To: <56A786DA.90204@gmail.com> 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
next prev parent reply other threads:[~2016-01-26 14:56 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-22 22:39 [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook 2016-01-22 22:39 ` [kernel-hardening] " Kees Cook 2016-01-22 22:39 ` [PATCH 1/2] sysctl: expand use of proc_dointvec_minmax_sysadmin Kees Cook 2016-01-22 22:39 ` [kernel-hardening] " Kees Cook 2016-01-23 3:10 ` Eric W. Biederman 2016-01-23 3:10 ` [kernel-hardening] " Eric W. Biederman 2016-01-23 22:25 ` Jann Horn 2016-01-24 1:20 ` Eric W. Biederman 2016-01-24 1:43 ` Al Viro 2016-01-24 1:56 ` Jann Horn 2016-01-24 6:02 ` Eric W. Biederman 2016-01-24 6:32 ` Jann Horn 2016-01-24 6:44 ` Eric W. Biederman 2016-01-22 22:39 ` [PATCH 2/2] sysctl: allow CLONE_NEWUSER to be disabled Kees Cook 2016-01-22 22:39 ` [kernel-hardening] " Kees Cook 2016-01-22 22:47 ` Robert Święcki 2016-01-22 22:47 ` [kernel-hardening] " Robert Święcki 2016-01-22 22:50 ` Kees Cook 2016-01-22 22:50 ` [kernel-hardening] " Kees Cook 2016-01-22 22:55 ` Robert Święcki 2016-01-22 22:55 ` [kernel-hardening] " Robert Święcki 2016-01-22 23:00 ` Kees Cook 2016-01-22 23:00 ` [kernel-hardening] " Kees Cook 2016-01-23 0:44 ` Serge Hallyn 2016-01-23 0:44 ` [kernel-hardening] " Serge Hallyn 2016-01-23 0:44 ` Serge Hallyn 2016-01-23 0:44 ` [kernel-hardening] " Serge Hallyn 2016-01-23 0:59 ` Ben Hutchings 2016-01-24 20:59 ` Kees Cook 2016-01-24 20:59 ` Kees Cook 2016-01-24 22:20 ` Andy Lutomirski 2016-01-25 18:51 ` Kees Cook 2016-01-22 22:49 ` [PATCH 0/2] " Richard Weinberger 2016-01-22 22:49 ` [kernel-hardening] " Richard Weinberger 2016-01-23 3:02 ` Eric W. Biederman 2016-01-23 3:02 ` [kernel-hardening] " Eric W. Biederman 2016-01-24 20:57 ` Kees Cook 2016-01-24 20:57 ` [kernel-hardening] " Kees Cook 2016-01-26 7:38 ` Serge Hallyn 2016-01-24 22:22 ` Andy Lutomirski 2016-01-24 22:22 ` [kernel-hardening] " Andy Lutomirski 2016-01-25 18:51 ` Kees Cook 2016-01-25 18:51 ` [kernel-hardening] " Kees Cook 2016-01-25 18:53 ` Andy Lutomirski 2016-01-25 18:53 ` [kernel-hardening] " Andy Lutomirski 2016-01-25 18:56 ` Kees Cook 2016-01-25 18:56 ` [kernel-hardening] " Kees Cook 2016-01-25 19:33 ` Eric W. Biederman 2016-01-25 19:33 ` [kernel-hardening] " Eric W. Biederman 2016-01-25 22:34 ` Kees Cook 2016-01-25 22:34 ` [kernel-hardening] " Kees Cook 2016-01-25 23:33 ` Andy Lutomirski 2016-01-25 23:33 ` [kernel-hardening] " Andy Lutomirski 2016-01-26 2:27 ` Daniel Micay 2016-01-26 4:57 ` Eric W. Biederman 2016-01-26 4:57 ` [kernel-hardening] " Eric W. Biederman 2016-01-26 14:38 ` Josh Boyer 2016-01-26 14:38 ` [kernel-hardening] " Josh Boyer 2016-01-26 14:46 ` Austin S. Hemmelgarn 2016-01-26 14:46 ` [kernel-hardening] " Austin S. Hemmelgarn 2016-01-26 14:56 ` Josh Boyer [this message] 2016-01-26 14:56 ` Josh Boyer 2016-01-26 17:20 ` Serge Hallyn 2016-01-26 19:56 ` Josh Boyer 2016-01-26 20:11 ` Austin S. Hemmelgarn 2016-01-26 17:15 ` Serge Hallyn 2016-01-26 18:09 ` Austin S. Hemmelgarn 2016-01-26 18:27 ` Andy Lutomirski 2016-01-26 18:45 ` Austin S. Hemmelgarn 2016-01-26 23:15 ` Kees Cook 2016-01-26 23:13 ` Kees Cook 2016-01-27 10:27 ` Eric W. Biederman 2016-01-27 12:32 ` Austin S. Hemmelgarn 2016-01-28 14:41 ` Robert Święcki 2016-01-28 14:41 ` Robert Święcki 2016-01-26 23:47 ` Josh Boyer 2016-01-26 16:37 ` Kees Cook 2016-01-26 16:37 ` [kernel-hardening] " Kees Cook 2016-01-28 8:56 ` Serge E. Hallyn 2016-01-28 12:53 ` Austin S. Hemmelgarn
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CA+5PVA5pUu_jr70ntvBhzSdXo52ypUueofdnoRdRh+ehCR9j4g@mail.gmail.com \ --to=jwboyer@fedoraproject.org \ --cc=ahferroin7@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=dhowells@redhat.com \ --cc=dvyukov@google.com \ --cc=ebiederm@xmission.com \ --cc=edumazet@google.com \ --cc=glider@google.com \ --cc=kcc@google.com \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=mszeredi@suse.cz \ --cc=richard@nod.at \ --cc=robert@swiecki.net \ --cc=sasha.levin@oracle.com \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.