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

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

Bug#1012547: linux: disable user namespaces per default

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

Contents

  Bug#1012547: linux: disable user namespaces per default Philippe Cerfon <philcerf@gmail.com> - 2022-06-09 02:10 +0200
    Bug#1012547: linux: disable user namespaces per default Ben Hutchings <ben@decadent.org.uk> - 2022-06-13 17:10 +0200
      Bug#1012547: linux: disable user namespaces per default Diederik de Haas <didi.debian@cknow.org> - 2022-06-13 18:00 +0200
        Bug#1012547: linux: disable user namespaces per default Ben Hutchings <ben@decadent.org.uk> - 2022-06-13 18:40 +0200
      Bug#1012547: linux: disable user namespaces per default Philippe Cerfon <philcerf@gmail.com> - 2022-06-16 18:30 +0200
        Bug#1012547: linux: disable user namespaces per default Philippe Cerfon <philcerf@gmail.com> - 2022-07-05 15:30 +0200
          Bug#1012547: linux: disable user namespaces per default Philippe Cerfon <philcerf@gmail.com> - 2022-08-08 16:00 +0200
      Bug#1012547: linux: disable user namespaces per default Philippe Cerfon <philcerf@gmail.com> - 2022-10-27 02:00 +0200
        Re: Bug#1012547: linux: disable user namespaces per default Gregor Riepl <onitake@gmail.com> - 2022-10-27 13:40 +0200
    Processed: Re: Bug#1012547: linux: disable user namespaces per  default "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-06-13 17:10 +0200

#75531 — Bug#1012547: linux: disable user namespaces per default

Source: linux
Version: 5.17.11-1
Severity: normal
Tags: security

Hi.

Some time ago, Debian decided to enable user namespaces per default.

Since then we've had numerous security holes which would have been
prevented when user namespaces were disabled.

I vaguely recall at least around 6-7 such holes, and a quick google
search seems to reveal that at least those would have been mitigated
by unprivileged user namespaces being disabled:
CVE-2019-18198
CVE-2020-14386
CVE-2022-0185
CVE-2022-24122
CVE-2022-25636
CVE-2022-1966 resp. CVE-2022-32250

And these are just the ones from more recent years.
A longer list can be found e.g.
https://security.stackexchange.com/questions/209529/what-does-enabling-kernel-unprivileged-userns-clone-do
.

It also doesn't look as if userns just needed some polishing and "now"
they'd be finally secure - it rather seems like just a matter of time
when one can read next, that some hole can be mitigated by disabling
userns.

It rather seems that this feature is only of special use, namely for
those people who use user namespaces with containers or similar - by
far no default on a average server or desktop.

Even "jailing" tools like bubblewrap do IMO not really justify this
being a default:
a) it's only used by certain programs, e.g. bubblewrap isn't a
standard tool found on every install
b) such tools could just ship a default sysctl config or rather ask a
debconf question whether such questionable functionality should be
enabled
c) there is anyway no such thing as a true "jail"  - software makers
should rather try to secure their code, than believing that some magic
tool would do the job for them, which use a feature which seems still
not stable from the security PoV.

So if the feature is anyway easily configurable - why choosing a
default which has proven insecure numerous times?
Why do all users - especially those who do not even use the feature -
have to suffer from it working out of the box, just for a few special
use cases (who could also just enable it)?

So please reconsider the previous choice, don't ship insecure defaults
and disable unprivileged userns per default, until at least some at
least 5-10 years no further hole is going to be found, which would
have been prevented with them being disabled.

Just my 2 cents,
Philippe.

PS: As for (d), it would be really bad if all programs who can make
use of userns now simply ship their own /etc/sysctl.d/foo.conf, making
it even more difficult for people who deliberately not want that
feature to keep it disabled for sure. There should be rather a
convention that such tools would enable it in a common file like
/etc/sysctl.d/userns.conf.

[toc] | [next] | [standalone]

#75586

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

Control: tag -1 wontfix

On Thu, 2022-06-09 at 01:57 +0200, Philippe Cerfon wrote:
[...]
> It rather seems that this feature is only of special use, namely for
> those people who use user namespaces with containers or similar - by
> far no default on a average server or desktop.
[...]

This is wrong.  On the desktop, browsers and Flatpak rely on user
namespaces for sandboxing (with an alternative being to install more
programs setuid-root).  On servers, use of containers is increasingly
common.  This is not "special use", it's absolutely standard.

We made the decision that the benefits of sandboxing with user
namespaces are likely to outweigh the risks, on most systems.  Nothing
you've said convinces me to alter that assessment.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.

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

#75588

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

On Monday, 13 June 2022 16:56:35 CEST Ben Hutchings wrote:
> We made the decision that the benefits of sandboxing with user
> namespaces are likely to outweigh the risks, on most systems.  Nothing
> you've said convinces me to alter that assessment.

I don't really/fully understand this topic, but I did look into it and from 
the Kconfig file I understood that it was (highly?) recommended to also enable 
CONFIG_MEMCG, while is defined as '=y' in debian/config/config.
So that seems great.

What I also found was the following in debian/config/armel/config.marvell:
# CONFIG_MEMCG is not set

Salsa commit fac721e3016478d286254eff2658954b15a70190 seems to be the 'cause' 
for that and commit title is "[armel] Fold config-reduced into config.marvell"
Lots of changes in that commit, but I didn't see an explicit reason why 
CONFIG_MEMCG should be disabled (IIUC) on that platform.
Is that something that needs to be corrected? (Just asking, I have no idea)

Cheers,
  Diederik

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

#75590

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

On Mon, 2022-06-13 at 17:46 +0200, Diederik de Haas wrote:
> On Monday, 13 June 2022 16:56:35 CEST Ben Hutchings wrote:
> > We made the decision that the benefits of sandboxing with user
> > namespaces are likely to outweigh the risks, on most systems.  Nothing
> > you've said convinces me to alter that assessment.
> 
> I don't really/fully understand this topic, but I did look into it and from 
> the Kconfig file I understood that it was (highly?) recommended to also enable 
> CONFIG_MEMCG, while is defined as '=y' in debian/config/config.
> So that seems great.
> 
> What I also found was the following in debian/config/armel/config.marvell:
> # CONFIG_MEMCG is not set
> 
> Salsa commit fac721e3016478d286254eff2658954b15a70190 seems to be the 'cause' 
> for that and commit title is "[armel] Fold config-reduced into config.marvell"
> Lots of changes in that commit, but I didn't see an explicit reason why 
> CONFIG_MEMCG should be disabled (IIUC) on that platform.
> Is that something that needs to be corrected? (Just asking, I have no idea)

Many (most?) of the machines supported by that configuration have a
dedicated kernel partition in flash, so we try to limit the kernel
image size.  That was one of the options that added significantly to
the image size and seemed less likely to be needed on armel.  I don't
know whether it still makes sense to disable it, since we gave up on
fitting into 2 MiB partitions.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.

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

#75632

On Mon, Jun 13, 2022 at 4:56 PM Ben Hutchings <ben@decadent.org.uk> wrote:
> This is wrong.

Well quite apparently not.

> On the desktop, browsers and Flatpak rely on user
> namespaces for sandboxing (with an alternative being to install more
> programs setuid-root).

At least firefox doesn't seem to need it, neither does KDE, LXDE or
Cinnamon. And last time I've looked, dpkg was still the main and
default package system of Debian, and flatpak just some random
external one. Though maybe one should rename Debian Flatian.

> On servers, use of containers is increasingly
> common.  This is not "special use", it's absolutely standard.

Just as it's absolutely standard not to have any containers.


> We made the decision that the benefits of sandboxing with user
> namespaces are likely to outweigh the risks, on most systems.  Nothing
> you've said convinces me to alter that assessment.

Well I guess the 6 or so root security holes, and counting, probably
just don't matter to Debian then. What does it matter if people's
system are compromised over and over again, as long as the needs of a
fraction of users are satisfied and a special technology runs out of
the box.

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

#75843

On Thu, Jun 16, 2022 at 6:19 PM Philippe Cerfon <philcerf@gmail.com> wrote:
> Well I guess the 6 or so root security holes, and counting

And here we go already, faster than even I'd have expected:

Say welcome to CVE-2022-32250, the next root security hole which would
apparently have been mitigated if Debian were to ship sane defaults.

Shall we guess how many systems are going to be compromised because of
that?! I guess, none, because attackers surely understand that they
should abuse something that's needed for some containers and flatpaks
:-)

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

#76086

Apparently it's already Christmas:

The next two holes that likely allow privilege escalation and that
would have been mitigated by unprivileged user namespaces being
disabled:
 CVE-2022-1015, CVE-2022-1016

Cheers,
Phiippe

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

#76703

Here we go, another one, it seems:

CVE-2022-2588 (https://seclists.org/oss-sec/2022/q3/115)


Seems I'm not the only one who's quite concerned about the ongoing
security impact of user namspaces, as the recent/current discussion
about some LSM patches for 6.1 shows:
https://lwn.net/ml/linux-kernel/CAHk-=wiCqicQrnQPeHbDF7ECKHk_ceYzZK5dYq7y5nZTZhpB8g@mail.gmail.com/#t

Quoting Linus:

> And I think you are in denial about how many problems the
> user-namespace stuff has caused.
>
> Distros are literally turning it off entirely because the whole "let
> users create their own namespace" has *NOT* been a great success.
>
> I personally think it was a mistake. We're stuck with it, but we most
> definitely need knobs to manage it that isn't just "enable/disable
> USER_NS" in the kernel config.
>
> So this whole "don't do this" approach you have is not acceptable.
>
> 99% of all code does NOT WANT the user namespace thing, and it's been
> a big new attack surface for the kernel getting things subtly wrong.


It's still a shame to see that Debian intentionally sacrifices the
security of *all* users just for the needs of very few.

Regards,
Philippe.

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

#76714

> Seems I'm not the only one who's quite concerned about the ongoing
> security impact of user namspaces, as the recent/current discussion
> about some LSM patches for 6.1 shows:
>>
>> 99% of all code does NOT WANT the user namespace thing, and it's been
>> a big new attack surface for the kernel getting things subtly wrong.
> 
> It's still a shame to see that Debian intentionally sacrifices the
> security of *all* users just for the needs of very few.

I'd very much like to see where Linus gets his "99%" from. Sounds a like 
like a "I'm not using it, so 99% of all users aren't using it". Podman 
certainly supports and uses them, when run as non-root. [1] [2]

The whole point of user namespaces is to *reduce* the attack surface, 
not increase it. If you don't have a comparable feature, you need to 
give your applications more power, increasing the risk of system 
compromise overall.
For example: Running containers or container runtimes as root.

That the implementation has serious issues like this one is sad, but it 
is more of an indication that the feature wasn't quite ready for general 
consumption yet, not that it's a bad feature per se. And how would you 
build a user base and discover issues without making the feature 
available to the general public?


[1] 
https://medium.com/techbull/what-is-user-namespace-and-podmans-rootless-containers-fc4c292c6bad
[2] https://opensource.com/article/18/12/podman-and-user-namespaces

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

#75587 — Processed: Re: Bug#1012547: linux: disable user namespaces per default

Processing control commands:

> tag -1 wontfix
Bug #1012547 [src:linux] linux: disable user namespaces per default
Added tag(s) wontfix.

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

[toc] | [prev] | [standalone]

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

csiph-web