On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote:
> Firefox (and probably other applications) are using user namespaces these
> days to enhance the security.
>
> Debian is disabling these since 2013, the original patch states it's a
> short term solution, but we are here 5 years later and they are still
> disabled.
>
> Apparently debian (and ubuntu) and arch are the only distributions
> disabling the user namespaces.
A cross-distro status update:
- Debian still disables user namespaces by default with our
/proc/sys/kernel/unprivileged_userns_clone patch.
- Ubuntu now enables user namespaces by default. I think they still apply
the /proc/sys/kernel/unprivileged_userns_clone patch, but with the
default flipped?
- Arch Linux now enables user namespaces in their default kernel. There
is a non-default kernel, "linux-hardened", which applies the same patch
as Debian.
- Apparently RHEL 7 also disables user namespaces, although instead of
patching in a new sysctl, they set /proc/sys/user/max_user_namespaces
to 0 (which is an upstream thing since Linux 4.9).
On Sun, 13 May 2018 at 22:57:56 +0200, Moritz Mühlenhoff wrote:
> Ben Hutchings wrote:
> > And this still mitigates a significant fraction of the security issues
> > found in the kernel.
>
> A quite significant fraction; on average this neutralises a root privilege
> escalation every month or so. This is really not something that we should
> re-enable any time soon.
Is this still the case, or has the status of user namespaces settled down?
bubblewrap works around the restriction by being setuid root (and
imposing restrictions in user-space that are intended to be more
restrictive than those imposed by upstream kernels), but this makes
bubblewrap bugs into potential root privilege escalations, so I would love
to see bubblewrap no longer need to be setuid (like in Ubuntu). We're also
starting to see bubblewrap/Flatpak features that are not implementable
in a secure way with a setuid bubblewrap, so those features effectively
get disabled (don't work) in Debian, in order to fail closed: in
particular, Flatpak has a new "sub-sandboxing" feature, which runs part
of an app with more strict restrictions than the rest and is particularly
desirable for web browsers, and I don't think that works with the setuid
bubblewrap.
Non-Linux-specific Web browsers like Firefox and Chrome/Chromium
don't want to rely on bubblewrap (or can't rely on it, if it's
too restrictive for what they need), so they try to use their own
unprivileged-userns-based sandboxing for the web content process. In
Firefox, if I understand correctly, the fallback path is to not sandbox
in this way at all; in Chrome/Chromium, there is a setuid fallback
(which is enabled by the Debian chromium package), but it does not
receive new upstream development, and it seems to be ambiguous whether
its use is discouraged.
smcv
