On 18 Oct 2015 22:13, Tobias Markus wrote:
On 17.10.2015 22:17, Richard Weinberger wrote:
quoted
On Sat, Oct 17, 2015 at 5:58 PM, Tobias Markus [off-list ref] wrote:
quoted
One question remains though: Does this break userspace executables that
expect being able to create user namespaces without priviledge? Since
creating user namespaces without CAP_SYS_ADMIN was not possible before
Linux 3.8, programs should already expect a potential EPERM upon calling
clone. Since creating a user namespace without CAP_SYS_USER_NS would
also cause EPERM, we should be on the safe side.
In case of doubt, yes it will break existing software.
Hiding user namespaces behind CAP_SYS_USER_NS will not magically
make them secure.
The goal is not to make user namespaces secure, but to limit access to
them somewhat in order to reduce the potential attack surface.
the irony is that disallowing non-privileged processes access to userns means
processes cannot jail themselves and thus make themselves more secure. i've
been adding userns to various projects purely to get access to things like
mount, net, pid, sysv, and ipc namespaces.
putting this behind a cap also breaks the Chromium sandbox -- they were able
to drop set*id on the sandbox binary and utilize userns instead.
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_sandboxing.md
https://code.google.com/p/chromium/issues/detail?id=312380
-mike