Debian Bug report logs - #898446
Please reconsider enabling the user namespaces by default

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Laurent Bigonville <bigon@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Please reconsider enabling the user namespaces by default

Date: Fri, 11 May 2018 20:44:50 +0200

Source: linux
Version: 4.16.5-1
Severity: normal

Hi,

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.

Is there a list of remaining issues with the user namespaces? IIRC the
only discussion I've seen were about adding upstream the option to
disable them at runtime, nothing else.

Is it a possibility to reenable these for buster?

Kind regards,

Laurent Bigonville

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Message #10 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Laurent Bigonville <bigon@debian.org>, 898446@bugs.debian.org

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Sun, 13 May 2018 00:33:02 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 moreinfo

On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
> Source: linux
> Version: 4.16.5-1
> Severity: normal
> 
> Hi,
> 
> Firefox (and probably other applications) are using user namespaces these
> days to enhance the security.

Can you provide some information about this?

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

And this still mitigates a significant fraction of the security issues
found in the kernel.

> Apparently debian (and ubuntu) and arch are the only distributions
> disabling the user namespaces.
> 
> Is there a list of remaining issues with the user namespaces? IIRC the
> only discussion I've seen were about adding upstream the option to
> disable them at runtime, nothing else.
> 
> Is it a possibility to reenable these for buster?

User namespaces *are* enabled - but by default, they can only be
created by root.  It is still possible to change that with a sysctl.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
                                                 - Anne Morrow Lindberg

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Frederik Himpe <frederik@frehi.be>

To: 898446@bugs.debian.org

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Sun, 13 May 2018 19:19:09 +0200

On Sun, 13 May 2018 00:33:02 +0100 Ben Hutchings <ben@decadent.org.uk>
wrote:
> Control: tag -1 moreinfo
> 
> On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
> > Source: linux
> > Version: 4.16.5-1
> > Severity: normal
> > 
> > Hi,
> > 
> > Firefox (and probably other applications) are using user namespaces these
> > days to enhance the security.
> 
> Can you provide some information about this?

There is some info here:
https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html


Regards,

-- 
Frederik Himpe <frederik@frehi.be>

Message #22 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: bigon@debian.org

Cc: 898446@bugs.debian.org

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Sun, 13 May 2018 22:57:56 +0200

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.

Cheers,
        Moritz

Message #27 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Frederik Himpe <frederik@frehi.be>, 898446@bugs.debian.org

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Mon, 14 May 2018 03:43:42 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 - moreinfo

On Sun, 2018-05-13 at 19:19 +0200, Frederik Himpe wrote:
> On Sun, 13 May 2018 00:33:02 +0100 Ben Hutchings <ben@decadent.org.uk>
> wrote:
> > Control: tag -1 moreinfo
> > 
> > On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
> > > Source: linux
> > > Version: 4.16.5-1
> > > Severity: normal
> > > 
> > > Hi,
> > > 
> > > Firefox (and probably other applications) are using user namespaces these
> > > days to enhance the security.
> > 
> > Can you provide some information about this?
> 
> There is some info here:
> https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html

Quoting from there:

> This [..] complements the existing sandbox: in addition to blocking
> specific system calls like `open` and `connect`, we can prevent
> filesystem/network access no matter how it is requested. This is part
> of our defense in depth: if a clever attacker manages to bypass one
> layer of protection, that still won't be enough to compromise the
> system.

So it seems that for Firefox user namespaces are nice to have, but not
critical for the sandbox.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Laurent Bigonville <bigon@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>, 898446@bugs.debian.org

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Mon, 14 May 2018 07:23:46 +0200

Le 13/05/18 à 01:33, Ben Hutchings a écrit :
> Control: tag -1 moreinfo
>
> On Fri, 2018-05-11 at 20:44 +0200, Laurent Bigonville wrote:
>> Source: linux
>> Version: 4.16.5-1
>> Severity: normal
>>
>> Hi,
>>
>> Firefox (and probably other applications) are using user namespaces these
>> days to enhance the security.
> Can you provide some information about this?
https://www.morbo.org/2018/05/linux-sandboxing-improvements-in_10.html

Message #45 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Nikolas Nyby <nikolas@gnu.org>

To: 898446@bugs.debian.org

Date: Wed, 6 Mar 2019 09:45:15 -0500

Just to note here, the Brave browser (https://brave.com/) requires user 
namespaces. With Debian's default kernel, you currently get this error 
when starting Brave:

    $ brave-browser
    [8918:8918:0304/181514.182194:FATAL:zygote_host_impl_linux.cc(116)] 
No usable sandbox! Update your kernel or see 
https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md 
for more information on developing with the SUID sandbox. If you want to 
live dangerously and need an immediate workaround, you can try using 
--no-sandbox.
    Trace/breakpoint trap

And you need to start Brave with --no-sandbox. This can be solved with a 
custom kernel that has CONFIG_USER_NS=y in its config.

From this discussion though, it does seem like this may be disabled by 
default for good reasons..

Message #52 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Laurent Bigonville <bigon@debian.org>, 898446@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Mon, 30 Mar 2020 10:56:48 +0100

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

Message #57 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Simon McVittie <smcv@debian.org>

Cc: Laurent Bigonville <bigon@debian.org>, 898446@bugs.debian.org, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Mon, 30 Mar 2020 14:17:18 +0200

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

Message #62 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Simon McVittie <smcv@debian.org>, 898446@bugs.debian.org, Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Wed, 15 Apr 2020 02:52:11 +0100

[Message part 1 (text/plain, inline)]

On Mon, 2020-03-30 at 10:56 +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).

And CentOS 8 appears to enable user namespaces by default.  So at this
point I think we probably need to follow suit, if only because users
and developers will expect it to be enabled.

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

I certinaly have the impression that things have settled down.  I'd
need to spend some time reviewing recent security issues, to be sure of
that.

> 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).
[...]
> 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.
[...]

I think you've made a good case that user namespaces are likely to be a
net positive for security on Debian desktop systems.

This might not be true yet for servers that aren't container hosts.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
                                                      - Albert Einstein

[signature.asc (application/pgp-signature, inline)]

Message #67 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>

Cc: 898446@bugs.debian.org, Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Wed, 15 Apr 2020 08:32:08 +0100

On Wed, 15 Apr 2020 at 02:52:11 +0100, Ben Hutchings wrote:
> I think you've made a good case that user namespaces are likely to be a
> net positive for security on Debian desktop systems.
> 
> This might not be true yet for servers that aren't container hosts.

Perhaps Debian's kernel should continue to disable unprivileged creation
of user namespaces for now, but we should have a package that installs
a /etc/sysctl.d/*.conf fragment that will enable them, and packages
that benefit from them (bubblewrap, web browsers, sbuild) should have
a Depends or Recommends on that package instead of shipping a setuid-root
namespace-creation helper?

During the transition from "usually disabled" to "usually enabled", such
a package would also provide a useful way to document that the dependent
package won't work (optimally, or at all) without that feature.

I would prefer not to ship that file from src:bubblewrap, since bubblewrap
isn't the only user of that feature. Perhaps src:linux would be a better
home for it? And then it could go away (or be replaced by a Provides
from the kernel image) if/when a future kernel supports unprivileged
creation of user namespaces unconditionally.

    smcv

Message #72 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Simon McVittie <smcv@debian.org>

Cc: 898446@bugs.debian.org, Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Thu, 16 Apr 2020 03:09:25 +0100

[Message part 1 (text/plain, inline)]

On Wed, 2020-04-15 at 08:32 +0100, Simon McVittie wrote:
> On Wed, 15 Apr 2020 at 02:52:11 +0100, Ben Hutchings wrote:
> > I think you've made a good case that user namespaces are likely to be a
> > net positive for security on Debian desktop systems.
> > 
> > This might not be true yet for servers that aren't container hosts.
> 
> Perhaps Debian's kernel should continue to disable unprivileged creation
> of user namespaces for now, but we should have a package that installs
> a /etc/sysctl.d/*.conf fragment that will enable them, and packages
> that benefit from them (bubblewrap, web browsers, sbuild) should have
> a Depends or Recommends on that package instead of shipping a setuid-root
> namespace-creation helper?
[...]

But if users install, say, Chrome or Docker from upstream, it won't
know how to do this Debian magic.

Also, I don't think we should keep patching in
kernel.unprivileged_userns_clone forever, so the documented way to
disable user namespaces should be setting user.max_user_namespaces to
0.  But then there's no good way to have a drop-in file that changes
back to the upstream default, because that's dependent on system memory
size.

So I think we should do something like this:

* Document user.max_user_namespaces in procps's shipped
  /etc/sysctl.conf
* Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
  it (log a warning if it's changed)
* Document the change in bullseye release notes

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.

[signature.asc (application/pgp-signature, inline)]

Message #77 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Simon McVittie <smcv@debian.org>

To: Ben Hutchings <ben@decadent.org.uk>, 898446@bugs.debian.org

Cc: Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Tue, 20 Oct 2020 17:21:24 +0100

On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> I don't think we should keep patching in
> kernel.unprivileged_userns_clone forever, so the documented way to
> disable user namespaces should be setting user.max_user_namespaces to
> 0.  But then there's no good way to have a drop-in file that changes
> back to the upstream default, because that's dependent on system memory
> size.
> 
> So I think we should do something like this:
> 
> * Document user.max_user_namespaces in procps's shipped
>   /etc/sysctl.conf
> * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
>   it (log a warning if it's changed)
> * Document the change in bullseye release notes

Is this something you intend to do before bullseye, or is it now going
to be after bullseye?

If this is intended to happen before bullseye, I'd like enough time
before the freeze to put an as-graceful-as-possible transition in place
in the bubblewrap package.

(I'm not sure what form that transition should take - suggestions welcome!
Ideally I'd like bubblewrap to be setuid root if and only if we are still
using a kernel where it needs to be.)

    smcv

Message #82 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Simon McVittie <smcv@debian.org>, 898446@bugs.debian.org

Cc: Ben Hutchings <ben@decadent.org.uk>, Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Thu, 22 Oct 2020 22:55:33 +0200

Hi,

On Tue, Oct 20, 2020 at 05:21:24PM +0100, Simon McVittie wrote:
> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> > I don't think we should keep patching in
> > kernel.unprivileged_userns_clone forever, so the documented way to
> > disable user namespaces should be setting user.max_user_namespaces to
> > 0.  But then there's no good way to have a drop-in file that changes
> > back to the upstream default, because that's dependent on system memory
> > size.
> > 
> > So I think we should do something like this:
> > 
> > * Document user.max_user_namespaces in procps's shipped
> >   /etc/sysctl.conf
> > * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
> >   it (log a warning if it's changed)
> > * Document the change in bullseye release notes
> 
> Is this something you intend to do before bullseye, or is it now going
> to be after bullseye?
> 
> If this is intended to happen before bullseye, I'd like enough time
> before the freeze to put an as-graceful-as-possible transition in place
> in the bubblewrap package.
> 
> (I'm not sure what form that transition should take - suggestions welcome!
> Ideally I'd like bubblewrap to be setuid root if and only if we are still
> using a kernel where it needs to be.)

TBH, I think not having it enabled by default until now saved us a
couple of time from needing to release urgent fixes. It is more a gut
feeling and might not have enough weight: but having it still disabled
in bullseye by default we would be still better of from security
releases/DSA's perspectives.

Regards,
Salvatore

Message #87 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Salvatore Bonaccorso <carnil@debian.org>

Cc: Simon McVittie <smcv@debian.org>, 898446@bugs.debian.org, Ben Hutchings <ben@decadent.org.uk>, Laurent Bigonville <bigon@debian.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Thu, 22 Oct 2020 23:04:24 +0200

On Thu, Oct 22, 2020 at 10:55:33PM +0200, Salvatore Bonaccorso wrote:
> but having it still disabled
> in bullseye by default we would be still better of from security
> releases/DSA's perspectives.

Agreed.

Cheers,
        Moritz

Message #92 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Bastian Blank <waldi@debian.org>

To: Salvatore Bonaccorso <carnil@debian.org>, 898446@bugs.debian.org

Cc: Simon McVittie <smcv@debian.org>, Ben Hutchings <ben@decadent.org.uk>, Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Fri, 23 Oct 2020 08:42:15 +0200

On Thu, Oct 22, 2020 at 10:55:33PM +0200, Salvatore Bonaccorso wrote:
> TBH, I think not having it enabled by default until now saved us a
> couple of time from needing to release urgent fixes. It is more a gut
> feeling and might not have enough weight: but having it still disabled
> in bullseye by default we would be still better of from security
> releases/DSA's perspectives.

And how does it help if all people enable it, because common software,
like chromium, actually require it to run?  Then it does not help at all
against being forced to publish fixes.

Bastian

-- 
If there are self-made purgatories, then we all have to live in them.
		-- Spock, "This Side of Paradise", stardate 3417.7

Message #97 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Jordan Glover <Golden_Miller83@protonmail.ch>

To: "898446@bugs.debian.org" <898446@bugs.debian.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Fri, 23 Oct 2020 15:23:34 +0000

I think there are two aspects here. (In)security of unpriv user ns is one of them - personally I'm in favor of opinions from people who argue that the attack vector they open will remain for foreseeable future because kernel is simply too big to fix all bugs. The other thing is that containers & sandboxes ecosystem moved strong towards unpriv user ns which makes them nerfed or unusable on systems which don't support them. In result this is the choice between insecurity and obscurity.

In current state downstream devs may just not care about debian, ask users to enable unpriv user ns or prepare special "debian edition" version of their stuff like suid bwrap which brings security issues on their own[1] (among other problems).

As it was noted vast majority of other distros calculated the costs in favor of enabling unpriv user ns but one need to know that equation has two sides and whether you think unpriv user ns are secure or not is only one of them.

Jordan

[1] https://github.com/containers/bubblewrap/security/advisories/GHSA-j2qp-rvxj-43vj

Message #102 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Simon McVittie <smcv@debian.org>, 898446@bugs.debian.org

Cc: Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Sat, 24 Oct 2020 02:22:53 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2020-10-20 at 17:21 +0100, Simon McVittie wrote:
> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
> > I don't think we should keep patching in
> > kernel.unprivileged_userns_clone forever, so the documented way to
> > disable user namespaces should be setting user.max_user_namespaces to
> > 0.  But then there's no good way to have a drop-in file that changes
> > back to the upstream default, because that's dependent on system memory
> > size.
> > 
> > So I think we should do something like this:
> > 
> > * Document user.max_user_namespaces in procps's shipped
> >   /etc/sysctl.conf
> > * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
> >   it (log a warning if it's changed)
> > * Document the change in bullseye release notes
> 
> Is this something you intend to do before bullseye, or is it now going
> to be after bullseye?

I would like to do this for bullseye.  However, this has to be a
collective decision of the team.

> If this is intended to happen before bullseye, I'd like enough time
> before the freeze to put an as-graceful-as-possible transition in place
> in the bubblewrap package.
> 
> (I'm not sure what form that transition should take - suggestions welcome!
> Ideally I'd like bubblewrap to be setuid root if and only if we are still
> using a kernel where it needs to be.)

The only way I see to do that properly is to run a program at boot that
sets the setuid bit correctly for the running kernel.

You can get close with a kernel postinst hook, but you'd be changing
the bit before the new kernel is running, and for non-official kernel
packages you won't know whether they allow unprivileged user-namespace
creation.

Ben.

-- 
Ben Hutchings
The world is coming to an end.	Please log off.

[signature.asc (application/pgp-signature, inline)]

Message #107 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Salvatore Bonaccorso <carnil@debian.org>, 898446@bugs.debian.org, Simon McVittie <smcv@debian.org>, 898446@bugs.debian.org

Cc: Ben Hutchings <ben@decadent.org.uk>, Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Tue, 17 Nov 2020 11:18:00 -0500

On 2020-10-22 22:55:33, Salvatore Bonaccorso wrote:
> Hi,
>
> On Tue, Oct 20, 2020 at 05:21:24PM +0100, Simon McVittie wrote:
>> On Thu, 16 Apr 2020 at 03:09:25 +0100, Ben Hutchings wrote:
>> > I don't think we should keep patching in
>> > kernel.unprivileged_userns_clone forever, so the documented way to
>> > disable user namespaces should be setting user.max_user_namespaces to
>> > 0.  But then there's no good way to have a drop-in file that changes
>> > back to the upstream default, because that's dependent on system memory
>> > size.
>> > 
>> > So I think we should do something like this:
>> > 
>> > * Document user.max_user_namespaces in procps's shipped
>> >   /etc/sysctl.conf
>> > * Set kernel.unprivileged_userns_clone to 1 by default, and deprecate
>> >   it (log a warning if it's changed)
>> > * Document the change in bullseye release notes
>> 
>> Is this something you intend to do before bullseye, or is it now going
>> to be after bullseye?
>> 
>> If this is intended to happen before bullseye, I'd like enough time
>> before the freeze to put an as-graceful-as-possible transition in place
>> in the bubblewrap package.
>> 
>> (I'm not sure what form that transition should take - suggestions welcome!
>> Ideally I'd like bubblewrap to be setuid root if and only if we are still
>> using a kernel where it needs to be.)
>
> TBH, I think not having it enabled by default until now saved us a
> couple of time from needing to release urgent fixes. It is more a gut
> feeling and might not have enough weight: but having it still disabled
> in bullseye by default we would be still better of from security
> releases/DSA's perspectives.

Could we get a little more hard data about the attack vectors here? I
totally trust the security team's "gut feeling" on this, but it would be
great to be able to evaluate more concretely what we're talking about
here.

Local root privilege escalation, basically? Can we get a sense of what
those vulerabilities are, say with some example CVEs?

I'm asking because my main concern with security these days is with the
web browser. It's this huge gaping hole: every measure we can take to
sandbox that thing is become more and more critical, so I wonder if the
our tradeoff's evaluation is well adjusted here, especially considering
a lot of user_ns consumers are bypassing those restrictions by running
as root anyways...

It seems that, in those cases, we're getting the worst of both worlds...

a.
-- 
It is a miracle that curiosity survives formal education
                        - Albert Einstein

Message #112 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: Antoine Beaupré <anarcat@debian.org>, Salvatore Bonaccorso <carnil@debian.org>, 898446@bugs.debian.org, Simon McVittie <smcv@debian.org>

Cc: Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Tue, 17 Nov 2020 17:19:33 +0000

[Message part 1 (text/plain, inline)]

On Tue, 2020-11-17 at 11:18 -0500, Antoine Beaupré wrote:
[...]
> Could we get a little more hard data about the attack vectors here? I
> totally trust the security team's "gut feeling" on this, but it would be
> great to be able to evaluate more concretely what we're talking about
> here.
> 
> Local root privilege escalation, basically? Can we get a sense of what
> those vulerabilities are, say with some example CVEs?

Yes, local privilege escalation.

From the advisories I've prepared, I think these are all LPEs that were
mitigated by our current patch:

CVE-2015-2041
CVE-2015-8709
CVE-2016-3134
CVE-2016-8655
CVE-2017-6346
CVE-2017-7184
CVE-2017-7308
CVE-2017-11600
CVE-2017-15649
CVE-2017-16939
CVE-2017-18509
CVE-2017-1000111
CVE-2018-16884
CVE-2019-15666
CVE-2020-14386

They seem to have slowed to a trickle at this point.  And there are
sadly lots of other LPE bugs that it has no effect on.

> I'm asking because my main concern with security these days is with the
> web browser. It's this huge gaping hole: every measure we can take to
> sandbox that thing is become more and more critical, so I wonder if the
> our tradeoff's evaluation is well adjusted here, especially considering
> a lot of user_ns consumers are bypassing those restrictions by running
> as root anyways...

I tend to agree with this.

Ben.

> It seems that, in those cases, we're getting the worst of both worlds...
> 
> a.
-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
                 - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'

[signature.asc (application/pgp-signature, inline)]

Message #117 received at 898446@bugs.debian.org (full text, mbox, reply):

From: Ben Hutchings <ben@decadent.org.uk>

To: 898446@bugs.debian.org, Antoine Beaupré <anarcat@debian.org>, Salvatore Bonaccorso <carnil@debian.org>, Simon McVittie <smcv@debian.org>

Cc: Laurent Bigonville <bigon@debian.org>, Moritz Mühlenhoff <jmm@inutil.org>

Subject: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Date: Sun, 13 Dec 2020 17:36:31 +0100

[Message part 1 (text/plain, inline)]

On Tue, 2020-11-17 at 17:19 +0000, Ben Hutchings wrote:
> On Tue, 2020-11-17 at 11:18 -0500, Antoine Beaupré wrote:
> [...]
> > Could we get a little more hard data about the attack vectors here? I
> > totally trust the security team's "gut feeling" on this, but it would be
> > great to be able to evaluate more concretely what we're talking about
> > here.
> > 
> > Local root privilege escalation, basically? Can we get a sense of what
> > those vulerabilities are, say with some example CVEs?
> 
> Yes, local privilege escalation.
> 
> From the advisories I've prepared, I think these are all LPEs that were
> mitigated by our current patch:
[...]
> They seem to have slowed to a trickle at this point.  And there are
> sadly lots of other LPE bugs that it has no effect on.
> 
> > I'm asking because my main concern with security these days is with the
> > web browser. It's this huge gaping hole: every measure we can take to
> > sandbox that thing is become more and more critical, so I wonder if the
> > our tradeoff's evaluation is well adjusted here, especially considering
> > a lot of user_ns consumers are bypassing those restrictions by running
> > as root anyways...
> 
> I tend to agree with this.
[...]

Since no-one contradicted this, I've gone ahead and changed the default
on the master branch.  I added a NEWS entry for linux-image meta-
packages to let people know how to change it back if they want.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.

[signature.asc (application/pgp-signature, inline)]

Message #122 received at 898446-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 898446-close@bugs.debian.org

Subject: Bug#898446: fixed in linux 5.10.1-1~exp1

Date: Thu, 17 Dec 2020 12:00:09 +0000

Source: linux
Source-Version: 5.10.1-1~exp1
Done: Salvatore Bonaccorso <carnil@debian.org>

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 898446@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Salvatore Bonaccorso <carnil@debian.org> (supplier of updated linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Thu, 17 Dec 2020 10:06:31 +0100
Source: linux
Architecture: source
Version: 5.10.1-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: Debian Kernel Team <debian-kernel@lists.debian.org>
Changed-By: Salvatore Bonaccorso <carnil@debian.org>
Closes: 898446 960195 973870 975572
Changes:
 linux (5.10.1-1~exp1) experimental; urgency=medium
 .
   * New upstream release: https://kernelnewbies.org/Linux_5.10
   * New upstream stable update:
     https://www.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.1
 .
   [ Salvatore Bonaccorso ]
   * [rt] Update to 5.10-rt17
 .
   [ Ben Hutchings ]
   * userns: Enable unprivileged user namespaces by default (Closes: #898446)
     (sysctl: kernel.unprivileged_userns_clone)
 .
   [ Bastian Blank ]
   * Enable all Industrial I/O accelerometers. (closes: #975572)
   * Enable all Industrial I/O ADC.
   * Enable all Industrial I/O DAC.
   * Enable all Industrial I/O digital gyroscopes.
   * Enable all Industrial I/O IMU.
   * Enable all Industrial I/O light sensors.
   * Enable all Industrial I/O magnetometers.
   * Enable all Industrial I/O pressure sensors.
   * Enable all Industrial I/O proximity sensors.
   * Enable all Industrial I/O temperatur sensors.
   * Enable BT_LEDS.
   * Enable remaining LEDS_TRIGGER_*.
   * Enable ZONEFS_FS.
   * Gemerate BTF debug info: (closes: #973870)
     - Enable DEBUG_INFO_BTF.
     - Build-depend on dwarves.
   * [amd64] Support high CPU counts:
     - Set MAXSMP.
     - Remove not longer modifiable NR_CPUS.
   * [armel/marvell] Disable uncompressed size check.
   * [x86] Enable INTEL_TXT. (closes: #960195)
Checksums-Sha1:
 f414f580462d3f89634b6bb6ea91b9659da7dbe0 203922 linux_5.10.1-1~exp1.dsc
 e0bbd79565bcc5549b68078207dc1a3be34a8480 121433136 linux_5.10.1.orig.tar.xz
 3631699e412f1ad4251b14f3975d13283a1c8c86 1272056 linux_5.10.1-1~exp1.debian.tar.xz
 003e639db01905843a17f0c6312593c2b67b1546 7339 linux_5.10.1-1~exp1_source.buildinfo
Checksums-Sha256:
 78d8a96c1dad9cf2e12d46d25bc9713873ce7bf77b6c88d198dc9285081e1a8d 203922 linux_5.10.1-1~exp1.dsc
 5452ac49ebd6a09465d3331deb3e79358c48081019303d92f2e7f8f1f924ca14 121433136 linux_5.10.1.orig.tar.xz
 355d08d3e67dae8c0b252c407362ee518316ab8a2733302056bc10b1bee2bfbb 1272056 linux_5.10.1-1~exp1.debian.tar.xz
 0d89ca63ffaa6d5e077ca1bc8e55fa9df1751df2d8d05f94b7e5d2f932ffe003 7339 linux_5.10.1-1~exp1_source.buildinfo
Files:
 53eefcd401478621ddf90878cbb2c2c9 203922 kernel optional linux_5.10.1-1~exp1.dsc
 bae658b8a6124c57a1f156f58d1b42ef 121433136 kernel optional linux_5.10.1.orig.tar.xz
 a0f05b3ab5e7549ef32eff28b38afae9 1272056 kernel optional linux_5.10.1-1~exp1.debian.tar.xz
 8773243ec27326864cb6c9b51bdfc4d3 7339 kernel optional linux_5.10.1-1~exp1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQKmBAEBCgCQFiEERkRAmAjBceBVMd3uBUy48xNDz0QFAl/bH+lfFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2
NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQSHGNhcm5pbEBk
ZWJpYW4ub3JnAAoJEAVMuPMTQ89EkCsP/0Y0xfn1zMKznXnPMlwnQPplW22XDZOd
HIzxTB7ggho/gN+pM2TF1JQPVtwEdAVkaIvwDOsJ73pCukJVDLidzdM8KHdspSwc
ZuvVr45Bjes8umIQcjfqlwRve9bpHf7FfjKFU9oVoBI4iZLpgiJeQOIvaglTy2+N
YqX6xGnm55KHE25RxZ14ZzxcRNeVBIldwe0de2hHMLW4py8qZaiUFbZVE3mAfrSq
eK9ltIlDn5qU2NFCYXtYoPgOIreGoTH3eIHD0iFaGHWKMhGb75q8K5osyQxDeslr
zg/aLlrEVnoBhBVI8ymnlXd4rCwlSaIIQs+OMGgfrEFUMwygx8Z6Fs7VFPbwCVqB
7xk/2aAnpbSZdkYbFk6ijbKN5Yu3/5Ak4AX3XirN6holt+n+RUuqNbsnXstXj/i1
937AhlraoPDGbVPQoRXlJ2gnwx8N89iLHCtTB+aGN9n5zHnbU07UA/Gcnh5qTZou
M7yOQk9Lhe68XKIlY6VRLtN6CwFKLVVZZiexCfxiEsscT4FIRO5iFL+Vk/UXjZNB
9ECk6lcxPwKgYMpCmMmP4YPy4M2QtDENjY3BZfsh3P6zOvs3MkQ2kjJwVCU4SmAZ
foKnIHpUgbwUrMmr6muOBtcNQvwQzzYZVxcsEjVZO6DguvlvKg/Cnp2CTxYrq+rv
D5fGXDzbXw/8
=ErTu
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.