Supported since stretch, the FlatPak framework is available on Debian. Might be useful for newer versions of standalone software that move too fast for Debian’s release cycle. There is a big warning label on relying on it for sandboxing security however.
Flatpak’s sandboxing isn’t that great. Most apps come with filesystem=home by default which mounts all of /home as read-write meaning you can escape just by running echo evil_malware >> .bashrc or many have device=all so you have access to all devices.
It’s not fine-grained at all and it’s either allow a whole bunch of stuff, or not allow anything.
The devs also refuse to add any X11 sandboxing and claim X11 can’t be secured even though using xpra is easy.
2 Likes
Indeed. Thanks for your input. It adds context to Bubblewrap’s recommendation of using Flatpak as an alternative for security sandboxing of resources like Pulseaudio which they don’t handle.
Now we know this is not a real option and that Firejail is the only sandboxing solution that attempts to handle the graphics/audio interactions of software besides other access.
2 Likes
In context of Policy for Inclusion of Compiled Software the sandboxing is irrelevant.
2 Likes
No, firejail’s handling of graphics/audio is essentially just a few blacklist rules.
firejail/src/firejail/pulseaudio.c at master · netblue30/firejail · GitHub
They’ve just made it far more complicated than it needs to be. Another reason why firejail has too large attack surface.
This can easily be replicated in other sandboxing solutions like bubblewrap by just not mounting pulseaudio files.
1 Like
Firejail discussion:
This is interesting because it contains some popular applications not available from any debian package repository.
Easy to setup on Debian.
Flatpakâthe future of application distribution
It’s because flathub is already in Debian.
Debian -- Details of package flatpak in buster
Does flathub pass the TUF Threat Model, TUF: Attacks and Weaknesses [archive]?
Edit:
Sandboxing abilities by flatpak are irrelevant as long as sandboxing isn’t worse as for manually installed software. Whatever sandboxing flatpak is doing, it shouldn’t break application’s own sandboxing. Such as, does flatpak break chromium’s own sandbox? I don’t know any indication for that yet. Just asking.
In other words, consideration is flathub as a source of software literally. It shouldn’t be held to a higher standard than APT.
1 Like
There have been no incidences reported of malware sneaking in past the code reviewers like snap so far. As for TUF security minded design, there’s no design documents I can readily find answering these questions so upstream needs to be asked. There is basic things like GPG signing all flatpak repo commits however.
For the Chrome package it seems they are running outside of the sanbox entirely otherwise it won’t work because of sandboxes conflicts.
1 Like
1 Like
The Chromium in flatpak has nested sandboxing - meaning it is patched to use both.
1 Like
Currently chromium or chromium based browsers doesnt work from flathub inside debian.
buster version of flatpak:
error: Failed to install org.chromium.Chromium: app/org.chromium.Chromium/x86_64/stable needs a later flatpak version (1.8.2)
When using buster-backports version of flatpak chromium still won’t work out of the box, but it is possible according to the following ticket.
Successfully tested just now.
Related to unprivileged user namespaces, kernel.unprivileged_userns_clone.
EDIT #1:
Reported to Debian.
org.chromium.Chromium broken in Debian buster
EDIT #2:
1 Like
nice tested on debian buster and its working as well. (but simon has nice reply which he gonna fix it without the need of security concerns in bullseye)
1 Like
On one hand, flathub seems like a great source of software for some cases. flathub’s own sandboxing capabilities even if limited forever could be disregarded for that use case.
On the other hand however, flathub’s own sandboxing capabilities interfere with other sandboxing initiatives, namely sandbox-app-launcher. Reference sandbox-app-launcher:
Could we request a feature from flathub to disable its own sandboxing to make it compatible with other sandboxing mechanisms such as sandbox-app-launcher?
Hello, Bug #977758 in bubblewrap reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: Stop making /usr/bin/bwrap setuid root (245de437) · Commits · Debian / bubblewrap · GitLab ------------------------------------------------------------------------ Stop making /usr/bin/bwrap setuid root With Debian kernels >= 5.10, this is no longer necessary: unprivileged users can now create user namespaces, the same as in upstream kernels and Ubuntu. For smooth upgrades, install a sysctl configuration fragment that will configure older kernels to behave similarly if the recommended procps package is installed. Closes: #977758 Closes: #977841 ------------------------------------------------------------------------ (this message was generated automatically) – Greetings https://bugs.debian.org/977758
Are they incompatible by merely running side-by-side on the same system or do you mean when they are sandboxing the same app we are?
You can set an override parameter to their sanbox:
https://flatpak-testing.readthedocs.io/en/latest/working-with-the-sandbox.html
1 Like
Incompatibility of anything by merely installing sandbox-app-launcher without using it seems very unlikely at this point. All that sandbox-app-launcher package does is a few dependencies (at time of writing sudo, bubblewrap, apparmor, libseccomp-dev, helper-scripts, dbus-x11) which by itself don’t do anything. Just extra files on the disk which remain dormant unless used by starting these / configuration of these. sandbox-app-launcher is essentially a wrapper around bubblewrap.
Yes. Ideally we could start a flatpak application through sandbox-app-launcher. I.e.
sandbox-app-launcher flatpak run org.org.Applicationname
Quote from this ticket:
No, the sandbox isn’t optional. You can only poke holes in it.
https://grep.be/blog//en/computer/debian/Software_available_through_Extrepo/
Extrepo may be a better alternative here. They have all the major browser repos in their curated list including the Chromium privacy fork Iridium and also a Torproject repo - which I haven’t checked yet but may be a more direct way to obtain newer TBB releases.
1 Like