On Mon, Mar 30, 2020 at 10:56:48AM +0100, Simon McVittie wrote:
> 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?
It think we should still keep it disabled for Bullseye, there's still a good
rate of local privilege escalation vulnerabilities in core code with
unpriv usernamespaces. We could enable it after the Bullseye release and
tally security issues enabled by unpriv namespaces and then make a
decision after a year or so.
Cheers,
Moritz
