3 ms·
Ironically Ubuntu 24 now blocks users from accessing namespaces because that kernel interface had a bunch of local privilege escalations, breaking programs that
by stefan_ 1y ago
Ironically Ubuntu 24 now blocks users from accessing namespaces because that kernel interface had a bunch of local privilege escalations, breaking programs that want to use them for isolation.
- holowoodman 1y agoFor the last 10 years or so, namespaces in Linux were the source of the absolute hightest number of local privilege escalations and sometimes even arbitrary code executions in kernel space. Building a kernel without user namespace support has been goto-advice for multiuser systems for almost as long. Ubuntu is just late to the game because they mostly have server or single-user-desktop customers.
- ranger_danger 1y agoSeems ironic considering namespaces are highly utilized for isolation/security purposes.
- immibis 1y agoI presume they're left enabled for root.
- stefan_ 1y agoThe same software that wants to use namespaces for isolation will refuse to run as root.
- immibis 1y agoNot true. Docker, for example. There's plenty of cases where you set up an isolation environment as root and then use it as non-root.
- holowoodman 1y agoYes, but actually no: usually setting up those namespaces is done through a privileged daemon or suid-root binaries. Both of those are prone to root exploits, which isn't as bad as a kernel exploit, but only a 'modprobe' away. Group membership in the 'docker' group is famous for being root-equivalent. It isn't impossible to do things right, but in practice, things are usually done badly.
- NexRebular 1y agoI've even seen namespaces used for hiding malicious software in Ubuntu systems too.
- stefan_ 1y agoActually I think device drivers got you beat there, but no ones suggesting we break them for users safety. Ubuntu today is more user hostile than Windows.
- holowoodman 1y agoDevice drivers are worse if you just count the numbers. But they are usually far less exploitable because very often you need to have the corresponding hardware plugged in or even need to manipulate said hardware to provide crafted inputs. So in reality, device driver problems are almost never exploitable.