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