Flatpak – A Security Nightmare
flatkill.org
flatkill.org
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.
Your move, I guess.
These two I always remember. So that's maybe why
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.
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.
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.
https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
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.
What I suggest is that Flatpak could provide something similar, by having a completely separate filesystem used by the tool.
Also, Python developers seems to be dealing with this stuff on a daily basis with virtualenv, so this isn't something new.
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.
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.
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 think MacOS handles app security right.
Yes, defaults matter, 99% users don’t have friends that ask them to run their binaries :)
As I said, this is a matter of philosophy.
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.
But ios pretty much does what you want and more, with “select photos you want to be accessible”, etc.
I guess it also helps that mobile users are not generally expecting to be able to use the devices as general purpose computers.
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.
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.
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.
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.
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.
Everything else is just more work for application developers and distributors won't include every application in their repositories.
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.
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?
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.
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.
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.
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.
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.
I don't expect any interesting conversation around this flame bait of a site this time around either.
We get it, you're upset. "Tone of voice" on this chips away at reader sympathy.