It's actually more mature for desktop sandboxing then the other solutions because its been effective for years and has a lot of community work on sandboxing -
Not every app is well sandboxed with flatpak but this is the goal and they are making very good progress. Also a great way to track a larger project that your distribution doesn't keep up to date as you'd like.
just to note -- flatpak/flathub use bubblewrap under the covers which is very promising but I don't see the community profiles like firejail yet.
I think the effective answer is you don’t; this is for services. However, sandboxes for this specific purpose exists too: Flatpak, for example. If you want to sandbox programs that are part of the system installation, Firejail can provide pretty useful sandboxing. SELinux and AppArmor also can be configured directly, and some distros will come with default configuration for system apps. No one solution will ever be a panacea for either security or use cases, but together they can help build a setup with defense-in-depth.
Something I'd like to see is a simple way to define “containers” on my desktop that would allow me to run sandboxed versions of my standard apps in bundles.
The plan would be something like the following.
You have a simple gui that would allow you to create new containers, for which you could define what it has access to (specific folders, internet, sound, etc).
You could then add apps to your container, and they would only be able to play with each other in the container with the restrictions given.
I think that would work with a simple app essentially based on bubblewrap.
For example:
* A "torrents" container, where the only apps would be firefox, deluge and vlc, and access to no folder in my home directory, but the container would have its own home directory.
* An "admin" container, with only firefox and thunderbird and libreoffice, say, and access to my ~/Downloads and ~/Documents folders.
You should be able to run the admin.firefox and torrents.firefox side by side, since they'd have different profiles.
By default, each container would have its own "virtual filesystem" with no accesss to anything outside (modulo what's really needed), and only by toggling "links" would it be able to access your actual fs tree.
The GUI would be easy enough for computer "illiterate" people to work with it.
And the GUI would be smart enough to create desktop files with each new application I add to a container, with customized icons.
I don't expect it would be too complicated (essentially bookkeeping on top of bubblewrap).
If anyone is interested, I'd happily discuss it more!
It takes some fussing about but you can do it in more or less the obvious way. I regularly use firefox in a systemd-nspawn container, the only annoying thing at this time is needing root to start the container but there's already a plan for how to fix that and I believe someone has also posted a PR for supporting starting "machines" (in the systemd-machined sense) as a regular user.
Not to start a flamewar, but I'd like to point out why I think snap is not only inferior to flatpak technically but actually a threat to the linux desktop:
Snap is very deliberately centralized, with a single hard-coded repo URL. The server is also closed-source. This is because snap's somewhat transparent primary goal is to give Canonical central control of app installation across all linux distributions. The plan from there will include taking cuts of sales revenue and publishing fees. The pieces for this (like DRM) are falling into place.
Flatpak, because it isn't born out of such business a model, supports an arbitrary number of user-defined repos, which are trivial to host because they are static folders and can be installed with a single-click via a `flatpakrepo` url.
This is on top of other advantages such as upstream support from the likes of GNOME, support for sharing code between apps using "frameworks", supporting themes, using namespaces instead of modified AppArmor, p2p support, a better permission system, etc.
Snapcraft is about Canonical control over devices, the sandbox is just a mean to an end. Snapcraft leaves you with no control over which code runs on your device.
