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.
On Thu, 2022-06-09 at 01:57 +0200, Philippe Cerfon wrote: [...] [...] 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.
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
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.
Well quite apparently not. 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. Just as it's absolutely standard not to have any containers. 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.
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 :-)
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