Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #60976 > unrolled thread

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

Back to article view | Back to linux.debian.kernel

Contents

  Bug#898446: Please reconsider enabling the user namespaces by default Laurent Bigonville <bigon@debian.org> - 2018-05-11 20:50 +0200
    Processed: Re: Bug#898446: Please reconsider enabling the user  namespaces by default "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-05-13 01:40 +0200
    Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2018-05-13 01:40 +0200
      Bug#898446: Please reconsider enabling the user namespaces by default Frederik Himpe <frederik@frehi.be> - 2018-05-13 19:40 +0200
        Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2018-05-14 04:50 +0200
      Bug#898446: Please reconsider enabling the user namespaces by default Moritz Mühlenhoff <jmm@inutil.org> - 2018-05-13 23:10 +0200
        Bug#898446: Please reconsider enabling the user namespaces by default Simon McVittie <smcv@debian.org> - 2020-03-30 12:10 +0200
          Bug#898446: Please reconsider enabling the user namespaces by default Moritz Mühlenhoff <jmm@inutil.org> - 2020-03-30 14:30 +0200
          Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2020-04-15 04:00 +0200
            Bug#898446: Please reconsider enabling the user namespaces by default Simon McVittie <smcv@debian.org> - 2020-04-15 09:40 +0200
              Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2020-04-16 04:20 +0200
                Bug#898446: Please reconsider enabling the user namespaces by default Simon McVittie <smcv@debian.org> - 2020-10-20 18:30 +0200
                  Bug#898446: Please reconsider enabling the user namespaces by default Salvatore Bonaccorso <carnil@debian.org> - 2020-10-22 23:00 +0200
                    Bug#898446: Please reconsider enabling the user namespaces by default Moritz Muehlenhoff <jmm@inutil.org> - 2020-10-22 23:10 +0200
                    Bug#898446: Please reconsider enabling the user namespaces by default Bastian Blank <waldi@debian.org> - 2020-10-23 09:00 +0200
                    Bug#898446: Please reconsider enabling the user namespaces by default Antoine Beaupré <anarcat@debian.org> - 2020-11-17 17:30 +0100
                      Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2020-11-17 19:00 +0100
                        Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2020-12-13 17:40 +0100
                  Bug#898446: Please reconsider enabling the user namespaces by default Ben Hutchings <ben@decadent.org.uk> - 2020-10-24 03:30 +0200
      Bug#898446: Please reconsider enabling the user namespaces by default Laurent Bigonville <bigon@debian.org> - 2018-05-14 07:30 +0200
    Processed: Re: Bug#898446: Please reconsider enabling the user  namespaces by default "Debian Bug Tracking System" <owner@bugs.debian.org> - 2018-05-14 04:50 +0200
    Bug#898446: (no subject) Nikolas Nyby <nikolas@gnu.org> - 2019-03-06 15:50 +0100
    Bug#898446: Please reconsider enabling the user namespaces by default Jordan Glover <Golden_Miller83@protonmail.ch> - 2020-10-23 17:30 +0200
    Bug#898446: marked as done (Please reconsider enabling the user  namespaces by default) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-12-17 13:10 +0100

Page 1 of 2  [1] 2  Next page →

#60976 — Bug#898446: Please reconsider enabling the user namespaces by default

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

[toc] | [next] | [standalone]

#60979 — Processed: Re: Bug#898446: Please reconsider enabling the user namespaces by default

Processing control commands:

> tag -1 moreinfo
Bug #898446 [src:linux] Please reconsider enabling the user namespaces by default
Added tag(s) moreinfo.

-- 
898446: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#60980

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#60991

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>

[toc] | [prev] | [next] | [standalone]

#61007

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#60995

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

[toc] | [prev] | [next] | [standalone]

#66650

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

[toc] | [prev] | [next] | [standalone]

#66655

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

[toc] | [prev] | [next] | [standalone]

#66760

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#66763

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

[toc] | [prev] | [next] | [standalone]

#66773

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#68412

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

[toc] | [prev] | [next] | [standalone]

#68423

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

[toc] | [prev] | [next] | [standalone]

#68424

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

[toc] | [prev] | [next] | [standalone]

#68427

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

[toc] | [prev] | [next] | [standalone]

#68589

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

[toc] | [prev] | [next] | [standalone]

#68590

[Multipart message — attachments visible in raw view] — view raw

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'

[toc] | [prev] | [next] | [standalone]

#68831

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#68435

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#61009

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web