Flatpak - a security nightmare - 2 years later

Two years ago I wrote about then heavily-pushed Flatpak, self-proclaimed "Future of Apps on Linux". The article criticized the following three major flows in Flatpak:

• Most of the apps have full access to the host system but users are misled to believe the apps are sandboxed
• The flatpak runtimes and apps do not get security updates
• Flatpak breaks many aspects of desktop integration

So let's see how Flatpak developers addressed these fundamental issues.

The sandbox is STILL a lie

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions, in other words, write access to the user home directory (and more) so all it takes to escape the sandbox is trivial echo download_and_execute_evil >> ~/.bashrc. That's it.

The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed.

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?

Flatpak apps and runtimes STILL contain long known security holes

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.

But is it just this one application? Let's look at the official runtimes at the heart of Flatpak (org.freedesktop.Platform and org.gnome.Platform 3.36 - as of time of writing used by most of the applications on Flathub). The first unpatched vulnerable dependency I found in the offical runtime is ffmpeg in version 4.2.1 with no security patches backported, CVE-2020-12284.

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.

Local root exploits are NOT considered a minor issue anymore!

Great! Two years ago I wrote about a trivial local root exploit using flatpak to install suid binaries (CVE-2017-9780) and how it was downplayed by Flatpak developers as a minor security issue here. I am happy to see at least the attitude to local root exploits has changed and today local root exploits are considered high severity.

Desktop integration

System and user fonts are now available to flatpak applications and basic font rendering settings are respected as well, however do not expect your changes in /etc/fonts, typically setting a proper fallback font for CJK characters, to work with flatpak. KDE applications in flatpak are still ignoring themes, fonts and icon settings (tested with Qt5ct). Applications installed from the distribution sources do not have these problems, of course. A quick screen capture to demonstrate.

More importantly, fcitx, the IME for Chinese is still broken - it has been 2 years. Here is the issue I linked 2 years ago - especially of interest is the following comment directly from fcitx developer:

"Because fcitx im module in flatpak is from 4.2.97 and using a different dbus object path. It need to be the same version of fcitx on your host."

While the "bundle everything" approach has proven very useful on servers it clearly does not work for desktop applications, let's keep linking system libraries in desktop applications (and use the bundled libraries as a fallback only) to avoid introducing all these problems to Linux desktop.