Hacker News new | ask | show | jobs
by stefan_ 363 days 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.
1 comments

For 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.
Actually 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.
Device 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.
Seems ironic considering namespaces are highly utilized for isolation/security purposes.
I presume they're left enabled for root.
The same software that wants to use namespaces for isolation will refuse to run as root.
Not 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.
Yes, 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.

I've even seen namespaces used for hiding malicious software in Ubuntu systems too.