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

41–50 of 264 posts

Re: Flatpak – a security nightmare

#41

Post by ReverseCold »

TeMPOraL wrote: post #22
blattimwind wrote: post #16

Earlier quoted context omitted.

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?

You open the parent project directory, right? That's how the file access controls work in MacOS. Sandboxed apps can't read files outside their sandbox until the user opens the directory/file in the file picker at least once. (Or something similar, I can't seem to find a source on that...)

Re: Flatpak – a security nightmare

#42

Post by vanderZwan »

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…

Could you link to the comment? Would like to read the discussion on Reddit too.

Re: Flatpak – a security nightmare

#43

Post by stephenr »

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.

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

Wat?

Windows famously doesn’t have “just drag it to your desktop” to install. There’s an entire segment of the industry around building installers and managers for installation of windows programs.

And I can’t recall a single mac-affecting malware that spread the way you describe except maliciously modified versions of pirated commercial software (eg adobe stuff) which doesn’t actually install via drag and drop anyway - it has an “installer” if its own.

Re: Flatpak – a security nightmare

#44

Post by geofft »

briffle wrote: post #29
gmueckl wrote: post #26

Earlier quoted context omitted.

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)

How does SELinux or AppArmor distinguish between those cases? More interestingly, how can it tell that VSCode spontaneously editing .bashrc is bad, but doing so in response to user input is good?

(There are capability-based systems that permit distinguishing between these cases, but to my knowledge SELinux and AppArmor don't support this.)

Re: Flatpak – a security nightmare

#45

Post by audidude »

zeroname wrote: post #32

"Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it." No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects fl…

If we could get applications to switch to using APIs backed by the xdg-desktop-portal, then they don't even get access to the host/home filesystems. They talk to a service which sends a FUSE FD to the app, and that overwrites the original file when close()d (but never does the app get direct filesystem access).

Gtk added GtkFileChooserNative for just this purpose. It implements the same file-chooser interface as other dialogs so in many cases is a couple line change to apps. Sadly, it can't be done automatically because various API/ABI reasons.

Re: Flatpak – a security nightmare

#46

Post by anon_cow1111 »

Random mint 18.04 user here.

I just noticed about a week ago that flatpak was downloading huge amounts of data (like hundreds of MBs). I had all system updates set to download and install manually, and hadn't installed anything new for at least a month. All this data was getting sent to /var/tmp as flatpak-cache folders.

I don't know what it was doing but I've since turned it off in the startup list. Any ideas? What are the chances this was malicious?

Re: Flatpak – a security nightmare

#47

Post by audidude »

AgentME wrote: post #28
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…

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.

You've described the xdg-desktop-portal. Gtk apps just need to switch to GtkFileChooserNative and they get that for free. It does an FD pass of a FUSE fd and the app never gets file-system access.

It also has the benefit of using the KDE file-chooser on KDE, Windows file-chooser on Windows, mac, etc...

Re: Flatpak – a security nightmare

#48

Post by nickysielicki »

1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged.

2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub.

3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a package to make sure that permissions are perfect. There is no reason that these issues can't be ironed out going forward.

Re: Flatpak – a security nightmare

#49

Post by iforgotpassword »

zeroname wrote: post #32

"Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it." No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects fl…

Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not. A flatpack sharing any part of the host file system with the app should be marked as insecure when installing and/or launching.

Re: Flatpak – a security nightmare

#50

Post by wongarsu »

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…

Most use cases of VLC only open files, so giving it universal privileges to open files but a prompt on filesystem writes would be fine. Gimp could have universal read and the right to create new files, but overwriting files it didn't create itself restricted behind a permission prompt. Same for Inkscape and Audacity.

If you want to push this further, you could imagine a permission system that can distuingish based on file types. Gimp overwriting a PNG is probably intended, Gimp overwriting a bash script probably not.

There's a lot more nuance in existing systems (SELinux) and potential future systems than just "allow everything or nothing".

Post reply on HN