Flatpak – A Security Nightmare(flatkill.org)
flatkill.org
Flatpak – A Security Nightmare
http://flatkill.org/#
15 comments
Conversely, if you publish your package exclusively as Flatpak, I will not download it. Nothing personal against your product, it's just not getting installed on my system via Flatpak.
“Your Bluetooth speaker has a hidden camera and wifi access point for your neighbours to login to so they can watch you shower” “Hell. Fine with me, it plays music very well”
Would you prefer one of the alternatives that also gives you cross distro packages that work, but with stronger security guarantees and developer ethos?
What are those alternatives?
snaps are the one I'm most familiar with, which provides sandboxing wherever possible, automatic updates, and a permissions system where I can do things like deny Firefox access to my webcam. And is available on a number of Linux distributions.
You can install nix. Does not give you sandboxes like flatpak unless combined with other tools like firejail or nixos-shell, but at least nixpkgs-unstable is one of the most up-to-date package managers out there.
The overwrought language here makes the reader feel like they're being yelled at for someone else's mistake.
We get it, you're upset. "Tone of voice" on this chips away at reader sympathy.
We get it, you're upset. "Tone of voice" on this chips away at reader sympathy.
I don't get why people feel the need to make these unique domain names for a single blog post.
This happened with 'chrome is bad'[0] where someone anonymously registered a new domain complaining about Chrome's updater taking up CPU, but the comments later pointed out that it most likely was just a bug in activity monitor[1].
It seems the only reason for doing this instead of having a personal site with multiple blog posts is to spark debate while keeping a zero-repercussion way out in case the internet/HN determines that the situation is more nuanced than what the blog makes it out to be, or when it's outright incorrect on facts.
0: https://news.ycombinator.com/item?id=25400618
1: https://news.ycombinator.com/item?id=25401681
This happened with 'chrome is bad'[0] where someone anonymously registered a new domain complaining about Chrome's updater taking up CPU, but the comments later pointed out that it most likely was just a bug in activity monitor[1].
It seems the only reason for doing this instead of having a personal site with multiple blog posts is to spark debate while keeping a zero-repercussion way out in case the internet/HN determines that the situation is more nuanced than what the blog makes it out to be, or when it's outright incorrect on facts.
0: https://news.ycombinator.com/item?id=25400618
1: https://news.ycombinator.com/item?id=25401681
I don't think in the current climate "having a zero-repercussions way out" is an unreasonable thing to want. Heck, I don't think merely having an incorrect take on a technical issue is something that should ever warrant "repercussions", unless it's intentionally claimed from a position of authority.
But more than that I think these silly single use websites are just gold marketing. They're very memorable, I don't think we'd have collectively remembered the "motherfucking website" if it was just a blog, for instance. It's a bit daft, but what can you do.
But more than that I think these silly single use websites are just gold marketing. They're very memorable, I don't think we'd have collectively remembered the "motherfucking website" if it was just a blog, for instance. It's a bit daft, but what can you do.
There is no such thing as "zero repercussions way out" here, and it seems to make no sense to even want that in this context. Either the bugs are real and they get fixed, or they don't and now the project looks bad; if for whatever reason the bugs turned out to not be an issue, that would be the only time it wouldn't matter in the end.
If the author isn't actively working with upstream to get them fixed, and isn't announcing that association with the project, it's probably safe to say they don't have a position of authority within that project.
If the author isn't actively working with upstream to get them fixed, and isn't announcing that association with the project, it's probably safe to say they don't have a position of authority within that project.
Idk about why they do it, but I can remember them! I read many many blog posts and if someone happens to ask me about a certain topic and I remember reading an blog post about it, I usually have to google or search my notes for it. Not with flatkill.org and with doesmysiteneedhttps.com
These two I always remember. So that's maybe why
These two I always remember. So that's maybe why
> I don't get why people feel the need to make these unique domain names for a single blog post.
It's funny and stands out.
>instead of having a personal site with multiple blog posts
It isn't like they couldn't make anonymously flatkill.some-free-hosting-site.tld.
>a zero-repercussion way out in case the internet/HN
Or when the mob doesn't like someone saying what they like is bad and proceed on a crusade.
It's funny and stands out.
>instead of having a personal site with multiple blog posts
It isn't like they couldn't make anonymously flatkill.some-free-hosting-site.tld.
>a zero-repercussion way out in case the internet/HN
Or when the mob doesn't like someone saying what they like is bad and proceed on a crusade.
flatkillsucks.com is $10/year on Namecheap.
Your move, I guess.
Your move, I guess.
This particular blog post gets reposted and debunked almost monthly on hacker news.
Response from a Flatpak package maintainer:
https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
The answers are good, with the exception of one point that I disagree with. In the article, the author states that IDE's obviously need to have full file system access in order to work. This is papering over the fact that development tools are some of the most critical pieces of software in an organisation, and if it becomes compromised the entire production chain may be compromised.
It doesn't help that a lot of development tools happily downloads random code from various repositories during build, so not only are the applications sensitive, they also are more vulnerable than anything else.
The solution here is of course to isolate the development environments and give them private structures that contains everything the tools need. I'm not sure if Flatpak has the ability to provde a "virtual home" or some such, it should be available.
It doesn't help that a lot of development tools happily downloads random code from various repositories during build, so not only are the applications sensitive, they also are more vulnerable than anything else.
The solution here is of course to isolate the development environments and give them private structures that contains everything the tools need. I'm not sure if Flatpak has the ability to provde a "virtual home" or some such, it should be available.
It's not papering over it if you look at the rest of the paragraph. The problem is that the IDEs just aren't made to work with this kind of sandboxing and need to be changed significantly. I agree it would be cool if someone eventually made an IDE that could operate like that.
My point is that I work like that with current IDE's when using Qubes OS.
What I suggest is that Flatpak could provide something similar, by having a completely separate filesystem used by the tool.
What I suggest is that Flatpak could provide something similar, by having a completely separate filesystem used by the tool.
That would need UI similar to Qubes that would have to be built and integrated probably on the IDE side. Purposefully, flatpaks don't typically ship a whole OS like Qubes VMs do, so the gap has to be filled somewhere.
Most VMs in Qubes does not come with a full OS. They're based on templates, which isn't too different from the system packages of Flatpak.
Also, Python developers seems to be dealing with this stuff on a daily basis with virtualenv, so this isn't something new.
Also, Python developers seems to be dealing with this stuff on a daily basis with virtualenv, so this isn't something new.
This post basically boils down "this site is correct on X but Flatpak is working towards solving X."
A flatpak conteibuter wrote a blogpost about that: https://news.ycombinator.com/item?id=26521390
I don't mind Flatpak, I just don't like when it's my only option to install something. I understand that sandboxing can make development marginally easier, but I have yet to see software get released via Flatpak that outright wouldn't be possible without it.
I do not have Flatpak enabled in my package manager, and will likely never enable it. That's not an attack on Flatpak users or the software, I'm just not putting it on my desktop. If we come to a point where people exclusively distribute via sandboxed methods like Snap and Flatpak, I'm going to have to start to get choosy with my applications.
I do not have Flatpak enabled in my package manager, and will likely never enable it. That's not an attack on Flatpak users or the software, I'm just not putting it on my desktop. If we come to a point where people exclusively distribute via sandboxed methods like Snap and Flatpak, I'm going to have to start to get choosy with my applications.
You're setting an impossible threshold for your expectations. No software will be possible to use with Flatpak but not without it. That's not the goal for Flatpak and there's no technical reason for this to ever happen.
It's on the software author to decide if they want to deal with all possible package formats or concentrate on specific ones. You always have the option to publish your own packages in the preferred format. Copr/PPA/others make it pretty simple even without local builds.
It's on the software author to decide if they want to deal with all possible package formats or concentrate on specific ones. You always have the option to publish your own packages in the preferred format. Copr/PPA/others make it pretty simple even without local builds.
You're missing one major benefit of Flatpak: With on small build manifest and by using flathub you can ship your application to a couple dozen distributions.
Everything else is just more work for application developers and distributors won't include every application in their repositories.
Everything else is just more work for application developers and distributors won't include every application in their repositories.
> I understand that sandboxing can make development marginally easier
I don't think I missed it, did I? I mean, I understand that sandboxing your software will make it run on every platform, but so will shipping a VM with your program preinstalled. At some point we just have to cut our losses and pick a platform that Just Works.
I don't think I missed it, did I? I mean, I understand that sandboxing your software will make it run on every platform, but so will shipping a VM with your program preinstalled. At some point we just have to cut our losses and pick a platform that Just Works.
> I don't think I missed it, did I?
You were talking about sandboxing, I was talking about building and distributing software. Sandboxing is an optional thing flatpak provides at runtime, so I'm not sure how it's supposed to make development or distribution easier. It seems we're just talking about different things when we say "sandboxing".
> I mean, I understand that sandboxing your software will make it run on every platform, but so will shipping a VM with your program preinstalled.
Do you know of a VM solution which is as easy to use for developers and users, offers the same or better platform integration and has little to no runtime overhead?
You were talking about sandboxing, I was talking about building and distributing software. Sandboxing is an optional thing flatpak provides at runtime, so I'm not sure how it's supposed to make development or distribution easier. It seems we're just talking about different things when we say "sandboxing".
> I mean, I understand that sandboxing your software will make it run on every platform, but so will shipping a VM with your program preinstalled.
Do you know of a VM solution which is as easy to use for developers and users, offers the same or better platform integration and has little to no runtime overhead?
The author of this has been running with it for a couple of years. Previous HN threads:
https://hn.algolia.com/?query=Flatpak%20%E2%80%93%20A%20Secu...
The tone and varied assortment of alleged issues makes me feel like he started by deciding that Flatpak was bad, and then found whatever he could to support his view.
https://hn.algolia.com/?query=Flatpak%20%E2%80%93%20A%20Secu...
The tone and varied assortment of alleged issues makes me feel like he started by deciding that Flatpak was bad, and then found whatever he could to support his view.
Okay, but is he wrong?
I don't have a horse in the flatpak race at all since I don't use it, but the arguments on this website seem strong. I don't really care what someone's motivation for making a point is, I just care whether they're correct or not.
I don't have a horse in the flatpak race at all since I don't use it, but the arguments on this website seem strong. I don't really care what someone's motivation for making a point is, I just care whether they're correct or not.
It's technically correct in the same way "ants suck - humans on ants racing is a nightmare" is technically correct. Whether it matters for you depends on your environment / what you want to gain from Flatpak.
If you don't use it (as in don't have a use case you want Flatpak to satisfy), then I think the article is neither right nor wrong.
If you don't use it (as in don't have a use case you want Flatpak to satisfy), then I think the article is neither right nor wrong.
It’s technically correct in the sense that allowing users to run arbitrary code is a security nightmare. From my own usage and assessment, flatpak seems to be more secure than traditional package managers.
Security bugs can be fixed. And build pipelines streamlined so flatpaks don't lag behind, but the OP's points about poor KDE integration and lack of internationalization are more worrisome. Flatpaks needs to move beyond GNOME/RedHat bias and patronage in order to be universally acceptable.
Security bugs can be fixed, but security holes from an architectural point of view can’t be easily dealt with.
Okay I had to look up what Flatpak was since the link doesn't begin with a summary, abstract, thesis statement, or overview of whatever the subject is. Would it be so hard to start with "Flatpak, a cross distribution package format [1] for distributing Linux applications, is a security nightmare. We'll outline some flaws we believe to be deal breakers"?
On the other hand, this seems like an attempt to fix application packaging on Linux which is something Linus has, rightly, complained about very publicly [2].
[1] I don't know what to call it exactly, is it a package format or a package manager? Could be something else entirely, I'm not sure.
[2] https://www.youtube.com/watch?v=Pzl1B7nB9Kc
On the other hand, this seems like an attempt to fix application packaging on Linux which is something Linus has, rightly, complained about very publicly [2].
[1] I don't know what to call it exactly, is it a package format or a package manager? Could be something else entirely, I'm not sure.
[2] https://www.youtube.com/watch?v=Pzl1B7nB9Kc
This site has been posted here multiple times in the past. I'd still like to know what the author suggests the alternative should be?
I'm a Qubes OS user, which indeed is a much better solution in terms of security, but it comes with plenty of drawbacks that a lot of users might not be willing to accept. It's also difficult to use for people who are not interested in security.
Right now, there is literally only one project in the Linux community that even tries to address the enormous hole which is Linux security, and that is indeed Flatpak. It's not a perfect solution, and they still have some way to go, but there really is no other way unless you want go to Qubes OS.
I'm a Qubes OS user, which indeed is a much better solution in terms of security, but it comes with plenty of drawbacks that a lot of users might not be willing to accept. It's also difficult to use for people who are not interested in security.
Right now, there is literally only one project in the Linux community that even tries to address the enormous hole which is Linux security, and that is indeed Flatpak. It's not a perfect solution, and they still have some way to go, but there really is no other way unless you want go to Qubes OS.
Have you looked at Firejail? It presents several options to contain applications, working on existing packages and AppImages. You could see it as a more easily configured verfsion of the security parts of Flatpaks without the application parts.
https://firejail.wordpress.com/
https://firejail.wordpress.com/
Firejail can easily suffer from some of the same issues, if it's not configured properly. Some of the issues listed here are not specific to Flatpak, and need to be addressed with any sandboxing mechanism.
Firejail is a tool, and a pretty nice one. But it isn't simple to use yet. But with support for using overlay filesystems for home or root, combined with cgroups isolation and it covers the issues that site brings up.
Flatpak handles all that too, all these tools are using the same Linux security primitives. There is really not any difference between them from a security perspective. Technically flatpak is based around bubblewrap for some of the low level bits, which is kind of like an even simpler version of firejail: https://github.com/containers/bubblewrap
I’ve read a security researcher’s option on firejail - that it is problematic as it is a suid executable. Making a potential bug into a root exploit.
Could someone verify/disprove this? I would guess it drops privileges as soon as they are not needed but didn’t yet have the time to look at it and I have no sufficient knowledge to say whether privilege dropping is enough.
Could someone verify/disprove this? I would guess it drops privileges as soon as they are not needed but didn’t yet have the time to look at it and I have no sufficient knowledge to say whether privilege dropping is enough.
It really depends on what you're trying to do. Doing some things on some distros is still not possible without having the setuid bit.
I have, and while it's likely that I would be able to use it correctly, it's not something most regular users would be able to configure.
And to be honest it seems that to configure firejail to be as secure as possible takes a lot more effort than using Qubes OS. Both solutions seem to be squarely in the domain of people who who understand security, which excludes the people who needs it the most.
And to be honest it seems that to configure firejail to be as secure as possible takes a lot more effort than using Qubes OS. Both solutions seem to be squarely in the domain of people who who understand security, which excludes the people who needs it the most.
> I'd still like to know what the author suggests the alternative should be?
I think MacOS handles app security right.
I think MacOS handles app security right.
Doesn't macos give full access to a trusted application? In order words, if I decide to trust a binary I downloaded from the Internet, it will be able to touch all my files?
What I want to see if that the files an application can use be limited to some subset of all the files on the machine. One can spend a lot of time discussing the level of separation that is appropriate, but just because I trust an application doesn't mean I want it to be able to have full control of my system.
What I want to see if that the files an application can use be limited to some subset of all the files on the machine. One can spend a lot of time discussing the level of separation that is appropriate, but just because I trust an application doesn't mean I want it to be able to have full control of my system.
MacOS does have proper sandboxing but I’m not sure about the granularity of it (I’m not a Mac user).
But ios pretty much does what you want and more, with “select photos you want to be accessible”, etc.
But ios pretty much does what you want and more, with “select photos you want to be accessible”, etc.
It's been easier to achieve this on mobile platforms due to the fact that it's not dependent on old API's that doesn't take compartmentalisation into consideration.
I guess it also helps that mobile users are not generally expecting to be able to use the devices as general purpose computers.
I guess it also helps that mobile users are not generally expecting to be able to use the devices as general purpose computers.
Not allowing users to run any unsigned binaries by default, such as a Go binary from your coworker, is somewhat against the Linux philosophy.
You can run it, but it should not be by default allowed and a warning for its questionable origin is very handy.
You can delete your whole Linux installation with a single dd command.
As I said, this is a matter of philosophy.
As I said, this is a matter of philosophy.
$ spctl --add myFancyBinary
Yes, defaults matter, 99% users don’t have friends that ask them to run their binaries :)
Yes, defaults matter, 99% users don’t have friends that ask them to run their binaries :)
A matter of philosophy. This would not fly in Linux distributions.
None of this represents a regression relative to traditional Linux package management, except that apparently the maintainance of some packages on flathub is not up to the standards of existing major distributions.
I'm guessing that the reason sandboxing rules are so permissive is because the applications in the sandbox aren't designed to run in a sandbox. Not much you can do about that until some sandboxing system becomes standard — chicken and egg problem.
I'm guessing that the reason sandboxing rules are so permissive is because the applications in the sandbox aren't designed to run in a sandbox. Not much you can do about that until some sandboxing system becomes standard — chicken and egg problem.
Exactly. And support for flatpak portals has been improving in qt gtk and electron for a while. So that chicken and egg problem is actually on its way to being solved.
I dislike unfair bashing of projects which the domain name sort of implies, but I can’t help but question the reason for Flatpak and snap to exist.
They are not great as sandboxes (something very dearly needed for linux, correct me if I’m wrong but firejail is suid so it actually can make a potential zero day into a root escalation), and the biggest problem: they suck as a packaging solution. It is the same way as Docker, making it someone else’s problem. I don’t understand why should linux distros badly copy that model when we have Nix, that actually solve dependency management properly. It should be pushed for.
They are not great as sandboxes (something very dearly needed for linux, correct me if I’m wrong but firejail is suid so it actually can make a potential zero day into a root escalation), and the biggest problem: they suck as a packaging solution. It is the same way as Docker, making it someone else’s problem. I don’t understand why should linux distros badly copy that model when we have Nix, that actually solve dependency management properly. It should be pushed for.
Flatpak is a good sandbox. It’s just they have to add a bunch of permissions in so that traditional style desktop apps can still function. You can crank the security to max if you want but it isn’t very useful if gimp can’t open files.
So flapak let’s you say that gimp should have file system access or access to specific folders. But the blog author takes the existence of these permissions as flatpak being critically insecure.
So flapak let’s you say that gimp should have file system access or access to specific folders. But the blog author takes the existence of these permissions as flatpak being critically insecure.
I’m not sure - file access is but one (glaring) hole of linux security. How well does it work with eg. network, audio/video, etc?
There are permissions for both. You can disable network entirely and disable access to X11/Wayland. You can use flatpak to lock down things to the point you can’t do anything anymore.
Previously: https://news.ycombinator.com/from?site=flatkill.org
I don't expect any interesting conversation around this flame bait of a site this time around either.
I don't expect any interesting conversation around this flame bait of a site this time around either.
Flagging should be banned at HN
Flatpak, with all of it's issues, gives me something I did not have before- cross distro packages that work. Maintainers have to do one build for their application and can ship it, and then it works on Fedora, Ubuntu-types, Arch, and others. Ta-da!
Sure, doing package management yourself isn't that hard- but the barriers for the users are higher and it's not as easy to use. You could also get your package into vendor's repositories, but now you have to triage issues from a bunch of distros that might have other issues. It gets messy, vs the solution Flatpak offers.