Re: Bug#1012547: linux: disable user namespaces per default
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
Bug#1012547: linux: disable user namespaces per default
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_ceyzzk5dyq7y5nztzhp...@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.
Bug#1012547: linux: disable user namespaces per default
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
Re: Bug#1012547: linux: disable user namespaces per default
On Tue, Jul 19, 2022 at 12:20 PM wrote: > I'm sorry that you didn't read the actual CVE. Well I did... which is why I haven't written "the next security hole in user ns" but "the next one that have been mitigated if Debian were to ship sane defaults". > Do correct me if I'm wrong, though. In the end of the day it's still yet another root security hole which was exposed for no good reasons, by user names being enabled per default - where the bug originates in, won't really bother any attacker, nor will it make a difference for any compromised system. Regards, Philippe
Re: Bug#1012547: linux: disable user namespaces per default
On Tue, 5 Jul 2022 at 16:22 Philippe Cerfon wrote: > Say welcome to CVE-2022-32250, the next root security hole which would apparently have been mitigated if Debian were to ship sane defaults. I'm sorry that you didn't read the actual CVE. This wasn't a bug with user namespaces, but rather a bug in netfilter that was exploitable through user namespaces. Of course, this wouldn't really have been exploitable had user namespaces since root using an exploit to elevate its privileges to root is... silly. The bug would've still existed without user namespaces, which is still bad, it just would've been pointless. It's pretty funny, actually; from what I'm able to undertstand, most, if not all the CVEs you listed in your original report weren't really bugs with user namespaces *at all*, they were really just bugs in components *around* user namespaces. Instead, how about we disable netfilter et al. for being buggy? ;) I really don't think the morale of the story here is "user namespaces are dangerous", but rather "code in Linux tends to be buggy and should be fixed", and I don't see why user namespaces should be disabled when it's other components that are buggy dangerous. Do correct me if I'm wrong, though. -- ~miko
Bug#1012547: linux: disable user namespaces per default
On Thu, Jun 16, 2022 at 6:19 PM Philippe Cerfon 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 :-)
Bug#1012547: linux: disable user namespaces per default
On Mon, Jun 13, 2022 at 4:56 PM Ben Hutchings 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.
Bug#1012547: linux: disable user namespaces per default
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. signature.asc Description: This is a digitally signed message part
Bug#1012547: linux: disable user namespaces per default
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 signature.asc Description: This is a digitally signed message part.
Bug#1012547: linux: disable user namespaces per default
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. signature.asc Description: This is a digitally signed message part
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 ow...@bugs.debian.org with problems
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.
