Arbitrary code execution breaking sandboxes in KDE Plasma
30 points by ecksdee
30 points by ecksdee
I really wish the Capsicum for Linux effort hadn't been killed by NIH. It's a far better model for sandboxing desktop applications (launcher grants them a set of initial capabilities [file descriptors] based on their metadata and they can't access anything else, powerboxes provide capabilities for opening and saving other things) than the pile of things that are used in Linux to try to achieve the same thing.
The whole Linux container model is a kinda scuffed patchwork of concepts that align mostly with running something akin to kubernetes services where services are orchestrated by some god-process, but don't really fit in a desktop environment where you'd want the ability to enter a lower privilege cgroup/namespace from userspace without going through the sort of root daemon or setuid rigmarole that inevitably invites privilege escalation risk.
It's also the wrong abstraction. The container isolation model is similar to jails in FreeBSD and Zones in Solaris: they're isolated worlds that look like VMs, you get something that's close to a separate computer. The thing I repeat all the time:
Isolation is easy, sharing is hard
The hard bit for application sandboxing is that it isn't an isolated environment. A sandboxed app that I run wants to have access to a document that I ask it to open, but only after it pops up a dialog box and I select the file, and only until the program quits. I want it to read from the clipboard, but only after I either use a standard keyboard shortcut (which the windowing system can intercept and grant access to the current clipboard contents before forwarding the event).
These very dynamic things are the kinds of things Capsicum was intended to support. You can start with access to a socket that talks to the windowing system, maybe access to a GPU device context, access to a temporary directory that is specific to this run and will be cleaned up at the end, read-execute access to shared libraries, and so on.
I heard about landlock semi-recently, it seems promising on that front, afaict.
Landlock remains path based, which leads to all sorts of confused-deputy and aliasing problems.
In theory this is how the major Linux desktop sandbox tools (Flatpak etc) are supposed to work, with SCM_RIGHTS + Wayland + D-Bus acting as the primitives. You can sort of see the outline of a secure desktop if you squint.
But the actual implementation on all sides is some combination of overly permissive, inflexible, and half-broken. Nobody seems to care about securing it end-to-end in the same way that people care about securing server workloads, which is why gVisor and Firecracker work so well but Flatpak can't even run a basic Gtk+ application without breaking the fonts, and every Wayland compositor has to re-implement half of the trusted desktop base.
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in, while iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic. Just do what they do! Why the hell is anything in the window manager reading /proc/{pid}/cmdline ??
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in,
Kind of. Android apps have a far simpler model for sharing (and some big holes when you try to make it look more like desktop interaction models).
iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic
Capsicum was designed, with input from Apple folks, specifically to support the sandboxing models that OS X shipped. They didn't switch to it because they'd already built something that did 90% of what they wanted on top of the TrustedBSD MAC layer and rewriting the whole thing with Capsicum was not desirable by that point.
Nobody seems to care about securing it end-to-end in the same way that people care about securing server workloads, which is why gVisor and Firecracker work so well but Flatpak can't even run a basic Gtk+ application without breaking the fonts,
I feel like these are measuring very different things? The scope of firecracker in particular is far narrower, given that it's "just" a micro VM implementation—not to discount the effort it takes for that, but Flatpak is trying to wrangle an existing and very complex ecosystem, whereas firecracker is doing a very good at mixing together two singular existing things (containers and VMs) and building on top of that existing infra. gVisor is certainly much much more involved, being basically a userspace kernel, but that's more practical when it's backed by Google money.
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in, while iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic.
...both of which are also backed by big company money and have the privilege of being able to tell the developers within "lol, cope" when making the necessary breaking changes. Linux userspace does not have that luxury.
Just do what they do!
Both of these mentioned have more tractible sandboxing because it's intertwined with the application platform. Linux userspace also does not have that luxury.
A public disclosure after upstream failed to patch. Hate to see it. (This is not at all directed towards the researcher.)