A newly launched website is warning users about Flatpak, branding the tech a “security nightmare”.

The ‘Flatkills.org’ web page takes aim at a number of security claims routinely associated with the fledgling Flatpak app packaging and distribution format.

Three areas are flagged by the site — which is currently doing the rounds on social media — that its author contends are not readily apparent to users:

Many Flatpak apps have filesystem write permission

Most Flatpak apps do not run in a sandbox

Slow/no critical security updates to apps and runtimes

Examples of the alleged shortcomings are provided by the author of the site, who goes on to conclude that:

“The way we package and distribute desktop applications on Linux surely needs to be rethinked, sadly flatpak is introducing more problems than it is solving.”

Flatkills.org is asking users who think Flatpak is a safe and secure way to get apps on Linux to think again.

But should they?

Flatpak Security: should you be worried?

Blunt though the viral website is it is clear that the author behind it cares about the Linux desktop, user expectations, and application security.

After all: no-one goes to the effort of launching an entire website solely for a wheeze.

That said, the concerns listed on Flatkills.org are not, to my mind, problems with Flatpak itself but with Linux app distribution in general.

For one, all of security features that Flatpak touts in its documentation and makes hay with in marketing materials are available. The “problem” is not that these controls don’t exist (they do) but that most app developers distributing Flatpak apps choose not to make use of them.

The problem is not that sandboxing don’t exist (it does) but that app devs choose not to use of it

Apps like GIMP, Vscode and Lollypop ship with broad permission sets (which users are made aware of when installing using the Flatpak CLI but not in a GUI install) by default.

This isn’t a flaw in anything other than motivation; for these apps to ‘do what they do’ many packagers idly request both read/write access to the home folder instead of using other mechanisms available.

Again, this situation is not unique to Flatpak or to the Flathub app store. Many popular Snap apps don’t make use of ‘strict confinement’, either.

But settings related to sandboxing and permissions (or lack thereof) is decided by the application packager, not the creator of the format.

Perhaps Flatpak could throw up a GUI permission dialog to ask for file system write permission on first run? Or list (again via a GUI) which permissions an app requires before the users install it (like Android used to)?

But we’re talking about a technology that only recently hit version 1.0 — it’s not going to reach perfection overnight.

For what it’s worth Flatpak developers are working on an improved app permissions model with ‘Portals‘. These allow granular control of permissions:

“Portals are high-level session bus APIs that provide selective access to resources to sandboxed applications. The implicit expectation of portals is that the user will always be involved in granting or rejecting a portal request, thus most portal APIs will lead to user interaction in the form of dialogs.”

Among the planned portals is a “file chooser”. This will provide sandboxed apps indirect access to files, but with the user staying in control of which files can or cannot be opened.

Apps get the permissions they need to run efficiently, but without the drawback of having permission to everything.

I’m a big fan of Snap apps permission model, which lets you check in on and revoke app permissions at any time, for both ‘strict’ snaps (which can’t write to ./*) and ‘classic’ snaps (which can), from the Ubuntu Software. Flatpak has similar controls too, albeit from the CLI.

That said, and again like Snap apps running in classic mode, the notion of “sandboxing” isn’t quite as water-tight as the marketing merits make out.

But if idea of Flatpaks enjoying unbridled access to your home folder may sound scary but if you install apps from PPAs, an OBS or other third-party repos you’re exposed to the exact same risks only worse — those apps will have root!

Solutions will come

Flatpak is still a (relatively) new technology. It’s perhaps a little unfair to expect it to have addressed all use case, scenarios and problems off the bat. Like any good open source tech Flatpak is evolving, and so is the ecosystem and those within it.

Also: Flatpak ≠ Flathub; distros could (in theory) host their Flatpak store with stricter update or permission model requirements.

On the plus side, solutions will emerge as and when problems are flagged up. And as Flatpak becomes more popular people will have more opinions on it, not all of them encouraging. But open discourse is a valid part of the open source process.

The Flatkills website is blunt (and perhaps a little dramatic) but it touches on points of contention that are, at their heart, valid, and do, in various ways, need work or further refinement.

But unlike the website I don’t think there needs to be a “rethink” of Flatpak, just a better understanding of the features and capabilities it does — and sometimes does not — support.