Before starting this response, I would like to do a quick introduction about myself to provide some relevant background on what I do. I maintain some flatpaks that are a part of Flathub. Some notable ones are Microsoft Edge and vkBasalt. I've also contributed to some Flatpak wrappers, some examples are Zoom and Czkawka. I have also spent a lot of time going through Linux support channels for those that had trouble with Flatpak.
Almost all popular apps on Flathub still come with
filesystem=hostorfilesystem=homepermissions, in other words, write access to the user home directory (and more) so all it takes to escape the sandbox is trivialecho download_and_execute_evil >> ~/.bashrc. That's it.
I strongly agree with that. Some directories, like ~/.local/share/flatpak/overrides, are blocked. Despite having home or host access, they will still need explicit permissions to gain read-write access in blocked directories. Doing so with .bashrc, .zshrc and other shell configuration files would be very helpful security-wise to prevent sandbox escape.
The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed.
Alright, let's try to confirm this ourselves. In Flathub's website, there is a category containing the 50 most popular apps. Here is what I am going to do: I am going to visit all those 50 apps, go to their respective repositories, read the manifest, and check for either filesystem=home or filesystem=host. I will take Spotify for example. I open the Spotify page on Flathub, scroll down, press on See details, press on <> Code, and press on com.Spotify.Client.json, which is Spotify's manifest. Inside the manifest, it does not contain filesystem=host or filesystem=home. Do note that some manifests are written in YAML, thus having the .yaml file type. Now, onto the results.
If we check ourselves, 27 out of the 50 don't have access to the home or host filesystems. The remaining 23 do. Assuming the author checked if "almost all" is correct in the first place, this has since been changed, because over half of the popular applications don't have access to the home or host filesystems. (This data was gathered on Feburary 11th, 2021)
Another thing, three of their examples, VSCodium, PyCharm and Octave, are IDEs. It is crucial for an IDE to have access to the home or host filesystems, for Git repositories and for other external use, otherwise it is not very useful. Two of their examples, GIMP and Inkscape, are image and vector editors respectively. They as well need the extra permissions to function, for example editing in an external drive, USB, or even Git repositories for editing logos, etc. Audacity and VLC as well need the extra permissions to work in external devices.
And, indeed, users are still mislead by the reassuring blue "sandboxed" icon. Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)? Seriously?
I partly disagree with this. Technically speaking, applications are always sandboxed, as stated by the Flatpak developers. Even permitting access to the host filesystem won't grant the application full reign over your system. An example to this is the /proc directory, the directory storing information of processes running in the background. Permitting an application access to the host filesystem will still not let the application know what processes are running in the background. Not only that, the app will still not have access to D-Bus interfaces unless permitted, such as org.gnome.Shell.Screenshot, and many more.
Thankfully, this issue has been resolved in the recent updates. If this issue still persisted, then I would've criticized as well:
It took me about 20 minutes to find the first vulnerability in a Flathub application with full host access and I didn't even bother to use a vulnerability scanner.
A perfect example is CVE-2019-17498 with public exploit available for some 8 months. The first app on Flathub I find to use libssh2 library is Gitg and, indeed, it does ship with unpatched libssh2.
Most, if not all, distributions that ship with libssh2 do not patch libssh2 as well. An example of such distribution is Arch Linux. Further, if this was a very big deal, the libssh2 maintainers would have released a new version with the patch immediately. Despite being a very active project, they still haven't released a new update with the fix as of writing this response.
Recently I stumbled upon an article from 2011 which started what is today known as flatpak, in the words of the project founder:
"Another problem is with security (or bugfix) updates in bundled libraries. With bundled libraries its much harder to upgrade a single library, as you need to find and upgrade each app that uses it. Better tooling and upgrader support can lessen the impact of this, but not completely eliminate it."
After reading that it comes as no surprise flatpak still suffers from the same security issues as 2 years ago because flatpak developers knew about these problems from the beginning.
A valid point. Since the Flatpak developers were fully aware of that issue, they have come up with an acceptable and easy solution: flatpak-external-data-checker (f-e-d-c). f-e-d-c is a tool that automatically checks for external sources, such as dependencies and binaries. Once there is an update found, flathubbot will automatically submit a merge request. Here are some examples in practice: [1] [2].
It is impossible to fix every issue and make all desired changes at once. What is a priority is a matter of perspective and their respective threat model. It's literally impossible to have an issue-free/bug-free/security-hole free program. It's not enough to point out an issue, what matters is whether that issue is more important to solve quick compared to others or whether it's worth solving it at all.
While I do agree with many of flatkill.org's statements, many of them are made to incite fear in the Linux community. Given that all Flatpak wrappers and application build scripts are available and able to be edited by anyone, the appropriate response is to educate on why this is a problem, and then fix it. The way that flatkill.org approached this issue says a lot.
If you dislike Flatpak for numerous reasons, then I respect your opinion, but basing your arguments on an anonymous post that claims to have "criticized" Flatpak, but has not provided any statistics or evidence that the vulnerabilities were exploited inside a Flatpak wrapper is not a reliable source of information.
Edit 0: Initial writeup — (2021-02-11)
Edit 1: Improve tone and quality of sentences (credit to Kellegram and Poäng) — (2021-02-12)
Edit 2: Fix typos and improve sentences — (2021-02-12)
Edit 3: Be more realistic and agree with valid points; fix errors and improve sentences (credit to Lionir Deadman) — (2021-02-14)