[HN Gopher] Flatpak - a security nightmare - 2 years later (2020)
___________________________________________________________________
Flatpak - a security nightmare - 2 years later (2020)
Author : dulvui
Score : 30 points
Date : 2024-05-11 21:41 UTC (1 hours ago)
(HTM) web link (flatkill.org)
(TXT) w3m dump (flatkill.org)
| aborsy wrote:
| 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 wrote:
| 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 wrote:
| > 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?
| EdwardDiego wrote:
| Yeah, complaining that an IDE wants access to your FS is odd.
| Like, that's where the files are.
| masspro wrote:
| 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 wrote:
| 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.
| realusername wrote:
| 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 wrote:
| 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"...
| realusername wrote:
| 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 wrote:
| 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.
| cassianoleal wrote:
| > giving Gimp/Krita/VLC root access to my computer
|
| Why would you give those apps root access?
| NewJazz wrote:
| Local privilege escalation.
| viraptor wrote:
| 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.
| realusername wrote:
| Then maybe it should not be accessible in the repository then
| if there's any doubt about the software.
| habitue wrote:
| This is too one size fits all. It's either "every package
| is untrusted" so the repo is useless, or it's "there's too
| many people to keep track of the trust level of" which is
| insecure.
|
| 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"
| nextos wrote:
| What we need is something orthogonal to package managers,
| something like Firejail or bwrap.
|
| 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.
| NewJazz wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-11 23:01 UTC)