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

181–190 of 264 posts

Re: Flatpak – a security nightmare

#181

Post by kilburn »

AnthonyMouse wrote: post #149
altfredd wrote: post #104

Earlier quoted context omitted.

There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before. Programmers like to come up with clever wa…

> Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. That is not very good. Suppose you create an audio file with Audacity and a series of images with ImageMagick and GIMP, then use ffmpeg to combine them into a video and VLC to view it. They're all operating on the same files. What we need is to add an application list to filesystem ACLs and then have security groups like…

If you are interested in trying something similiar, this is what Qubes OS [1] does, albeit with a different implementation (separate VMs for separate tasks).

It is more cumbersome to use than the current mainstream paradigm, but not that much!

[1] https://www.qubes-os.org/intro/

Re: Flatpak – a security nightmare

#182

Post by michaelmrose »

danilocesar wrote: post #172
yellowapple wrote: post #147

Earlier quoted context omitted.

In flatpak you are worse off, though, since - as the article indicates - they lag behind on security updates. If they get compromised by unpatched exploits, that sandbox is a valuable line of defense.

The writer tries to blame Flatpak for app maintainers mistakes. That isn't fair. If an app doesn't get an security fix whoever maintains that package should be the one to blame. Disclaimer: I don't like flatpak either, I'm just trying to be fair here...

This is a fair point. Tons of people said that flatpaks wont get security updates because you would end up with 7 versions of libfoo getting updated, or not, on different schedules.

Lo and Behold this is true.

The security gains even in the future are also probably mostly imaginary. You can't trust average users to understand the implications of granting permissions. By default if they are installing an app they trust the dev.

Further its not like malicious actors can't test against the sandbox and do the extra work to discover ways through the fence. Getting your target to run your malware tends to be game over outside of very heavily restricted environments.

If the browser had a build in fashion to ask the user to give them full control of the machine in a way that didn't look like malware 20% of users would end up with compromised devices.

Re: Flatpak – a security nightmare

#183

Post by Ndymium »

jonstewart wrote: post #176
derefr wrote: post #148

Earlier quoted context omitted.

It's a sandbox like Android has a sandbox: each app lists a set of capabilities; the user gets a dialogue on installation where they have to grant those capabilities (or else cancel the install); and then for anything the app tries to do that's not in that set of capabilities, it fails. A sandbox doesn't mean "you can never do [foo]." A sandbox means "you can never doo [foo] unless the user lets you." Even web browse…

Is it also like Android's "sandbox" in that every application asks for every permission and the only choice is between "no security" and "can't install anything useful" and inures the user to just click "accept" on everything?

Android's permission system was overhauled in version 6 so that permissions are now generally asked when they are needed, for a specific type of operation, instead of the big dialog when installing.

I personally use several apps where I have granted one set of permissions and denied another (because it was for a feature I don't use). It has gotten a lot better than what it used to be.

Re: Flatpak – a security nightmare

#184

Post by microtonal »

TheDong wrote: post #65
gmueckl wrote: post #15

Earlier quoted context omitted.

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.

The fact that many desktop applications need access to $HOME and that $HOME also conveniently provides arbitrary code execution via .bashrc/.profile/etc is kinda fundamentally at odds with doing filesystem sandboxing of desktop apps. Sure, flatpak isn't making things worse by not being able to fix the fact that desktop users expect to open $HOME/screenshot.png in gimp, but it's also not going to easily fix that. This…

This is fixable on android / chromeos by specifically having applications request access to data which is isolated from arbitrary code execution (e.g. "user files" which don't include .bashrc). I think flatpak may need to ultimately have a custom file-browser where the user can "share" subsets of files into a sandbox and then patch applications to use that file browser... or to otherwise build a new filesystem abstraction.

It does have that through portals:

https://github.com/flatpak/xdg-desktop-portal

If you Flatpak a Gtk+ 3 or modern Qt application you get portals for free. E.g. I packaged a Qt application and I am not sharing the home directory - when the user opens a file it uses the Qt/KDE portal (similarly to macOS, ChromeOS, etc.).

As far as I understand the problem is that portals are only available for Gtk+ and recent Qt versions. Some of the applications that the posts mentions use toolkits that probably don't support portals (Java JDK, wxWidgets, etc.).

The situation for Linux is a bit different than e.g. macOS, where practically everything uses Cocoa and Apple could just throw the switch.

So, for applications that do not use vanilla Gtk+ or Qt they still need to make the home directory visible or they would not be Flatpack'able.

Re: Flatpak – a security nightmare

#185

Post by microtonal »

derefr wrote: post #157
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…

Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt. 2. documents consisting of many files are structured into project bundles; you open—and thus grant access to—the entire bundle at once. 3. the GUI is structured to orient activity around documents rather than around applications. You hardly ever launch an app and then open a file in it. Instead, you open the document and the…

Ways macOS handles the this problem: 1. the File Open dialog is itself the permission prompt.

And yet, there are quite some applications that ask you to open the home directory once so that it gets symlinked into their sandbox. It's basically a hack to say 'I need access to your whole home directory'. Of course, it is safer than permitting access by default.

Of course, in many cases there are good reasons (backup software, space usage analyzers). But not everything can be mediated through file dialogs.

Re: Flatpak – a security nightmare

#186

Post by jniedrauer »

geofft wrote: post #44
briffle wrote: post #29

Earlier quoted context omitted.

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

Directory trees and files have a security context (etc_t, user_home_t, and so on), and there are rules governing which application contexts are allowed to access or modify which security contexts. It doesn't cover every edge case, and it can be frustrating to deal with things like local docker development. But the added safety is absolutely worth it to me.

Re: Flatpak – a security nightmare

#187

Post by p2t2p »

p2t2p wrote: post #113

Trust me, nobody cares. The regular user doesn't go past "I can install Spotify in one click". It always were like that and it always will be like that. With more "normies" coming to Linux there will be more stuff like that. That is exactly why people were saying that there are no viruses on Linux only thanks to lower popularity. And with all honesty - how many of us read script files when installing something from A…

Downvoted without replies... Does anybody find statement that most users don’t spend too much time to ensure security of their machine offensive or incorrect? I know only myself and few other fairly geeky people doing that...

Re: Flatpak – a security nightmare

#188

Post by andreyv »

Flatpak, Snap, container images are the new iteration of static linking.

Just like with static binaries, they make deployment easier for the developer, but introduce problems with size, duplication and library updates.

Flatpak added runtimes [1] to alleviate the problem. Does this solution look familiar? Yes, it is the same dynamic library concept. We are coming full circle.

[1] http://docs.flatpak.org/en/latest/available-runtimes.html

Re: Flatpak – a security nightmare

#189

Post by ahreflink »

vanderZwan wrote: post #42
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.

https://old.reddit.com/r/linux/comments/9ms96u/flatpak_secur...

Re: Flatpak – a security nightmare

#190

Post by derefr »

AnIdiotOnTheNet wrote: post #170
derefr wrote: post #152

Earlier quoted context omitted.

Those aren't "package formats"; they're different names for a very small set of actual container formats (e.g. tar, zip), with the names there to namespace different incompatible OS file-layout hierarchies and sandboxing technologies. If it was just about packaging, everyone would just have a build server that creates their binary once and then slams it through https://github.com/jordansissel/fpm . But there are more…

Hmm... it's almost like maybe applications shouldn't spew their files all over in the first place, then you wouldn't have to worry about putting them in the wrong places...

If you can tell me what a self-contained equivalent to, say, the libpam package would be, I’m all ears.

Oh, also, a subset of case 2 is: packages that contain servers need to register the server as a service with the OS’s init system, and every OS has its own init system that expects a service definition file in its own distinct format and location.

Post reply on HN