9 ms·

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

44 points by dulvui 2y ago

aborsy 2y 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 2y 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 2y 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?
- EdwardDiego 2y ago
  Yeah, complaining that an IDE wants access to your FS is odd. Like, that's where the files are.
  - yencabulator 2y ago
    An IDE should get access to the specific directory that contains the project, not everything.
    - EdwardDiego 2y ago
      Okay. But I have more than one project. And sometimes, I want to use my IDE to open /tmp/foo.json that I just curled out. 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.
      - brennoflavio 2y ago
        The article complains about saying that the app is sandboxed. I don't want my ide to be sandboxed anyway, so just flagging that in the store should be enough. Vscode on snap runs unconfined for example, that's explicit
      - yencabulator 2y ago
        The "portals" mechanism can dynamically allow access to anything you pick in a file open dialog, while helping the app sandboxed.
- masspro 2y 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.
realusername 2y 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 2y 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"...
  - realusername 2y 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 2y 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.
  - cassianoleal 2y ago
    > giving Gimp/Krita/VLC root access to my computer Why would you give those apps root access?
    - NewJazz 2y ago
      Local privilege escalation.
deleted 2y ago
[deleted]
hi-v-rocknroll 2y 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 2y 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.
- Vilian 2y 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

44 points by dulvui 2y 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 2y 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 2y 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?

EdwardDiego 2y ago
Yeah, complaining that an IDE wants access to your FS is odd. Like, that's where the files are.
- yencabulator 2y ago
  An IDE should get access to the specific directory that contains the project, not everything.
  - EdwardDiego 2y ago
    Okay. But I have more than one project. And sometimes, I want to use my IDE to open /tmp/foo.json that I just curled out. 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.
    - brennoflavio 2y ago
      The article complains about saying that the app is sandboxed. I don't want my ide to be sandboxed anyway, so just flagging that in the store should be enough. Vscode on snap runs unconfined for example, that's explicit
    - yencabulator 2y ago
      The "portals" mechanism can dynamically allow access to anything you pick in a file open dialog, while helping the app sandboxed.
masspro 2y 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.

realusername 2y 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 2y 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"...
- realusername 2y 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 2y 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.
- cassianoleal 2y ago
  > giving Gimp/Krita/VLC root access to my computer Why would you give those apps root access?
  - NewJazz 2y ago
    Local privilege escalation.

deleted 2y ago

[deleted]

hi-v-rocknroll 2y 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 2y 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.

Vilian 2y 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