a key but often overlooked feature of distributions is that package *removal* is another form of package curation that is largely targeted at harm reduction.
maybe i should blog about that someday
Conversation
or in other words, if you're a distro shipping firejail to your users, you are harming your users and you should stop
2
9
Replying to
Firejail is horrible but unfortunately user namespaces also provide a bunch of low-hanging local root vulnerabilities by exposing substantially more kernel attack surface to anything able to use them.
It's important to disallow nearly anything from actually making namespaces.
1
1
5
A lot of setuid binaries don't take the risk of that poorly designed privilege elevation mechanism seriously and Firejail is definitely one of those.
Unfortunately most of the Linux kernel has the same approach to user namespaces. Developers see their code as not attack surface.
1
2
For example, user namespaces allow an unprivileged user to create a network namespace via a user namespace and then manage networking including iptables/nftables rules, etc. Same for mount namespace with mounts, etc. It exposes a huge amount of attack surface not designed for it.
1
2
The developers who wrote a lot of those things assumed only root could use them and did not write them to be at all robust to unprivileged users having access. Many of them don't agree with exposing the code this way so they don't actually see it as an issue for their subsystem.
1
2
Similar in some ways to how filesystem developers have historically considered it laughable to avoid trusting the filesystem state despite removable drives and verified boot both being widely used for ages and both depending on this actually being taken seriously.
1
3
At least they've sort of started fixing filesystems but they're still kinda treating it as a joke. Those network APIs are hardly doing that. Perf events are another API that's basically a root elevation system call with a maintainer who considers local security a total joke.
1
1
Ideally, namespaces are only actually usable by a tiny portion of userspace designed to create proper sandboxes. They need to give the sandboxed apps an API to make their own sandboxes, to avoid needing to expose user namespaces, etc. to them which makes the sandbox a joke.
1
2
Userns is a nice example of maintainers with their own fiefdoms without overall culture/leadership caring for security.
Userns, etc. maintainers don't take responsibility since the bugs it exposes aren't their bugs. Those maintainers don't see those bugs as their problem either.
Also see: CRIU. A small group developed a niche feature that had strong opposition. They put it behind CONFIG_EXPERT to excuse doing crazy things. They turned a bunch of private things into public ABIs. Now they expect the ABIs they exposed to block security / correctness fixes.
1
3
They unilaterally exposed ABIs in all sorts of subsystems without really putting in design effort with this understanding that it was just experimental and now it's actually being considered legitimate to block fixes based on it.
Anyways, Linux kernel makes me sad sometimes.
2