Flatpak – a security nightmare – 2 years later (2020)(flatkill.org) |
Flatpak – a security nightmare – 2 years later (2020)(flatkill.org) |
The end user doesn’t know, like, what bus-xyz or a socket is and if this app needs it!
The permissions may also change over time. Like a PDF reader may not need a particular permission unless you open a link or play an audio.
The apps have to be shipped in restricted mode, and ask user-understandable permissions. Basically, like phones.
Any shortcomings of sandboxing has to be compared with something else to be practically meaningful. A sandbox that works when an application is appropriately packaged is better than not running in one for all applications.
This is way oversold. That's true of "all popular apps" because those apps are legacy things written to run in the host filesystem and store state to the home directory. And there are good reasons to want to do this.
That's not an indictment of the technology, that's just saying that Thunderbird or whatever hasn't been ported to run in a sandbox yet. I mean, yeah. But why complain about the perfectly good sandbox technology and not the app?
Edit: this one is even worse:
> 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.
So, that's a ssh client vulnerability. And indeed, you absolutely want your apps to ship current binaries with vulnerabilities patched, and this app didn't. So isn't it a good thing you deployed that app in a sandbox? Again, why complain about Flatpak when it likely is what's saving you from a client vulnerability?
You can't expect apps to migrate to something that a) promises to support the existing model, and b) also support the existing model.
What these app package formats should be doing is coming up with a new model and then asking people to support their model as if it were a new platform.
Similar to how thunderbird supports Linux Mac and windows.
That might actually result in both an access model that makes sense to end users and actually creates an app package formats that isn't full of trade offs and work arounds.
> So isn't it a good thing you deployed that app in a sandbox? Again, why complain about Flatpak when it likely is what's saving you from a client vulnerability?
Because it's not!
https://flathub.org/apps/org.gnome.gitg
> gitg is potentially unsafe
Full file system read/write access
Can read and write all data on the file system
User runtime subfolder keyring
Can read and write all data in the directory
Network access
Has network access
You need this sandboxing on the phone not because of security but because the developer of the app is untrusted, that's the opposite of Gimp / Krita / VLC or whatever else is packaged where the author is trusted and the sources are available.
Do people think that distribution developers are hand combing through all those apps? Untrusted by default is more scalable.
Why would you give those apps root access?
Just look at the xz backdoor... "Author trusted"...
Sandboxing just puts the problem one level higher and doesn't remove it.
Then on the subject of the xz backdoor, nothing is safe from that kind of attack.
We are always going to have much greater confidence in the security of the base OS than the security of random apps in the ecosystem.
You named some great applications that have seen a lot of scrutiny... But what if someone installs a malicious gimp plugin, or wants to use a closed source app like discord? Your argument falls apart quickly.
Where exactly is that true? Certainly not on mobile. There's a reason why I don't put anything sensitive on it...
And on Linux I'd say it's about the same for both.
For closed source apps I agree with that and something like snap/flatpack is maybe a better model for them.
On workstations, glibc and coreutils see a lot more attention than e.g. xonotic.
The solution is choosing an acceptable level of trust and putting safeguards like sandboxing where possible. (And ideally monitoring on the possible violations)
It's much harder to make a trust bet like that than, in principle, to make a local decision like "Hmm, why is the xz tool requesting access to the ssh port? That doesn't seem right"
In other words, sandboxing based on permissions, without loosing the advantages of having fine-grained control over dependencies.
Flatpak is a step forward in terms of sandboxing, but a step back in terms of dependency control.
I feel that users like me are far more prevalent than users who want to rigorously audit every path the IDE may want to open.
Vscode on snap runs unconfined for example, that's explicit
Easy to get root anyway, just add an alias to sudo to .bashrc and whenever the user follows an online instruction guide into fixing something they'll get root privileges.
or overwrite LD_PRELOAD for the user
or replace the users desktop files and pretend to be another application (because you can overwrite /usr/share/applications launchers in .local/share/applications)
You shouldn't but you install debs/rpms from the internet which get root permissions during install.
As in, any unrestricted process with user privileges on Linux can up to root through vulnerabilities in the kernel or other components. Namespaces, LSMs, and seccomp limit that exposure.
Not that it makes a huge difference in practice, IMO. The apps most users run (i.e. distro apps) are plenty trusty for normal threat models. Apps that run real untrusted code (web browser) have their own sandboxes. And people with more serious threat models can run qubes or tails or whatever
> unrestricted process with user privileges on Linux can up to root through vulnerabilities in the kernel or other components
Getting pwnd via vulnerabilities is very different from giving root access. You're arguing with a strawman, I'd rather not engage.