13 ms·

Flatpak – A Security Nightmare (2018)

218 points by fao_ 6y ago

blendergeek 6y ago
Unless this has been updated since 2018 (it doesn't have a date but also looks like it still from 2018) it should be marked [2018]. Also: Here is previous discussion from around the time this website was created: https://news.ycombinator.com/item?id=18180017 https://news.ycombinator.com/item?id=18180017
- nominated1 6y ago
  > Unless this has been updated since 2018 I think this might also apply to Flatpak. Has Flatpak addressed any of these concerns? If so, how?
  - arghwhat 6y ago
    That's not how this works. Old content is marked with its year, irrespective of its relevance.
- floatingatoll 6y ago
  https://web.archive.org/web/diff/20181013065735/20200615030544/http://flatkill.org/ https://web.archive.org/web/diff/20181013065735/202006150305... doesn't show any differences.
inshadows 6y ago
As opposed to what? To how I run GIMP in the past? Certainly not. > Look ma, I've discovered a program can do nefarious things What else is new?
- Gaelan 6y ago
  I mean, there's an argument that this is worse. If a security bug is found in libc, in the "old world," your distro would have an update out in a day, and you'd be completely safe. With flatpak, you also depend on whoever's maintaining the GIMP flatpak (and all your other apps), who may not be motivated to do updates any faster than GIMP's normal release schedule, potentially leaving you vulnerable for much longer.
  - secabeen 6y ago
    This is also the case for server containers, and I do worry about the day that some critical low level library that is in thousands of containers has a security bug. Yes, many shops are using CI to push out new containers regularly. Others are deploying containers from third-parties, without any regular updates or path to fixing security problems.
  - tracker1 6y ago
    And for a lot of smaller apps, they're unable to realistically support being distributed in many different distributions. Flathub is cross-distro and easier for the app author/developer/maintainer to support. Is it perfect, no... is it actually much more secure, not usually. All of that said, is it available in pretty much every linux distribution and often a newer version than what would be in the repositories, absolutely.
  - outsomnia 6y ago
    > your distro would have an update out in a day, and you'd be completely safe If you do not restart your services after updating the package, your services continue to run against the exact libs they were started with, even though the library is updated on disk and anything new that starts will use the fixed version. For something like the libc, that is pretty much every service bringing it in and still running the unpatched version of the library. Updating distro packages is of course usually a good thing, but alone it does not make you "completely safe". Also they have a patched version "in a day" because they embargoed public release of the vuln details usually for months, creating a gap where a (growing...) set of people know a secret that can compromise your system and you don't. When I get that update I don't feel "completely safe".
  - jhasse 6y ago
    libc is part of the Freedesktop runtime, so the GIMP Flatpak doesn't need to update.
- JadeNB 6y ago
  > > Look ma, I've discovered a program can do nefarious things > What else is new? I think that this dismissal (which presents as a quote something that doesn't seem to appear in the original article) is too hasty. Surely exactly the same could be said of any submission involving, say, privilege escalation? Of course every program and means of distribution has security risks, and their existence isn't news; but documenting the specific risks is surely worth it.
  - inshadows 6y ago
    Well, as every direct reply said, it is true that these App Store models suffer from possibly outdated libraries with unpatched security bugs. But it's nothing new. Everybody knows that. It's case with Docker and all other fat bundle formats. > Sadly, it's obvious Red Hat developers working on flatpak do not care about security Presenting it as a novel privilege escalation with such wording IMO deserves hasty dismissal. These kinds of "hype-ridden disclosures" (i.e. allocating domain name) deserve to be ridiculed because they're meaningless distractions. See [1] for discussion. [1] https://lwn.net/Articles/668695/ https://lwn.net/Articles/668695/
    - pie_flavor 6y ago
      All the other formats talk about how easy they are to use, and when you mention security, they throw up their hands and say "I dunno". Flatpak, on the other hand, its entire shtick is how applications are sandboxed for security.
      - inshadows 6y ago
        And flatpak is actually sandboxed for security. So what's your point? The only news the author of this hype website told us is that 1) there was a vulnerability, 2) lots of application have broad privileges and 3) apps have bundled dependencies. -- 1) Bugs happen. Deal with it. 2) Flatpak actually tells you which privileges an app is going to use. What do you suggest as a solution? Is it technical problem or social problem? What is the state of art? I'd say the state of Art is Android in that it asks for permissions individually as they're required. Still, this problem is not fundamental issue in Flatpak. It certainly doesn't deserve "Flatkill" logo and domain. 3) Is Flatpak actually an exception to the rule? - Making Python app? Use pyenv, pipenv, venv or ${popular_venv_of_the_year} and bundle all your dependencies! - Making .NET app? Use NuGet and bundle all your DLLs! - Making Java app? Use Maven, Gradle, SBT and bundle all your JARs! - Making Rust app? Use Cargo and glue everything together. - Etc. Etc. So yeah, for every programming language we're encouraged to treat our dependencies as unique, fix their versions to prevent possible breakages and take the responsibility for monitoring security issues. Developers just like it. I don't like it but it's everywhere. And as other posters said, Flatpak actually have runtimes which carry core dependencies like libc that get updated independently of the app. So what is the novelty here deserving the flatkill domain? Where is that juicy security vulnerability?
- michaelmrose 6y ago
  Aside from security updates being delivered between late and never if they are ever compromised 1/3 of users will be effected in the first hour and 100% effected within 24 hours even if on the 25th hour they discover it and take it down. In the old school situation distributions would still be between days to weeks deciding to pull in a new version released through normal channels.
jsnell 6y ago
So Flatpaks also install under /var? That's horrible, I thought it was only Snaps that made that decision :( Does anyone know what the official reasoning for this is?
- bepvte 6y ago
  Flatpaks use a git-like tree of hashes, which cant just be shoved into random places on your filesystem. It has an exports directory you can symlink or add to your path.
  - mariocesar 6y ago
    or you can install in your user directory, current cli of flatpak ask you for this and you can set the default install option for the user directory also
  - mikepurvis 6y ago
    In that case it should be in /opt, where application bundles not managed by the system's primary packaging system belong.
    - Spivak 6y ago
      This isn’t technically correct when Flatpak is installed via your distribution. Then it is managed by your packaging system and it’s data should live in a /var/lib. /opt is for software that doesn’t adhere to the FHS and can’t/shouldn’t be installed in a prefix. Red Hat and Arch install software to /opt via their official package managers. /opt isn’t safe to stick arbitrary software even though it’s commonly used for that — /opt/local is the non-FHS equivalent of /usr/local.
    - reactor4 6y ago
      Agreed, that's what /opt is for.
    - dylan-m 6y ago
      > This isn’t technically correct when Flatpak is installed via your distribution. Then it is managed by your packaging system and it’s data should live in a /var/lib. Besides, this is silly: they go in /var/lib/flatpak, which is for flatpak's program state information. (Exported desktop files and whatnot go to /var/lib/flatpak/exports/, which is pointed to by `$XDG_DATA_DIRS`). I mean, if you want to go all Militant Unix Admin on it and install apps to /opt, you can `man flatpak` and set `FLATPAK_SYSTEM_DIR=/opt/flatpak`, but unless your system spans a dozen hard drives I'm not sure what that's going to achieve. I guess this is sort of an ownership conundrum: a flatpak app is run _via_ flatpak. On its own, it's just a heap of files.
bepvte 6y ago
I still love flatpak, and much of what this article states is hostile and outdated. The "XDG portal" specification makes filesystem access less popular then before. Also, "fakepak"? Really?
gavinray 6y ago
Am I the only person who actually doesn't really mind that flatpaks and snaps have less user-control over behavior and/or security implications? I really enjoy them. Install it, forget about it, let it update automatically. Theoretically could something unwanted happen, yeah probably, but I enjoy the convenience they provide and typically you're installing fairly well-known software (Microk8s, VS Code, and Chromium come to mind). My one gripe with snaps is that AppArmor can occasionally cause headaches with Microk8s permissions.
- monadic2 6y ago
  I just wish they separated out the functionality of app portability, app sandboxing, and app installation. It’s much less debuggable and comprehensible packaged together. Kind of reminds me of systemd, actually.
  - viraptor 6y ago
    I don't think you can separate sandboxing and installation. Any nontrivial and useful sandboxing relies heavily on how / where the app lives and how it communicates with the world. This includes things like dbus paths too, not just file paths.
    - monadic2 6y ago
      Well, it’s a problem the floss community will have to deal with sooner or later—it feels pretty awkwardly papered over with snap.
      - viraptor 6y ago
        The other way is to rely on labels rather than names. But I don't see every distro switching to selinux with per-flatpak/snap policies, so it's going to be have to be joined installation and sandboxing.
        monadic2 6y ago
axaxs 6y ago
I don't understand why people favor Snap or Flatpak to Appimage, which looks to be the simplest of the three. Would anyone mind sharing their experiences?
- devbat8712 6y ago
  I've found appimages to be a bit of a pain in the past because they're portable, so you need to have a place to put them
- suby 6y ago
  Appimages don't update automatically.
  - Polylactic_acid 6y ago
    And they aren't integrated in to the OS like snap or flatpak. I can install/update a flatpak and it shows up in the program menu. For appimage I have to open my filemanager and click on the program like a prehistoric windows user. Also last time I read the OP article the tldr is "Flatpak has security options but many packages turn them off making them exactly as secure as appimage/binaries from a package manager"
    - suby 6y ago
      I think this is something that can eventually be fixed. Indeed, I'm on Linux Mint and the integration is actually pretty good. When you first run an appimage it asks if you'd like to add the program to the start menu. Icons are correct and everything. I can also imagine some possible ways to allow appimages to auto update, though I suspect there'd be a lot of resistance to that.
      - Polylactic_acid 6y ago
        I'm not really aware of a single way appimage would be better than flatpak. To get the integration and updating working you would need to install a tool and not having to install something for appimage is the only benefit I see over flatpak. It makes it easier to just quickly download and runs something but less convenient in the long run. Also in the future I can see apps being built to actually use the permissions system in flatpak so it doesn't have to be disabled. Flatpak is a step forwards for linux where as appimage is restoring bad practices from windows.
LeoPanthera 6y ago
This page is really old, but I disagree with "the users are misled to believe the apps run sandboxed". I think most people use flatpak (and/or snap, appimage, etc.) as a way of installing applications in a way that does not contaminate the host OS, and a way of removing them again without leaving any traces behind. For example, it's an extremely convenient way of installing Steam without having to worry about its obscure, 32-bit, dependencies. That they are sandboxed, or not, is very much secondary, for most users, I believe.
- livre 6y ago
  As a user and someone who knows nothing about flatpak other than "it can install apps" what you said is true. I use flatpak and appimage because they allow me to use software without cluttering my /bin and other root subdirectories. And also because I can install with them software that my distro does not include in its repositories. All resides in my home and it's easy to remove without leaving any traces. I didn't know flatpak apps were supposed to be sandboxed until I read this article when it was posted a few years ago. Whenever I want to sandbox something I use firejail.
- gentleman11 6y ago
  What I know about flatpak was from some Linux you tubers who led me to believe it was a sandbox. For that matter, some hn users posted similar things in the last month when talking about snaps iirc
  - vetinari 6y ago
    Flatpak has a sandbox; but for some apps, it has to be a more open, otherwise they would not work as intended. All that's open is visible as a flatpak permission; if you want, you can tighten it up and see, what breaks. On the other side spectrum are people, that are disappointed, that they cannot use SDKs installed at random places in their host system with editors packaged with Flatpak. Well, duh...
- trevyn 6y ago
  Someone might want to fix the Wikipedia, then: “Flatpak is a utility for software deployment and package management for Linux. It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system.” https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak
davidhyde 6y ago
No https redirect and the post is about security.
- SkyMarshal 6y ago
  I get the optics aren't great. But, if you check the source, this is a single HTML + CSS page with zero scripts or forms. Does it matter, technically?
  - tracker1 6y ago
    Considering ISPs and Nation states have injected additional scripts into plain HTML payloads, it does matter, technically.
  - the_hoser 6y ago
    It really, really does.
    - bandrami 6y ago
      How? I don't trust the site's author, so from a security standpoint there's nothing gained by distinguishing him from an impersonator.
      - the_hoser 6y ago
        Do you trust your ISP/Government/Router to not inject spyware/malware into the pages you visit?
        bandrami 6y ago
        That's literally what I just said. I don't trust the site's author any more than I trust an ISP/Government/Router.
- AlexCoventry 6y ago
  http://n-gate.com/software/2017/07/12/0/ http://n-gate.com/software/2017/07/12/0/
evross 6y ago
A great talk on Flatpak sandboxing was released in March. [1]. The original post is from 2018 (Flatpak 1.0). Not sure if these issues are completely fixed yet, there are a lot of release notes up to version 1.63 (stable). [2] It seems that the maintainers and community are working on improving security continuously. My main hope is that they optimize for privacy, security and user control of the packages. Overall I'm impressed by flatpak with it's cross-distribution packaging. [1] https://www.youtube.com/watch?v=3rCIEzfZw1I https://www.youtube.com/watch?v=3rCIEzfZw1I [2] https://github.com/flatpak/flatpak/releases https://github.com/flatpak/flatpak/releases
- mongol 6y ago
  Did you see it live? Not a great experience on Youtube, audio problems unfortunately.
  - evross 6y ago
    I found it through search on Youtube, had been looking for which way to package applications on Linux. Packaging really takes a bit of time, reading documentation and figuring out how to do it. After packaging a flatpak you need to add it to a local repository on your device before you can test install it, which isn't as intuitive as clicking on a .appimage file, but brings some benefits. The documentation is quite readable: https://docs.flatpak.org/en/latest/first-build.html https://docs.flatpak.org/en/latest/first-build.html. Agreed for audio quality. It's hard to listen to with only the left channel working. It might be worth reuploading it with balanced stereo.
Thorrez 6y ago
> The criticial vulnerability "shell in the ghost" was fixed in flatpak about one month after linux distributions. I can't find any reference to that vulnerability except this page.
- pmontra 6y ago
  The name isn't an exact match but maybe it's this glibc vulnerability: https://blog.qualys.com/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability https://blog.qualys.com/laws-of-vulnerabilities/2015/01/27/t... Edit: nope, this is Ghost in the Shell, from last February https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/ https://www.microsoft.com/security/blog/2020/02/04/ghost-in-...
  - Thorrez 6y ago
    I don't think either one is right. That first one is from Jan 2015, but according to Wikipedia the first release of Flatpack was Sept 2015. The second one doesn't even seem to be a vulnerability, but rather the general concept of web shells. One of the vulnerabilities mentioned in the article (CVE-2019-0604) is for Microsoft SharePoint, so that's unrelated to Flatpack. Also note the difference in order of the words "ghost" and "shell".
gentleman11 6y ago
> Yes, it's possible your linux box has been compromised if you use flatpak, we are literally talking about several months old public exploits. Ever opened an image in flatpak Gimp? The criticial vulnerability "shell in the ghost" was fixed in flatpak about one month after linux distributions. There were some heavily up voted comments and posts on hn this year about how much people hate how snaps auto update themselves. Does this change anyone’s mind, or do those points still stand?
- AlexandrB 6y ago
  Those points are completely unrelated to flatpak taking a long time to release patches. Whether flatpak forced updates or not, from TFA it seems as though it's still months behind Linux distros.
arminiusreturns 6y ago
I will use appimage. I refuse to use flatpak or snaps. That's my take as a linux user and admin.
thayne 6y ago
> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue. The actual wording in the linked release is "This is a minor security update, matching the behaviour on master where we avoid ever creating setuid files or world-writable directories." The wording is perhaps a little ambiguous, but my interpretation of that is, "this is a minor update that fixes a security issue," not "this is an update that fixes a minor security issue." The author also implies that simply including a setuid binary would allow the app itself to get elevated privileges. This seems at odds with the way flatpak uses containers to sandbox the app, and in fact when I looked at the linked CVE, the actual vulnerability is that a seperate attack could use a setuid binary installed as part of a flatpak to get privilege escalation. Don't get me wrong, it's still a sever vulnerability. But it is much more difficult to exploit than the author first led me to believe.
- choeger 6y ago
  Add to that the first paragraph, which is literally a complaint that flatpack does not make things better compared to rpm. Indeed the one about security updates is valid and my biggest grievance with such an approach. Note, however, that propietary software like sublime could easily use statically linked or embedded libraries anyways, as they do not have to adhere to any packaging guidelines. So this applies only to free software that has been packaged with the distro.
  - vetinari 6y ago
    > Indeed the one about security updates is valid and my biggest grievance with such an approach. And that stems from misunderstanding. Flatpak has a concept of runtimes. If you have some basic library that would be updated by your distribution, you have pretty much big chance that it would be part of the runtime and updated by runtime maintainers, not by the application authors. I.e. you would get your security updates, subject to the maintenance period of the runtime (for example, the org.freedesktop.Platform has 2-year support).
    - danieldk 6y ago
deleted 6y ago
[deleted]
akho 6y ago
Flatpak mixes together application packaging, sandboxing, desktop integration, and an update mechanism. I do not understand the need to have all four in the same tool. I even think it limits the usefulness of each component. Would a combination AppImage, firejail, and a couple of shell scripts be worse?
- dylan-m 6y ago
  Much worse. I encourage you to try some properly sandboxed Flatpak apps. Here's a fun one: https://flathub.org/apps/details/com.github.maoschanz.drawing https://flathub.org/apps/details/com.github.maoschanz.drawin... Note that the app has no access to your home directory by default, and this fact is invisible to the end user. The file open and save dialog is handled out of process by a portal, which is a service that allows an application to (with permission) poke holes in its sandbox. By tying a few different things together, this is seamless: the user gets a file chooser dialog and chooses a file, as usual. (As a bonus, it's always a native dialog). Behind the scenes, the application is granted access to read or write to that file. I don't think this would be easy to manage if Flatpak was split into a bunch of different moving parts, and I can't imagine it providing any meaningful benefit. With that said, it isn't as monolithic as folks seem to think. It's built on bubblewrap and ostree and a whole bunch of freedesktop specifications.
bonestormii_ 6y ago
The moment you delegate your security or stability concerns to a third party, all bets are off. Period. Package maintainers, RedHat, whoever. Maybe the patch fixes a vulnerability, maybe it creates one. Maybe the company pushing security is really pushing mindshares of ecosystems for subscription revenue and industry influence. Build from source; keep your packages as minimal as possible; keep your permissions as granular and restricted as you can manage; and pray to your gods of choice. I can't understand why people are so anxious to embrace so much unneeded complexity. Things that "just work" always just work until they just don't.
- kelnos 6y ago
  I'm pretty sure "build from source" is out of reach for most people (from a technical ability standpoint), and for those who could do that, most have better things to do with their time. If your threat model includes intentionally malicious packages from Red Hat, Debian, or whomever, ok, but understand that you're a miniscule fraction of a percent of the user base. And you'd better be auditing the source that you compile as well.
  - ownagefool 6y ago
    The words "threat model" gets thrown around, but I'm not actually sure "our threat model didn't include our OS vendor" would be considered an acceptable excuse. Sure, we have reasons to trust Redhat; - You can look at their working practices ( Good coding hygiene, Peer Review, Tools, etc ) - You can make the commercial argument ( they make money by doing the right thing, it's not in their interest to hack us ) But ultimately we're still explicitly trusting 1000s of people here, so reality is much more nuanced. - Hardern your OS, i.e. only install the bare essentials. - Monitoring for processes or networking traffic doing unexpected things. Thus, you evidence that you reasonably trust the vendor but you'd expect to see an alert were to prove false. Probably a better use of "threat model" would be, we don't need to place trust in developer end user devices because we instead place our trust in our SCM, CI/CD and the SDLC process.
    - kelnos 6y ago
Iolaum 6y ago
This article is written in bad faith. RE: The sandbox is a lie. No it's not. The technical capabilities are there. The problem is that the application needs to be written a certain way in order for the sandbox to be enforced and the app not to break. This is a not a technical problem but a political and resource one. Meaning how do you incentivize developers to re-write their apps so that they are compatible with that. Given that there are very few money to be made in linux applications I can see why developers are not rushing to re-write. Hence flatpak's allow for an escape hatch on the sandbox so existing apps continue to work. Even Google, with all of it's influnce on the android ecosystem, and all the money involved in it had to back off on scoped storage last year because of the developer outcry. Flatpak is moving towards the right direction. But because of lack of resources it 'll take more time to get there. RE: You are NOT getting security updates Again the author mixes technical capability with the limitations of a volunteer driven ecosystem to arrive to a bad conclusion. In 99% of cases flatpaks are provided by third party volunteers. They have no obligation to stop their life in order to test and provide timely updates. This is also true for normal deb/rpm packages by the way. Maintainers of complex packages such as calibre are unsung heroes. However flatpak's architecture allows for software vendors to host their own repositories and it's easy for the user's to subscribe to them. Hence if a software vendor wants to provide timely updates to their users the capability is there and waiting. RE: Local root exploit? Minor issue! Hello Nitpicking. thayne did a better job than I could do in their post (https://news.ycombinator.com/item?id=23523887 https://news.ycombinator.com/item?id=23523887). At the end of the day an update was provided for the users addressing this. As a user I don't care about how the update was sold. I saw an update available and I updated my system. TLDR: Flatpak technical capabilites are fine (or working towards the right direction). The ecosystem does not have the resources to emberace those capabilities fast enough and that's been used to diminish the technical work been done.
- pie_flavor 6y ago
  This is a tool. How good it is, is measured by how useful it is to me. If it does not provide something I need it to do, then it's less good for it. If it fails to provide the services it advertised as providing, then it's straight-up bad. I don't care why this happens. Might be technical, might be political, might be resource based. Doesn't matter. The tool either does what I need it to or doesn't. And flatpak does not provide sandboxing or security updates, and that it doesn't do this is independent of whether it's a technical or non-technical problem.
steerablesafe 6y ago
Packaging your software in Flatpak/snaps/appimage: Pros: You have 100% control of your dependencies. Cons: You have 100% responsibility for your dependencies. In short: more control implies more responsibility.
thecureforzits 6y ago
Independent of the technical issues being discussed I find this site to be an interesting example of the politics around open source development. It is run anonymously (out of albania, presumably to avoid whois lookups) and does not link to responses or opposing points of view. In addition it is posted regularly on various technology sites such as reddit, HN, etc.

218 points by fao_ 6y ago

Unless this has been updated since 2018 (it doesn't have a date but also looks like it still from 2018) it should be marked [2018]. Also: Here is previous discussion from around the time this website was created: https://news.ycombinator.com/item?id=18180017 https://news.ycombinator.com/item?id=18180017

nominated1 6y ago
> Unless this has been updated since 2018 I think this might also apply to Flatpak. Has Flatpak addressed any of these concerns? If so, how?
- arghwhat 6y ago
  That's not how this works. Old content is marked with its year, irrespective of its relevance.
floatingatoll 6y ago
https://web.archive.org/web/diff/20181013065735/20200615030544/http://flatkill.org/ https://web.archive.org/web/diff/20181013065735/202006150305... doesn't show any differences.

inshadows 6y ago

As opposed to what? To how I run GIMP in the past? Certainly not. > Look ma, I've discovered a program can do nefarious things What else is new?

Gaelan 6y ago
I mean, there's an argument that this is worse. If a security bug is found in libc, in the "old world," your distro would have an update out in a day, and you'd be completely safe. With flatpak, you also depend on whoever's maintaining the GIMP flatpak (and all your other apps), who may not be motivated to do updates any faster than GIMP's normal release schedule, potentially leaving you vulnerable for much longer.
- secabeen 6y ago
  This is also the case for server containers, and I do worry about the day that some critical low level library that is in thousands of containers has a security bug. Yes, many shops are using CI to push out new containers regularly. Others are deploying containers from third-parties, without any regular updates or path to fixing security problems.
- tracker1 6y ago
  And for a lot of smaller apps, they're unable to realistically support being distributed in many different distributions. Flathub is cross-distro and easier for the app author/developer/maintainer to support. Is it perfect, no... is it actually much more secure, not usually. All of that said, is it available in pretty much every linux distribution and often a newer version than what would be in the repositories, absolutely.
- outsomnia 6y ago
  > your distro would have an update out in a day, and you'd be completely safe If you do not restart your services after updating the package, your services continue to run against the exact libs they were started with, even though the library is updated on disk and anything new that starts will use the fixed version. For something like the libc, that is pretty much every service bringing it in and still running the unpatched version of the library. Updating distro packages is of course usually a good thing, but alone it does not make you "completely safe". Also they have a patched version "in a day" because they embargoed public release of the vuln details usually for months, creating a gap where a (growing...) set of people know a secret that can compromise your system and you don't. When I get that update I don't feel "completely safe".
- jhasse 6y ago
  libc is part of the Freedesktop runtime, so the GIMP Flatpak doesn't need to update.
JadeNB 6y ago
> > Look ma, I've discovered a program can do nefarious things > What else is new? I think that this dismissal (which presents as a quote something that doesn't seem to appear in the original article) is too hasty. Surely exactly the same could be said of any submission involving, say, privilege escalation? Of course every program and means of distribution has security risks, and their existence isn't news; but documenting the specific risks is surely worth it.
- inshadows 6y ago
  Well, as every direct reply said, it is true that these App Store models suffer from possibly outdated libraries with unpatched security bugs. But it's nothing new. Everybody knows that. It's case with Docker and all other fat bundle formats. > Sadly, it's obvious Red Hat developers working on flatpak do not care about security Presenting it as a novel privilege escalation with such wording IMO deserves hasty dismissal. These kinds of "hype-ridden disclosures" (i.e. allocating domain name) deserve to be ridiculed because they're meaningless distractions. See [1] for discussion. [1] https://lwn.net/Articles/668695/ https://lwn.net/Articles/668695/
  - pie_flavor 6y ago
    All the other formats talk about how easy they are to use, and when you mention security, they throw up their hands and say "I dunno". Flatpak, on the other hand, its entire shtick is how applications are sandboxed for security.
    - inshadows 6y ago
      And flatpak is actually sandboxed for security. So what's your point? The only news the author of this hype website told us is that 1) there was a vulnerability, 2) lots of application have broad privileges and 3) apps have bundled dependencies. -- 1) Bugs happen. Deal with it. 2) Flatpak actually tells you which privileges an app is going to use. What do you suggest as a solution? Is it technical problem or social problem? What is the state of art? I'd say the state of Art is Android in that it asks for permissions individually as they're required. Still, this problem is not fundamental issue in Flatpak. It certainly doesn't deserve "Flatkill" logo and domain. 3) Is Flatpak actually an exception to the rule? - Making Python app? Use pyenv, pipenv, venv or ${popular_venv_of_the_year} and bundle all your dependencies! - Making .NET app? Use NuGet and bundle all your DLLs! - Making Java app? Use Maven, Gradle, SBT and bundle all your JARs! - Making Rust app? Use Cargo and glue everything together. - Etc. Etc. So yeah, for every programming language we're encouraged to treat our dependencies as unique, fix their versions to prevent possible breakages and take the responsibility for monitoring security issues. Developers just like it. I don't like it but it's everywhere. And as other posters said, Flatpak actually have runtimes which carry core dependencies like libc that get updated independently of the app. So what is the novelty here deserving the flatkill domain? Where is that juicy security vulnerability?
michaelmrose 6y ago
Aside from security updates being delivered between late and never if they are ever compromised 1/3 of users will be effected in the first hour and 100% effected within 24 hours even if on the 25th hour they discover it and take it down. In the old school situation distributions would still be between days to weeks deciding to pull in a new version released through normal channels.

jsnell 6y ago

So Flatpaks also install under /var? That's horrible, I thought it was only Snaps that made that decision :( Does anyone know what the official reasoning for this is?

bepvte 6y ago
Flatpaks use a git-like tree of hashes, which cant just be shoved into random places on your filesystem. It has an exports directory you can symlink or add to your path.
- mariocesar 6y ago
  or you can install in your user directory, current cli of flatpak ask you for this and you can set the default install option for the user directory also
- mikepurvis 6y ago
  In that case it should be in /opt, where application bundles not managed by the system's primary packaging system belong.
  - Spivak 6y ago
    This isn’t technically correct when Flatpak is installed via your distribution. Then it is managed by your packaging system and it’s data should live in a /var/lib. /opt is for software that doesn’t adhere to the FHS and can’t/shouldn’t be installed in a prefix. Red Hat and Arch install software to /opt via their official package managers. /opt isn’t safe to stick arbitrary software even though it’s commonly used for that — /opt/local is the non-FHS equivalent of /usr/local.
  - reactor4 6y ago
    Agreed, that's what /opt is for.
  - dylan-m 6y ago
    > This isn’t technically correct when Flatpak is installed via your distribution. Then it is managed by your packaging system and it’s data should live in a /var/lib. Besides, this is silly: they go in /var/lib/flatpak, which is for flatpak's program state information. (Exported desktop files and whatnot go to /var/lib/flatpak/exports/, which is pointed to by `$XDG_DATA_DIRS`). I mean, if you want to go all Militant Unix Admin on it and install apps to /opt, you can `man flatpak` and set `FLATPAK_SYSTEM_DIR=/opt/flatpak`, but unless your system spans a dozen hard drives I'm not sure what that's going to achieve. I guess this is sort of an ownership conundrum: a flatpak app is run _via_ flatpak. On its own, it's just a heap of files.

bepvte 6y ago

I still love flatpak, and much of what this article states is hostile and outdated. The "XDG portal" specification makes filesystem access less popular then before. Also, "fakepak"? Really?

gavinray 6y ago

Am I the only person who actually doesn't really mind that flatpaks and snaps have less user-control over behavior and/or security implications? I really enjoy them. Install it, forget about it, let it update automatically. Theoretically could something unwanted happen, yeah probably, but I enjoy the convenience they provide and typically you're installing fairly well-known software (Microk8s, VS Code, and Chromium come to mind). My one gripe with snaps is that AppArmor can occasionally cause headaches with Microk8s permissions.

monadic2 6y ago
I just wish they separated out the functionality of app portability, app sandboxing, and app installation. It’s much less debuggable and comprehensible packaged together. Kind of reminds me of systemd, actually.
- viraptor 6y ago
  I don't think you can separate sandboxing and installation. Any nontrivial and useful sandboxing relies heavily on how / where the app lives and how it communicates with the world. This includes things like dbus paths too, not just file paths.
  - monadic2 6y ago
    Well, it’s a problem the floss community will have to deal with sooner or later—it feels pretty awkwardly papered over with snap.
    - viraptor 6y ago
      The other way is to rely on labels rather than names. But I don't see every distro switching to selinux with per-flatpak/snap policies, so it's going to be have to be joined installation and sandboxing.
      - monadic2 6y ago

axaxs 6y ago

I don't understand why people favor Snap or Flatpak to Appimage, which looks to be the simplest of the three. Would anyone mind sharing their experiences?

devbat8712 6y ago
I've found appimages to be a bit of a pain in the past because they're portable, so you need to have a place to put them
suby 6y ago
Appimages don't update automatically.
- Polylactic_acid 6y ago
  And they aren't integrated in to the OS like snap or flatpak. I can install/update a flatpak and it shows up in the program menu. For appimage I have to open my filemanager and click on the program like a prehistoric windows user. Also last time I read the OP article the tldr is "Flatpak has security options but many packages turn them off making them exactly as secure as appimage/binaries from a package manager"
  - suby 6y ago
    I think this is something that can eventually be fixed. Indeed, I'm on Linux Mint and the integration is actually pretty good. When you first run an appimage it asks if you'd like to add the program to the start menu. Icons are correct and everything. I can also imagine some possible ways to allow appimages to auto update, though I suspect there'd be a lot of resistance to that.
    - Polylactic_acid 6y ago
      I'm not really aware of a single way appimage would be better than flatpak. To get the integration and updating working you would need to install a tool and not having to install something for appimage is the only benefit I see over flatpak. It makes it easier to just quickly download and runs something but less convenient in the long run. Also in the future I can see apps being built to actually use the permissions system in flatpak so it doesn't have to be disabled. Flatpak is a step forwards for linux where as appimage is restoring bad practices from windows.

LeoPanthera 6y ago

This page is really old, but I disagree with "the users are misled to believe the apps run sandboxed". I think most people use flatpak (and/or snap, appimage, etc.) as a way of installing applications in a way that does not contaminate the host OS, and a way of removing them again without leaving any traces behind. For example, it's an extremely convenient way of installing Steam without having to worry about its obscure, 32-bit, dependencies. That they are sandboxed, or not, is very much secondary, for most users, I believe.

livre 6y ago
As a user and someone who knows nothing about flatpak other than "it can install apps" what you said is true. I use flatpak and appimage because they allow me to use software without cluttering my /bin and other root subdirectories. And also because I can install with them software that my distro does not include in its repositories. All resides in my home and it's easy to remove without leaving any traces. I didn't know flatpak apps were supposed to be sandboxed until I read this article when it was posted a few years ago. Whenever I want to sandbox something I use firejail.
gentleman11 6y ago
What I know about flatpak was from some Linux you tubers who led me to believe it was a sandbox. For that matter, some hn users posted similar things in the last month when talking about snaps iirc
- vetinari 6y ago
  Flatpak has a sandbox; but for some apps, it has to be a more open, otherwise they would not work as intended. All that's open is visible as a flatpak permission; if you want, you can tighten it up and see, what breaks. On the other side spectrum are people, that are disappointed, that they cannot use SDKs installed at random places in their host system with editors packaged with Flatpak. Well, duh...
trevyn 6y ago
Someone might want to fix the Wikipedia, then: “Flatpak is a utility for software deployment and package management for Linux. It is advertised as offering a sandbox environment in which users can run application software in isolation from the rest of the system.” https://en.wikipedia.org/wiki/Flatpak https://en.wikipedia.org/wiki/Flatpak

davidhyde 6y ago

No https redirect and the post is about security.

SkyMarshal 6y ago
I get the optics aren't great. But, if you check the source, this is a single HTML + CSS page with zero scripts or forms. Does it matter, technically?
- tracker1 6y ago
  Considering ISPs and Nation states have injected additional scripts into plain HTML payloads, it does matter, technically.
- the_hoser 6y ago
  It really, really does.
  - bandrami 6y ago
    How? I don't trust the site's author, so from a security standpoint there's nothing gained by distinguishing him from an impersonator.
    - the_hoser 6y ago
      Do you trust your ISP/Government/Router to not inject spyware/malware into the pages you visit?
      - bandrami 6y ago
        That's literally what I just said. I don't trust the site's author any more than I trust an ISP/Government/Router.
AlexCoventry 6y ago
http://n-gate.com/software/2017/07/12/0/ http://n-gate.com/software/2017/07/12/0/

evross 6y ago

A great talk on Flatpak sandboxing was released in March. [1]. The original post is from 2018 (Flatpak 1.0). Not sure if these issues are completely fixed yet, there are a lot of release notes up to version 1.63 (stable). [2] It seems that the maintainers and community are working on improving security continuously. My main hope is that they optimize for privacy, security and user control of the packages. Overall I'm impressed by flatpak with it's cross-distribution packaging. [1] https://www.youtube.com/watch?v=3rCIEzfZw1I https://www.youtube.com/watch?v=3rCIEzfZw1I [2] https://github.com/flatpak/flatpak/releases https://github.com/flatpak/flatpak/releases

mongol 6y ago
Did you see it live? Not a great experience on Youtube, audio problems unfortunately.
- evross 6y ago
  I found it through search on Youtube, had been looking for which way to package applications on Linux. Packaging really takes a bit of time, reading documentation and figuring out how to do it. After packaging a flatpak you need to add it to a local repository on your device before you can test install it, which isn't as intuitive as clicking on a .appimage file, but brings some benefits. The documentation is quite readable: https://docs.flatpak.org/en/latest/first-build.html https://docs.flatpak.org/en/latest/first-build.html. Agreed for audio quality. It's hard to listen to with only the left channel working. It might be worth reuploading it with balanced stereo.

Thorrez 6y ago

> The criticial vulnerability "shell in the ghost" was fixed in flatpak about one month after linux distributions. I can't find any reference to that vulnerability except this page.

pmontra 6y ago
The name isn't an exact match but maybe it's this glibc vulnerability: https://blog.qualys.com/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability https://blog.qualys.com/laws-of-vulnerabilities/2015/01/27/t... Edit: nope, this is Ghost in the Shell, from last February https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-investigating-web-shell-attacks/ https://www.microsoft.com/security/blog/2020/02/04/ghost-in-...
- Thorrez 6y ago
  I don't think either one is right. That first one is from Jan 2015, but according to Wikipedia the first release of Flatpack was Sept 2015. The second one doesn't even seem to be a vulnerability, but rather the general concept of web shells. One of the vulnerabilities mentioned in the article (CVE-2019-0604) is for Microsoft SharePoint, so that's unrelated to Flatpack. Also note the difference in order of the words "ghost" and "shell".

gentleman11 6y ago

> Yes, it's possible your linux box has been compromised if you use flatpak, we are literally talking about several months old public exploits. Ever opened an image in flatpak Gimp? The criticial vulnerability "shell in the ghost" was fixed in flatpak about one month after linux distributions. There were some heavily up voted comments and posts on hn this year about how much people hate how snaps auto update themselves. Does this change anyone’s mind, or do those points still stand?

AlexandrB 6y ago
Those points are completely unrelated to flatpak taking a long time to release patches. Whether flatpak forced updates or not, from TFA it seems as though it's still months behind Linux distros.

arminiusreturns 6y ago

I will use appimage. I refuse to use flatpak or snaps. That's my take as a linux user and admin.

thayne 6y ago

> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue. The actual wording in the linked release is "This is a minor security update, matching the behaviour on master where we avoid ever creating setuid files or world-writable directories." The wording is perhaps a little ambiguous, but my interpretation of that is, "this is a minor update that fixes a security issue," not "this is an update that fixes a minor security issue." The author also implies that simply including a setuid binary would allow the app itself to get elevated privileges. This seems at odds with the way flatpak uses containers to sandbox the app, and in fact when I looked at the linked CVE, the actual vulnerability is that a seperate attack could use a setuid binary installed as part of a flatpak to get privilege escalation. Don't get me wrong, it's still a sever vulnerability. But it is much more difficult to exploit than the author first led me to believe.

choeger 6y ago
Add to that the first paragraph, which is literally a complaint that flatpack does not make things better compared to rpm. Indeed the one about security updates is valid and my biggest grievance with such an approach. Note, however, that propietary software like sublime could easily use statically linked or embedded libraries anyways, as they do not have to adhere to any packaging guidelines. So this applies only to free software that has been packaged with the distro.
- vetinari 6y ago
  > Indeed the one about security updates is valid and my biggest grievance with such an approach. And that stems from misunderstanding. Flatpak has a concept of runtimes. If you have some basic library that would be updated by your distribution, you have pretty much big chance that it would be part of the runtime and updated by runtime maintainers, not by the application authors. I.e. you would get your security updates, subject to the maintenance period of the runtime (for example, the org.freedesktop.Platform has 2-year support).
  - danieldk 6y ago

deleted 6y ago

[deleted]

akho 6y ago

Flatpak mixes together application packaging, sandboxing, desktop integration, and an update mechanism. I do not understand the need to have all four in the same tool. I even think it limits the usefulness of each component. Would a combination AppImage, firejail, and a couple of shell scripts be worse?

dylan-m 6y ago
Much worse. I encourage you to try some properly sandboxed Flatpak apps. Here's a fun one: https://flathub.org/apps/details/com.github.maoschanz.drawing https://flathub.org/apps/details/com.github.maoschanz.drawin... Note that the app has no access to your home directory by default, and this fact is invisible to the end user. The file open and save dialog is handled out of process by a portal, which is a service that allows an application to (with permission) poke holes in its sandbox. By tying a few different things together, this is seamless: the user gets a file chooser dialog and chooses a file, as usual. (As a bonus, it's always a native dialog). Behind the scenes, the application is granted access to read or write to that file. I don't think this would be easy to manage if Flatpak was split into a bunch of different moving parts, and I can't imagine it providing any meaningful benefit. With that said, it isn't as monolithic as folks seem to think. It's built on bubblewrap and ostree and a whole bunch of freedesktop specifications.

bonestormii_ 6y ago

The moment you delegate your security or stability concerns to a third party, all bets are off. Period. Package maintainers, RedHat, whoever. Maybe the patch fixes a vulnerability, maybe it creates one. Maybe the company pushing security is really pushing mindshares of ecosystems for subscription revenue and industry influence. Build from source; keep your packages as minimal as possible; keep your permissions as granular and restricted as you can manage; and pray to your gods of choice. I can't understand why people are so anxious to embrace so much unneeded complexity. Things that "just work" always just work until they just don't.

kelnos 6y ago
I'm pretty sure "build from source" is out of reach for most people (from a technical ability standpoint), and for those who could do that, most have better things to do with their time. If your threat model includes intentionally malicious packages from Red Hat, Debian, or whomever, ok, but understand that you're a miniscule fraction of a percent of the user base. And you'd better be auditing the source that you compile as well.
- ownagefool 6y ago
  The words "threat model" gets thrown around, but I'm not actually sure "our threat model didn't include our OS vendor" would be considered an acceptable excuse. Sure, we have reasons to trust Redhat; - You can look at their working practices ( Good coding hygiene, Peer Review, Tools, etc ) - You can make the commercial argument ( they make money by doing the right thing, it's not in their interest to hack us ) But ultimately we're still explicitly trusting 1000s of people here, so reality is much more nuanced. - Hardern your OS, i.e. only install the bare essentials. - Monitoring for processes or networking traffic doing unexpected things. Thus, you evidence that you reasonably trust the vendor but you'd expect to see an alert were to prove false. Probably a better use of "threat model" would be, we don't need to place trust in developer end user devices because we instead place our trust in our SCM, CI/CD and the SDLC process.
  - kelnos 6y ago

Iolaum 6y ago

This article is written in bad faith. RE: The sandbox is a lie. No it's not. The technical capabilities are there. The problem is that the application needs to be written a certain way in order for the sandbox to be enforced and the app not to break. This is a not a technical problem but a political and resource one. Meaning how do you incentivize developers to re-write their apps so that they are compatible with that. Given that there are very few money to be made in linux applications I can see why developers are not rushing to re-write. Hence flatpak's allow for an escape hatch on the sandbox so existing apps continue to work. Even Google, with all of it's influnce on the android ecosystem, and all the money involved in it had to back off on scoped storage last year because of the developer outcry. Flatpak is moving towards the right direction. But because of lack of resources it 'll take more time to get there. RE: You are NOT getting security updates Again the author mixes technical capability with the limitations of a volunteer driven ecosystem to arrive to a bad conclusion. In 99% of cases flatpaks are provided by third party volunteers. They have no obligation to stop their life in order to test and provide timely updates. This is also true for normal deb/rpm packages by the way. Maintainers of complex packages such as calibre are unsung heroes. However flatpak's architecture allows for software vendors to host their own repositories and it's easy for the user's to subscribe to them. Hence if a software vendor wants to provide timely updates to their users the capability is there and waiting. RE: Local root exploit? Minor issue! Hello Nitpicking. thayne did a better job than I could do in their post (https://news.ycombinator.com/item?id=23523887 https://news.ycombinator.com/item?id=23523887). At the end of the day an update was provided for the users addressing this. As a user I don't care about how the update was sold. I saw an update available and I updated my system. TLDR: Flatpak technical capabilites are fine (or working towards the right direction). The ecosystem does not have the resources to emberace those capabilities fast enough and that's been used to diminish the technical work been done.

pie_flavor 6y ago
This is a tool. How good it is, is measured by how useful it is to me. If it does not provide something I need it to do, then it's less good for it. If it fails to provide the services it advertised as providing, then it's straight-up bad. I don't care why this happens. Might be technical, might be political, might be resource based. Doesn't matter. The tool either does what I need it to or doesn't. And flatpak does not provide sandboxing or security updates, and that it doesn't do this is independent of whether it's a technical or non-technical problem.

steerablesafe 6y ago

Packaging your software in Flatpak/snaps/appimage: Pros: You have 100% control of your dependencies. Cons: You have 100% responsibility for your dependencies. In short: more control implies more responsibility.

thecureforzits 6y ago

Independent of the technical issues being discussed I find this site to be an interesting example of the politics around open source development. It is run anonymously (out of albania, presumably to avoid whois lookups) and does not link to responses or opposing points of view. In addition it is posted regularly on various technology sites such as reddit, HN, etc.