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.
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.
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)
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
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.
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.
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.
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).