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
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.
Quoted, replied here just now:
Chromium Browser for Kicksecure Discussions (not Whonix) - #70 by Patrick
Should we install Debian -- Details of package flatpak in bullseye by default in Whonix 16 (Debian bullseye based)?
Would be useful to make installation of OnionShare from flatpak easier:
OnionShare Whonix integration development discussion - #23 by torjunkie
According to this (which wont fix, or at least anytime soon), Then our security complains from gentoo package manager are just the same as this one.
Better no, Stick to upstream.
This post is super difficult to understand for anyone but those knowing every bit of Whonix wiki.
This really could use a reference…
Security-Focused Operating System Comparison as Base for Whonix
I am not sure it’s worth rehashing the years old Gentoo stuff. Ideally any security argument against FlatPak could stay on itself without needing to refer to Gentoo anything.
I guess you mean this:
Install Additional Software Safely
Yeah so this is not suitable to be taken as a source of software until they fix this issue (Thats why i linked it to gentoo because of the similar issue in the package manager).
Any software delivery mechanism that is at least as secure as apt should be considered (if it doesn’t take up too much space).
Quote Whonix wiki flatpak Package Manager Security
Comparison by security features [34] (such as signed metadata) alone, flatpak package manager security is comparable to Debian’s APT package manager security with a caveat. Flatpak currently does not defend against
indefinite freeze attacks[archive].Definition of
indefinite freeze attacksaccording to theTUF(The Update Framework) Threat Model [archive]:Indefinite freeze attacks. An attacker continues to present files to a software update system files that the client has already seen. As a result, the client is kept unaware of new files.
This attack is difficult to pull-off for many adversaries since it requires breaking TLS. While flatpak package version information are not protected by a
valid-untilfield [archive] these are fetched over TLS. Even if an adversary could break TLS, this would be lesser of an issue torified connections (such as by Whonix ™) since the adversary could not mount a targeted indefinite freeze attack against a specific user. Only against all Tor users, which would likely be caught, unless the adversary also has the ability to break Tor. The attack chain would be very complex. Break Tor → target specific user(s) → break TLS → mount indefinite freeze attack → exploit vulnerability due to indefinite freeze attack caused outdated software version.To work around this issue, users would have to manually check if their version numbers of their flatpak installed applications match the version numbers available from the flathub repository. Every application available from flathub has a corresponding website has a chapter
Additional informationwith entriesUpdatedandVersion. For example for Chromium there is the org.chromium.Chromium flathub website [archive] which at the time of writing this wiki chapter showed.UpdatedDecember 23, 2020,Version87.0.4280.88-1. Since researching version information on the flathub website is equally vulnerable to indefinite freeze attacks as the flathub package manager itself (both rely on TLS), it is recommended to use Whonix ™ or Tor Browser for this purpose. [35]Sometimes versions available through APT are too old, even have known vulnerabilities being exploited in the wild, for a long time. (example) On the other hand, flatpak most of the time, offers more recent software versions and/or deploys security fixes in a more timely manner.
Due to the complex attack chain, the advantages of flatpak outweigh the severity of potential indefinite freeze attacks since flatpak is sometimes the only trustworthy, easy to use source of software (or never versions) than what Debian stable (with Frozen Packages) (or newer) is offering.
Some who criticized its provided security:
https://flatkill.org/ (2018)
Flatpak - a security nightmare (2020)
some who also discussed these criticisms:
We aren’t relying on flatpak’s sandbox so this is a moot point, but still interesting to follow.
EDIT:
TL;DR Summary of the post is: “it’s bad, but not that bad and they’re working on it.”
Unfortunately any flatpak package manager capabilities are overshadowed by any flatpak sandbox capabilities.
In comparison, APT does not attempt to sandbox any packages it installed. Hence, a lot less negative press about it.
Actually I might be better if flatpak and the sandbox would be separate projects so one project doesn’t inherit the reputation by the other.
But it pass TUF which flatpak fail as well to (fully) pass it. So not only sandboxing issue but as well on package level issues.