Live data from Hacker News

Flatpak – a security nightmare

flatkill.org

21–30 of 264 posts

Re: Flatpak – a security nightmare

#21
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.

That’s how macOS sandboxing works too.

Re: Flatpak – a security nightmare

#22
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.

Do you open your files in PyCharm or VSCode through a file picker?

Re: Flatpak – a security nightmare

#24

> 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…

> A bit of Hanlon's Razor[0] goes a long way to resolve problems involving human cooperation (of any kind) more smoothly.

I don't like the snarky tone of the article, but I really thing you're being naive here. Let's examine the facts:

- Flatpak's intent is clear and stated first in in their homepage [1]: "Flatpak is a next-generation technology for building and distributing desktop applications on Linux"

- Red Hat is the company other companies hire to manage their linux systems.

- In the flatpak homepage there's a huge quote stating "The Fedora Workstation team are very excited about Flatpak and the prospects it brings for making the Linux desktop easier to develop for. We plan to continue supporting this effort going forward."

- The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it.

I don't think this is stupidity. This is flat out lying to try and get mindshare.

Re: Flatpak – a security nightmare

#25
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…

[deleted]

Re: Flatpak – a security nightmare

#26
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…

This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers). How can we distinguish between those cases?

Re: Flatpak – a security nightmare

#27
post #19
post #7

Earlier quoted context omitted.

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...

> Well they’re “free” if you buy them alongside hosting.

Depends on hosting company. I've "bought" domains for free many times, without hosting, just to run joke sites for few months.

Re: Flatpak – a security nightmare

#28
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…

The sandboxing platform could offer an API so a sandboxed program can spawn a privileged file-open dialog, and then the sandboxed program is only allowed to modify the file/directory that the user picked.

With the current situation, calling the programs sandboxed is completely misleading.

Re: Flatpak – a security nightmare

#29
post #26
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…

This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers…

This is pretty much the whole point of SELinux (and probably AppArmour)

Re: Flatpak – a security nightmare

#30
So a secure implementation will be written, breaking everyone's code and workflow. The resulting rage of the users will then be used to silence the security concerned, and a great checkbox will be painted under the door-mat [Informed consent is given by foot stomp] and the world rotates on.
Post reply on HN