"flatpak isnt secure anyways" - by slonkazoid

response to the flatpak portion of madaidan's analysis of a typical linux desktop's security (and partially Flatkill)

"flatpak isnt secure anyways"

here i was going about my day when someone in the WinBoat discord linked me this.. interesting article from 2022, specifically the flatpak section, saying flatpak isnt secure anyways ^^. i clicked on the link and the stench of Flatkill immediately hit me. if you don't know what Flatkill is, it is seemingly a reactionary response to flatpak existing more than anything else. it is full of ill-informed claims about security and includes name-calling an inanimate piece of software. but that's all besides the point. this post aims to debunk the article by madaidan, not Flatkill. so let's start, shall we?

madaidan's article

starting from the "Flatpak" title,

Flatpak aims to sandbox applications, but its sandboxing is very flawed. It fully trusts the applications and allows them to specify their own policy. This means that security is effectively optional and applications can simply choose not to be sufficiently sandboxed.

This is somewhat correct. The application you use to install Flatpak packages always warns you about permissions. The CLI does this. Discover does this. Everything does this. They warn you about potentionally unsafe permissions such as filesystem access. If you don't trust the app with these permissions, just don't click install. Furthermore, Flatpak isn't just a sandboxing solution, it is also an app distribution solution that fixes many of the shortcomings of prior attempts at Universal Linux Packaging, such as AppImages. Yes, a package can opt out of many of the sandboxing features. No, this is not a bad thing. You have free will, use it.

Flatpak's permissions are also far too broad to be meaningful. For example, many applications come with the filesystem=home or filesystem=host permissions, which grant read-write access to the user's home directory, giving access to all of your personal files and allowing trivial sandbox escapes via writing to ~/.bashrc or similar.

99% of the time, you don't have to use broad filesystem permissions. This is just lazy packaging, and would be caught by Flathub's package manifest linter. You have to specifically apply for an exception from Flathub's maintainers if your app requests unsafe permissions. Also, you can always not give an application a permission it requests.

It is correct that filesystem=home/host are too broad to be useful, but, just don't use them? Most apps do not need them.

In the Flathub Github organisation, ~550 applications come with such permissions, which is ~30% of all repositories. While this percentage may not seem significant, it includes a considerable amount of applications that people will commonly use. Examples of such include GIMP, Eog, Gedit, VLC, Krita, LibreOffice, Audacity, VSCode, Dropbox, Transmission, Skype and countless others.

Some of these are are overblown. For example, Skype is not even on Flathub anymore. Transmission, Audacity, VLC, and EoG are not official packages, and are probably the result of lazy or amateur packaging. You can submit a pull request to their respective manifests to rectify this problem. As for GIMP, Krita and gedit, these are likely just old manifests that were never updated to remove the filesystem permissions after the Document portal was standardized. VSCode is an interesting one. The Flatpak isn't official, and VSCode really doesn't like to run in an isolated environment. I don't know why you would use the Flatpak version ever, but that's besides the point. Consider how you use VSCode. It is an IDE. It is one of the rare cases that actually warrant a filesystem=host permission. You need to be able to access all of the tooling available on the system for it to work. I don't think VSCode having this permission is a bad thing, because it really does need it.

Another example of Flatpak's broad permissions is how it allows unfiltered access to the X11 socket, permitting easy sandbox escapes due to X11's lack of GUI isolation. Adding X11 sandboxing via a nested X11 server, such as Xpra, would not be difficult, but Flatpak developers refuse to acknowledge this and continue to claim, "X11 is impossible to secure".

This is true. X11 is impossible to secure. But this isn't a problem if you're using Xwayland, which you should be unless you're running Debian 9 with ancient Xfce or something.

Further examples include Flatpak giving complete access to directories such as /sys or /proc (kernel interfaces known for information leaks), rather than allowing fine-grained access to only the required files,

I can not believe this is an actual point that's brought up. Flatpak isolates the container's /proc using a fresh pidns, and the app runs as PID2 inside the container (screenshot attached). /sys doesn't let you magically take over the system. You need root access to do anything malicious with /sys, and the info leak isn't within the scope of Flatpak, at least for today.

and the highly permissive seccomp filter which only blacklists ~20 syscalls and still exposes significant kernel attack surface.

Flatpak isolates the syscalls that could cause issues via Seccomp. The main objective here is to maintain the integrity of the sandbox. Flatpak's security model relies on the sandboxed application not being able to attain the permissions necessary to create a new userns and mountns.

Kernel attack surface is a non–issue. Linux is one of the most audited pieces of software ever. The likelihood of someone finding a local root or namespace escape exploit while not even using the namespace syscalls is comically low. If someone had found such exploit, they would not use it on you. That is a billion dollar 0–day right there.

postscript

sharing articles like these with people that might not know better is not bettering the linux desktop. it only makes the community more fragmented. it's kind of like flat earthers if you think about it.