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

https://flatkill.org/2020/

by dulvui • 2 years ago

44 41 2 years ago

aborsy• 2 years ago

One issue is that the permissions are hard to understand.

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.

gkhartman• 2 years ago

I agree. I tend to avoid flatpak, since I don't usually have the time to debug access issues. The desktop integration doesn't seem good enough to give me an allow/block dialog each time. The current situation of "is the app I need a snap|flatpak|$os_pkg_format_here" seems to add a lot of fatigue to the experience.

ajross• 2 years ago

Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions

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?

EdwardDiego2• 2 years ago

Yeah, complaining that an IDE wants access to your FS is odd. Like, that's where the files are.

yencabulator2• 2 years ago

An IDE should get access to the specific directory that contains the project, not everything.

masspro• 2 years ago

Devil’s advocate on the last point about the libssh vuln: it would be in a sandbox, but if you do take that with the commentary that most apps have large areas of sandboxing disabled, then the sandbox isn’t effective in stopping exploitation of a vulnerability and the flatpak model has increased the chance of there being a vuln in the first place because bundled outdated deps are the natural end state of a flatpak without constant intervention.

nxicvyvy• 2 years ago

Flatpack etc sandbox is shoehorned into a system that doesn't expect it.

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.

yjftsjthsd-h• 2 years ago

> The first app on Flathub I find to use libssh2 library is Gitg and, indeed, it does ship with unpatched libssh2.
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

Now instead of the lack of useful sandboxing reducing you to the same absence of protection as native distro packages, you're worse off.

realusername4• 2 years ago

I really don't think the app model makes any sense for a Linux desktop anyways.

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.

nightowl_games• 2 years ago

That's not a sufficient level of trust. The author should basically never be trusted and it's extremely difficult to verify that the source of what's available is the same as what's in the binary that you downloaded.

Just look at the xz backdoor... "Author trusted"...

realusername4• 2 years ago

I will always prefer "trust the developers" Linux model to "trust the manufacturers" that you have on mobile.

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.

jcastro• 2 years ago

On the contrary, giving Gimp/Krita/VLC root access to my computer makes no sense to me.

Do people think that distribution developers are hand combing through all those apps? Untrusted by default is more scalable.

cassianoleal6• 2 years ago

giving Gimp/Krita/VLC root access to my computer

Why would you give those apps root access?

viraptor2• 2 years ago

Trust is a part of security. "The developer is untrusted and may download a copy of all my emails if given access" is definitely a security / access control concern.

realusername4• 2 years ago

Then maybe it should not be accessible in the repository then if there's any doubt about the software.

NewJazz6• 2 years ago

Uh... No.

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.

realusername4• 2 years ago

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.

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.

hi-v-rocknroll• 2 years ago

Yep. I refuse to touch it. But we need a usable (and more documented) "QubeOS" including curated "app store" and app containment with overlay filesystems to separate data, OS, and application concerns sanely, predictably, and securely. XCP-ng implements O_DIRECT that allows zfs to be used as a backing store.

karmakaze• 2 years ago

This report would be better received if it wasn't from 4 years ago and posted on a domain named flatkill.org--seems 'politicized'.

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.

Vilian2• 2 years ago

and most of the issues debunked by the flatpak dev, and bottles developer, in that same year, 4 years after that steam deck recomends flatpak, and portals are a lot more mature, that site need tobe taken down lmao

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

Related Stories