Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak – a security nightmare

flatkill.org

Post reply on HN
Print view View original

11–20 of 264 posts

Re: Flatpak – a security nightmare

#11

Post by briffle »

vanderZwan wrote: post #6

> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security. Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion l…

Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by the developers to maintain it)

In fact, it could be nicer if it catches on, as developers won't need to maintain deb files, rpm files, pacman files, etc.

Re: Flatpak – a security nightmare

#13

Post by dralley »

Cross-posting a comment from Reddit, because it nails one of the points mentioned:

---

The list on the page is

    Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ...
With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action causes a prompt.

Now, that's not to say this is good as it is, but for most listed programs it's probably the way to go.

Re: Flatpak – a security nightmare

#14

Post by jopsen »

flatpak is still early.. most apps are still installed from package managers, and few apps are written with flatpak in mind.

The current situation is probably not much worse than installing from various third party package archives.

I suspect things will get better as adopting catches on.. it's no surprise that early stage open source software have rough edges.

Re: Flatpak – a security nightmare

#15

Post by gmueckl »

vanderZwan wrote: post #6

> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security. Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion l…

Most of the issues that are expicitly mentioned are fixable bugs and not fundamental design errors. In the end it seems to come down to poor package repository maintenance, which many repositories for Linux distros suffer from. While I do not like the idea of flatpak very much myself, this criticism seems too harsh to me.

Re: Flatpak – a security nightmare

#16

Post by blattimwind »

dralley wrote: post #13

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action c…

File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.

Re: Flatpak – a security nightmare

#17

Post by briffle »

Kalium wrote: post #8
glglwty wrote: post #4

Is the sandboxing of flatpak more or less secure than docker?

As I understand it, from reading this page it doesn't actually matter much how secure the sandbox is as many applications effectively disable it.

And many docker users run privileged containers, because then they don't need to troubleshoot permissions.. It doesn't meant the underlying system is flawed, because people take the lazy way around it.

I'm thinking of all the blogs back a few years ago for setting up things on Centos. Step 1, disable SELinux.. That was never recommended, but the blog writers didn't want to go into details about how to manage selinux, or couldn't understand it.

Re: Flatpak – a security nightmare

#18

Post by zeroname »

pdonis wrote: post #2

I share this writer's concerns with Flatpak. It looks to me like yet another attempt to bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux.

This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained.

In other words, Linux is secure because nobody can ship software on it without going through massive hurdles and because everybody who is smart enough to install software on Linux does some diligence.

Re: Flatpak – a security nightmare

#19

Post by Ecco »

TeMPOraL wrote: post #7
Ecco wrote: post #5

Wait a minute, did somebody get so pissed at flatpak that they bought a domain name just to specifically host that single blog post?

Domains are cheap. Often free for one year.

Well they’re “free” if you buy them alongside hosting. Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc...

Re: Flatpak – a security nightmare

#20

Post by arthurfm »

lvh wrote: post #9
glglwty wrote: post #4

Is the sandboxing of flatpak more or less secure than docker?

They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are wors…

> I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use.

binctr looks like an interesting solution to tackle this issue.

[1] https://blog.jessfraz.com/post/getting-towards-real-sandbox-...

[2] https://github.com/genuinetools/binctr

[3] https://news.ycombinator.com/item?id=18180276

Post reply on HN