The Future of Flatpak | slacker news

In case anyone ever seriously contemplates a new design, here's an anecdote:

Quite a few years ago, when Flatpak was a brand new project, I met some of the original developers. I tried, and failed, to convince them to change one particular fundamental part of the design. In the original design, and today, an installed Flatpak has a name, the permissions are bound to that name, you run that Flatpak and it has its assigned permissions, and, if anything else talks to it, it talks to it by that name. If I install a VSCode Flatpak as my UID and grant it access to my Documents directory, then VSCode, running as me, has access to Documents.

I argued that this was the wrong design. If I install VSCode as me, then there should be an installed copy, and that should have approximately no significance. If I run VSCode, then the running instance should have some id (possibly ephemeral), and that instance should have a set of permissions. If I want to run VSCode with access to ~/project_a and another instance with access to ~/project_b, it should just work and the instances should not be able to access each other's data, even if they're running at the same time. If I want to run two Tailscales, it should work. If I want to fire up an ephemeral instance of Firefox, that should work, too.

However many years later, I still think I was right. Flatpak gets this wrong, MS and Apple's App Stores get this wrong, Mac OS gets this (very very) wrong, etc. There's plenty of opportunity to do better.

(This is important from a bug-mitigation perspective: a LibreOffice document that achieves RCE should not be able to access my other documents. It's also important frmo a vendor-doesn't-care-at-all perspective: VScode has basically no security to begin with, and VSCode inside Flatpak ought to have a degree of real security courtesy of Flatpak.)

I do think this would be good for power users who want strict isolation between different instances of apps (and I'd also love to see better QubesOS type approaches, using a hypervisor), but perhaps most of this kind of work should be prioritized inside the application itself, using nested sandboxing. That way, the barriers are exactly where the user expects them to be based on the normal behavior of the application. Assuming vulnerabilities in the code that glues it all together don't get explosive, of course.

Web browsers do already use a variety of sandboxing techniques to achieve separation between tabs. Some of these techniques work inside Flatpak, but some of them are broken by Flatpak:

> Ideally, Flatpak would simply support nested namespacing and nested sandboxes, but currently it does not. Flatpak uses seccomp to prevent applications in a sandbox from having direct access to user namespaces.

Some of them are replaced by Flatpak, for application developers that wish to use the APIs:

> What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further

Fortunately, it seems Wick is optimistic about UID namespacing, the main thing stopping Firefox and Chrome from fixing this:

> Wick feels that user namespaces are, nowadays, a well-tested and a much-used interface. He does not think that there is much of a good argument against user namespaces anymore.

Back to the topic of instanced Flatpaks, as I understand one snag is that there is a long-term desire (by app stores/platforms in general) for a full boot-to-userspace code-signing setup to be tied into the sandboxing. The identity of each application should remain the same (unless specifically overridden by a power user) so that a fake version of an application can't adopt an existing application's confidential encrypted files if it doesn't meet the codesigning requirements. I guess one solution here would be for the segregated instances to be nested inside the application's identity, but that's getting quite complex. And we don't even have encryption nor any functioning secure boot + confidential computing implementation yet -- all we really have so far on this front is the reverse domain name notation being verified by Flathub, with filesystem access sandboxing to keep these folders separate.