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.
