Flatpak – a security nightmare – 2 years later (2020)

Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work. And you paid $10 for it. You uninstall, reinstall, and 'Allow'.

(Majority of) People barely understand the (privacy/security) impact of giving access to Location, Contacts, Calendar, Phone, SMS. Now think of the more obscure (?) layers of the following pyramid: Hardware, Middleware/Drivers, OS, Applications. (Majority of) People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!

Although both A&G can review your code and flag these upfront with some auto-policy-check, I feel that it would send many app creators reeling & pain. Pain for app creators = smaller revenue to A&G.

I assume it's the typical cat & mouse game. A&G may try to reduce/prevent access here but their SDKs will create a new oppotrunity/workaround to get access there. The new "there" access will be abused and someone will find away to do what they were doing in the previous setup. And thus we restart the chase.

It's in the way that people code. Naughty and/or lazy coders will go for the keys to the kingdom, ignoring the security. To avoid misunderstanding the word 'lazy' doesn't mean 'lazy people', but 'lazy/inapprpriate/corner-cutting practices'.

In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a permission only for that file for a limited time e.g. only to read it once. Also there is no easy way to know what these apps send over network. How do I know they are not downloading all my documents to China?

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, and a number of tools installed via pip or directly downloaded from github. (In fact, you probably use Linux on desktop in order to do all these things, because it makes life easier.) And many users aren't even really aware of the contents of their .bashrc and such.

So, is there a security problem with Linux desktop? Yes, absolutely. And it is serious enough to worry for those who are not paranoid security enthusiasts (I mean, even real vulnerabilities aren't truly a concern to many users, but we have to admit there is a problem, when it becomes quite evident, that Linux starts falling behind both MacOS and Windows in this regard). But is flatpak the culprit? No, not really. Linux on desktop in 2021 is just really flawed (at least security-wise).

This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating or something.

I decided to look at the messaging - the websites of both Flatpak[0] and Snap[1] make no claims about security, or about being "designed to be built by less-trusted parties".

Both of them focus more heavily on the convenience of distribution than any user-facing benefits such as sandboxing.

If you're referring to the GNOME Software "Sandboxed" badge, it still indicates that there are some universal properties of the sandbox. (For example, flatpak apps live in their own PID namespace and cannot see what other processes are running on your system.) Also, there is a permissions badge on the right that does indicate the level of access you'd be granting to the app. (Full $HOME access is indicated with High, and a click on the badge tells you exactly what it needs.) There could be some work needed to do around guarding `.bashrc` and similar, though.

In addition, Flatpaks and Snaps are both served as repos - a `.flatpakref` for instance is just a reference to a repo. Using a `.flatpakref` to install software is like adding a repo to your sources.list, but in ways more secure:

1) Flatpak doesn't have the concept of install scripts (and doesn't have a way to install a setuid binary), so just installing an app won't cause a security hole. On the other hand, a `.deb`/`.rpm` can run arbitrary code as root in the install scripts.

2) Packages on Flatpak are scoped to the repo you installed them from - for example, if you request `org.gnome.Calculator` from flathub, another repo can't serve version 10000 of the same app and have users install it. If the same app is available on multiple repos, flatpak will prompt you and ask what version to install.

example output for `flatpak install org.gnome.Calculator`:

Remotes found with refs similar to ‘org.gnome.Calculator’:

   1) ‘fedora’ (system)
   2) ‘flathub’ (system)

[0]: https://flatpak.org [1]: https://snapcraft.io