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

[Ben Hutchings]

On Tue, 2020-11-17 at 17:19 +, 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
Description: This is a digitally signed message part

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

[Ben Hutchings]

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
Description: This is a digitally signed message part

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

[Antoine Beaupré]

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

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

[Ben Hutchings]

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
Description: This is a digitally signed message part

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

[Jordan Glover]

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

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

[Bastian Blank]

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

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

[Moritz Muehlenhoff]

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

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

[Salvatore Bonaccorso]

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

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

[Simon McVittie]

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

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

[Ben Hutchings]

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
Description: This is a digitally signed message part

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

[Simon McVittie]

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

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

[Ben Hutchings]

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
Description: This is a digitally signed message part

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

[Moritz Mühlenhoff]

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

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

[Simon McVittie]

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

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

[Laurent Bigonville]

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

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

[Debian Bug Tracking System]

Processing control commands:

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

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

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

[Ben Hutchings]

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 
> 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
Description: This is a digitally signed message part

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

[Moritz Mühlenhoff]

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

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

[Frederik Himpe]

On Sun, 13 May 2018 00:33:02 +0100 Ben Hutchings 
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 

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

[Debian Bug Tracking System]

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 ow...@bugs.debian.org with problems

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

[Ben Hutchings]

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
Description: This is a digitally signed message part

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

[Laurent Bigonville]

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