On Tue, Jan 26, 2016 at 10:09 AM, Austin S. Hemmelgarn <ahferroin7@xxxxxxxxx> wrote: > On 2016-01-26 12:15, Serge Hallyn wrote: >> >> Quoting Josh Boyer (jwboyer@xxxxxxxxxxxxxxxxx): >>> >>> On Mon, Jan 25, 2016 at 11:57 PM, Eric W. Biederman >>> <ebiederm@xxxxxxxxxxxx> wrote: >>>> >>>> Kees Cook <keescook@xxxxxxxxxxxx> writes: >>>> >>>>> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman >>>>> <ebiederm@xxxxxxxxxxxx> wrote: >>>>>> >>>>>> Kees Cook <keescook@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >>>>>> >>>>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
