Flatpak – A Security Nightmare (2018)
flatkill.org
flatkill.org
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.
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.
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).
Unfortunately, this is not true. Many of the Flathub Flatpaks compile custom versions of a lot widely-used libraries. E.g., the most recently updated Flathub package of an open source project (as of writing), compiles by itself [1]:
Boost 1.73, Eigen 3.3.7, OpenCV 4.3.0, exiv2 0.27.2, marble 20.04.1, lensfun 0.3.2, ImageMagick 7.0.10-13, libgphoto2 2.5.25, libusb 1.0.23, jasper 2.0.16, libksane 20.04.1, sane-backends 1.0.27, libqlr master, qtav 1.13.0, x265 3.3
Most of these are standard dependencies that are in most Linux distributions.
[1] https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382...
E.g. Boost. Fedora 32, which was released this April, but has version 1.69 (released in Dec 2018), while the current one is 1.73. Similarly, ImageMagick is updated every few days. In these cases, it is better to let the applications decide which versions they want, and keep up with updates.
It's a much longer chain of risk decisions than you would first be lead to believe.
Also: Here is previous discussion from around the time this website was created: https://news.ycombinator.com/item?id=18180017
I think this might also apply to Flatpak.
Has Flatpak addressed any of these concerns? If so, how?
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.
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...
It's been very much not secondary to the PR effort behind it. A few years ago, when the first usable releases started popping up, sandboxing was the touted as Flatapk's biggest advantage and basically the reason why it was the future of Linux software distribution on the desktop. That's why that page gives sandboxing so much importance.
I disagree, have not seen container mentioned in PR materials for flatpak even once. I actually was not sure they were using that for sandboxing, I just knew they did some manner of sandboxing as it was making things break in some cases.
Until one or two years ago hardly a month went by without one of these hitting one of the various Linux communities. I'm not sure how you missed them. Just one example that I literally got to by googling "flatpak is the future":
https://www.zdnet.com/article/the-future-of-linux-desktop-ap...
And sure enough, right in the middle of that piece, is this bit:
"Applications delivered by either run in a virtual sandbox. This makes them safer to use. They can also run on any desktop distro. Neither users nor ISVs have to worry about the underlying distro or its version because all the needed components for the application come already bundled."
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.
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.
This is the same thing that happens when installing from the distribution's package manager? I install it, forget about it, and run the update command whenever I remember, once every few weeks.
The amount of available software depends on your distribution, but on Arch practically everything is available in the official repositories or the user repositories.
And when security issues are fixed, updating my system fixes them for all applications instead of just the ones which update their flatpaks (and from the article, it seems like many don't).
That is an ideal, the reality is somewhat different. It takes constant effort to ensure this. See https://wiki.debian.org/EmbeddedCopies for details.
Sure, it's not perfect, and some packages end up having embedded dependency copies, but that's a far cry from flatpak, where everything is an embedded copy, by design.
With apt/yum/etc it is the responsibility of the distro maintainers to package it.
Containers are a security nightmare because developers tend to have a release-and-forget mindset. Packagers are the ones doing the thankless work of constantly tracking issues, backporting fixes, dealing with dependency issues, etc. Take the packagers out of the equation and the result will be entirely predictable--much more stale software sitting on the hard drives of oblivious users, just as we see with containers.
IMHO this should be thankless. If you want updated software then update it.
By backporting fixes, you create an untested and unsupportable version. They pull patches that may or may not have dependencies on other changes to the software, which they avoid because they don't want to update, and generate a whole bunch of noise for application developers.
If the upstream releases a new version and the packagers just throw it into the distro, they've created an untested and unsupportable system.
This is true. So stop trying to pull apart tens or hundreds of other people's work hours on some attempt to create some frankenware.
The rest of what you wrote doesn't make sense. Of course it would get tested whether they backport or not. Of it doesn't, then they aren't testing what they are doing now.
The current state is that we don't get much cross pollination as the version being pushed by RedHat isn't the same as the version being pushed by Debian, so bugs are introduced and resolution doesn't help each other.
Your distro doesn't live in a vacuum. Stop acting like it does.
> This is true. So stop trying to pull apart tens or hundreds of other people's work hours on some attempt to create some frankenware.
I'm not involved in this, so I'm not entirely sure what you want me personally to stop doing, but I definitely appreciate the efforts of distributions to create systems that work together as a whole, and don't spontaneously fail because an upstream author has put out a new release and is now forcing me to choose between carrying a vulnerability and breaking compatibility.
> The rest of what you wrote doesn't make sense.
I beg to differ. Perhaps I should simplify my language.
> Of course it would get tested whether they backport or not.
By whom? There's a reason Debian Stable has a painfully long release cycle, and it's partially because they're taking that time to make sure the complete set of versions you get when you do an `apt-get install <whatever>` works together, as a coherent system. If you change `libfoo-1.0.0` to `libfoo-2.0.0` and just push that out to everyone, the combination of `libfoo` with any of its dependencies or dependents is now untested.
You can make a separate argument for rolling release distros if you like, but the problem doesn't go away.
Again, this is why the concept of "distribution" came into being in the first place: because throwing together arbitrary versions and expecting the result to work is madness. Or, if you prefer, Debian Unstable.
> The current state is that we don't get much cross pollination as the version being pushed by RedHat isn't the same as the version being pushed by Debian, so bugs are introduced and resolution doesn't help each other.
Correct. And if upstream authors took responsibility for their previous releases and backported patches themselves, they wouldn't have divergence in the first place. But that's not necessarily workable, so we've got the next best thing: other people keeping the lights on for them.
> Your distro doesn't live in a vacuum. Stop acting like it does.
I'm not claiming anything of the sort.
given the amount of security issues that are being fixed silently, even sometimes unadvertently, in newer releases of any software, I really believe that doing this instead of forcing ppl to update just creates a less secure world.
And then you also get the issue of bugs that are actually security issues, but weren't labeled/identified as such, and therefore never get fixed in those stable distributions.
[1] https://git.centos.org/rpms/webkit2gtk3/commits/c8 [2] https://webkitgtk.org/security/WSA-2020-0001.html [3] https://webkitgtk.org/security/WSA-2020-0002.html [4] https://webkitgtk.org/security/WSA-2020-0003.html [5] https://webkitgtk.org/security/WSA-2020-0004.html [6] https://webkitgtk.org/security/WSA-2020-0005.html
RHEL and CentOS have pretty good backporting support for packages that they support, but most installs of them that I have seen use/include packages from other collections that are not supported, which is of course the wrong way to do it.
Why the question? I was only trying to state what I think is fact, not sell one approach or another.
Flatpak program is pinned to a runtime version, e.g. org.freedesktop.Platform//18.08 (with 18.08 being a major version) of which receives security updates periodically. When user installed a package, Flatpak will install a program and its runtime to Flatpak directory.
If a program only depends on libraries in a runtime (and not requiring any bundled dependencies) then packager won't need to worry about upgrading those libraries at all, as updating a runtime will update those dependencies.
Yeah definitely, I just like not having to think about running the apt update commands. It's not a huge difference.
I mean, that isn't what I said necessarily.
I use Linux because Windows is bloated, slow garbage and OSx is crippled, locked-down Linux with a UI I'm none too fond of.
I'm not a power-user. I run Ubuntu with i3, that's about the depths of my linux-wizardry.
> When you hit a bug in a flatpak or snap, what are you going to do?
Install the apt repo or build from source I suppose?
I have no problems with it, and was wondering if maybe an update broke it?
Say what
I don't see why AppImage wouldn't be able to be updated if support for this would be added to the app itself.
When trying to download software that doesn't exist in my distro's repo, I always look for AppImage first.
- No sandboxing
- Doesn't solve the "run everywhere" problem, AppImages usually are compiled agaisnt Ubuntu LTS's, which isn't 100% binary compatible with other distros, e.g. fedora
- Its a game of bingo whether the AppImage has a library bundled or not, and whether the app will work your host version or not.
- Performance, appimages are a compressed filesystem that getss mounted by fuse each time the app is run, which is slow, additionally subsequent launches of the app aren't even faster because we get fresh inodes each launch.
- Bad system intergration, appimaged is an abomination.
- AppImages promote a bad security practice of marking binaries from the web as executable, let's not replicate the main way malware is distributed on Windows.
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"
https://github.com/AppImage/appimaged
The main problem with AppImages is that there is no easy way to update them in bulk.
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.
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.
Also, from the research I have done (which I'll admit is inadequate), the process of building an appimage seemed more straight forward than either flatpak or snap.
> Look ma, I've discovered a program can do nefarious things
What else is new?
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".
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.
> 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.
> 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.
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?
In the old school situation distributions would still be between days to weeks deciding to pull in a new version released through normal channels.
Also, it's fairly easy to reinstall the OS but people are more concerned about their home directories being damaged or exfiltrated.
Why?
It is also extremely common for $HOME to be a network drive or even a USB stick, so better to cache stuff in /var which can be assumed to be local storage.
/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.
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.
Would a combination AppImage, firejail, and a couple of shell scripts be worse?
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.
I can't find any reference to that vulnerability except this page.
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-...
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".
Pros:
You have 100% control of your dependencies.
Cons:
You have 100% responsibility for your dependencies.
In short: more control implies more responsibility.
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.
Once you realise you're going to need to deal with running stuff you don't entirely trust, you it makes some sense to extend this beyond the bare necessities and dip your toe into productivity improvements.
Problem is, much of the industry is full of charlatans that copy and buy as opposed to understand. You end up with orgs that spend $20 million security products but refuse to pay for the expertise to configure it.
The reality is we have, we have a lack of skills, especially around InfoSec and most people just mimic what they've heard, rather than really think about it. On average, companies don't compete for talent, and they don't have enough skills and discourse to hire better than they have anyway, so it doesn't really matter what they run.
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.
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.
I can't recall any threat-modeling session I've been a part of, or any infosec security professional I've talked to, who has seriously considered the OS vendor as a threat. "Our threat model didn't include the OS vendor" absolutely is an acceptable excuse.
Your mitigations (only install bare essentials, network monitoring) are good advice in general, and people should be doing those things regardless of any perceived threat from the OS vendor.
Aside from that, really the only way you can absolutely harden yourself assuming a hostile OS vendor is to... not use an OS, and build your entire system from scratch. Which, again, sure, might be a perfectly reasonable thing to do for some ultra-sensitive applications, but -- again -- that is a teeny tiny fraction of a percent of what's actually happening out in the world.
On the last point, doing it all yourself probably isn't actually better. Most people don't have the time in the day to invent the universe, so you're always back to figuring out how you establish trust.
But if you really care about security, and if you are managing a linux OS where you have a lot of deep access to the system, I think saying "I have better things to do with my time than understand the system I'm managing; that's what vendors are for" is a lazy perspective.
Consider this: https://github.com/systemd/systemd/issues/6237
Order of events here: - RedHat creates systemd to handle init and daemons--something that used to be handled mostly by shell scripting and much simpler tools.
- Debian and RHEL based systems adopt systemd. That's most Linux systems.
- About 6-7 years later, an issue is noticed and reported by a user. If a user creates a service to be run under a username beginning with a number, which some distros (not RHEL or Debian though), systemd validates the name (why?) by matching it against a regex.
-If validation on any field fails, they categorically ignore that field and run the service.
-In this case, because it is the user name, it runs the service as root instead of the user name.
-Their response? "This is how the system handles all fields. We do it for consistency and compatibility. Closed."
-That was 3 years ago. This was never fixed. "It's not a bug! Just don't give systemd a potentially valid user name that looks like that!"
So using the daemon system promoted by RedHat (who we trust!) has created a situation where a process--possibly a server or something public facing--could be run as root without you immediately realizing it. You don't care to understand your system, but you do have to operate it. RedHat won't do that part for you. So, you could create these conditions unknowingly.
It wasn't malicious, but what's important is that it isn't necessary.
Look at what kinds of questions did the RedHat maintainers ask?
"I wonder what tool allowed you to generate this file?" A totally useless question, given these files are frequently generated manually. "It's the tools fault! Whatever it is. Even though it might be a valid username on your system."
A better question might be "Why do we have to validate/parse the username field at all?" After all, parsing bugs are well-known for creating security vulnerabilities, and if the name is invalid, then there will be no user, and the service will fail in the same way it does when the username string is syntactically valid but there is simply no user. In short, they have a product that "helps you manage your OS; and from RedHat (who we trust!)", yet we find that it increases complexity; does unnecessary work; and results in a bug that could allow a process to run root when it should not.
This scenario is so similar to the flatpak sandbox issue. "It's not a bug. It's just that most people are misconfiguring it." Fine! But you chose to embrace the added complexity of a system (flatpak) that you just don't actually need. It has pros and cons. It's not a matter of trusting RedHat not to be malicious--it's trusting them to make that judgement for you. Their judgement is not perfect.
There is a medium that exists between "audit every line of source in the system yourself" and "trust implicitly everything a vendor says and does". I think that RedHat is reputable and trustworthy, and they are trying to push Linux forward, but they are simultaneously reinforcing their position as industry experts through creating software that "eats linux". It's not malicious, it's just the nature of their existence. Your interests and their interests are not the same, so it makes sense to consider things for yourself.
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?
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). 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.