IntroductionPeople consider Linux the most secure operating system, as it is open-source. Even with all its might, vulnerabilities creep in the shadow, ready to strike. In this blog, we'll be taking a look at an infamous heap overflow vulnerability discovered in 2022. The growth of the Kubernetes and containers increased
The title does not mention anything near - Mitigation.
Your mentioned workaround is Ubuntu or more precise Kernel specific because most newer kernel already do this which can according to my link even cause issues.
To be able to exploit this vulnerability, the attacker needs to be able to run code in the container and the container must have CAP_SYS_ADMIN privileges. Linux kernel and all major distro maintainers have released patches.
This is not desktop user specific issue, more for those who work with container, and then even have CAP_SYS_ADMIN privileges. A normal desktop does not run containers nor has such privileges that someone can exploit actively. Server or for those who work in such environment usually use mentioned products.
The vulnerability was introduced in kernel 5.1 and patched in 5.16.2. You can mitigate completely the problem by patching to the latest version. Note, all major distributions released patches.
The guide is designed for those who for example use an older 4.x LTS kernel, run such processes, under specific circumstances and are vulnerable. So it is a fix.
People speculate that desktops are meant here, when real target always was servers and people who work with lots of file-system related stuff but that is mostly also server only target. Some exceptions aside.
i am no expert, found the following :
CVE-2022-0185
From the Ubuntu security team
Published:18-January-2022
Mitigation
Disable unprivileged user namespaces:
sysctl -w kernel.unprivileged_userns_clone=0Nick Haflinger is, here again, 100% right.
Sorry @CHEFKOCH@lemmy.ml I read your link up to the end.
The title does not mention anything near - Mitigation.
Your mentioned workaround is Ubuntu or more precise Kernel specific because most newer kernel already do this which can according to my link even cause issues.
Nice try…
This is not desktop user specific issue, more for those who work with container, and then even have CAP_SYS_ADMIN privileges. A normal desktop does not run containers nor has such privileges that someone can exploit actively. Server or for those who work in such environment usually use mentioned products.
The guide is designed for those who for example use an older 4.x LTS kernel, run such processes, under specific circumstances and are vulnerable. So it is a fix.
People speculate that desktops are meant here, when real target always was servers and people who work with lots of file-system related stuff but that is mostly also server only target. Some exceptions aside.
i adjusted my previous comment.
i understand that I didn’t understand enough. i will leave this topic.