Flatpak – a security nightmare – 2 years later (2020) • Hacker News Board

Re: Flatpak – a security nightmare – 2 years later (2020)

#211

Post by andagainagain » Sun, Mar 21, 2021, 4:10 PM UTC

vorticalbox wrote: post #188

> The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed. All of these require access to the users data to actually function. GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media these apps have the same "problem" in snap requiring --classic to allow ac…

Question then - does flatpak require an explicit flag when installing them to access those files? Or is it as I assumed just "flatpak install"

Re: Flatpak – a security nightmare – 2 years later (2020)

#212

Post by GekkePrutser » Sun, Mar 21, 2021, 4:11 PM UTC

From the article:

> The flatpak runtimes and apps do not get security updates

This is exactly what I worry about with things like Flatpak and Snaps (Ubuntu).

Instead of having the distro maintainer provide timely security updates, all they have to do now is shrug and point at the external package maintainer. So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update. This is clearly not going to work as well.

And while sandboxing is a great idea, it can be done using other methods too, like SELinux or AppArmor.

Not to mention the wasting of resources by running all those separate versions of each library.. But that's not security-related discussion.

Re: Flatpak – a security nightmare – 2 years later (2020)

#213

Post by vetinari » Sun, Mar 21, 2021, 4:15 PM UTC

tjoff wrote: post #206

vetinari wrote: post #184

Earlier quoted context omitted.

And then have a barrage of users complaining that their app packaged in flatpak doesn't work.

Users are stupid, but they are not as stupid to press no on a request to allow an application to open files and then complain that no files exist.

As an counterargument, see all the comments to this article.

Most people here comment on something they have exactly zero idea about how the security model works, how the transition (i.e. holes in the sandbox and the reasoning behind them) works and what is the intended end-result (portals).

Re: Flatpak – a security nightmare – 2 years later (2020)

#214

Post by Pxtl » Sun, Mar 21, 2021, 4:15 PM UTC

Ar-Curunir wrote: post #43

gspr wrote: post #28

Earlier quoted context omitted.

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.

This. I would expect a modern permissions model to be:

App has access to its own config/cache folders, and is implicitly and temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.

Possibly something more liberal could be granted for read permissions for like a gallery app or a music library thing, but that's what I'd expect for write permissions.

Re: Flatpak – a security nightmare – 2 years later (2020)

#215

Post by tsimionescu » Sun, Mar 21, 2021, 4:22 PM UTC

oxylibrium wrote: post #148

krick wrote: post #125

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, a…

I'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundred…

> It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem.

This isn't entirely true - you need something like Administrator access (so at least a UAC prompt) to create a Windows Service, whereas all software you run on Linux will normally have access to write to your .bashrc.

Of course, if we're talking about installers and not random .exe's, where users are already conditioned to allow installers to run as Administrator, the problem re-surfaces.

A bit closer to editing .bashrc in Windows is the peculiarity that Windows DLL search order normally starts from the directory where the .exe was loaded from. So, any .exe in a User-writable location that loads a DLL can be tricked into running malware by creating/overwriting a malicious DLL of the same name there (this doesn't work for Windows DLLs, though).

Re: Flatpak – a security nightmare – 2 years later (2020)

#216

Post by tjoff » Sun, Mar 21, 2021, 4:26 PM UTC

vetinari wrote: post #213

tjoff wrote: post #206

Earlier quoted context omitted.

Users are stupid, but they are not as stupid to press no on a request to allow an application to open files and then complain that no files exist.

As an counterargument, see all the comments to this article. Most people here comment on something they have exactly zero idea about how the security model works, how the transition (i.e. holes in the sandbox and the reasoning behind them) works and what is the intended end-result (portals).

Imho not nearly the same thing.

Re: Flatpak – a security nightmare – 2 years later (2020)

#217

Post by ravi-delia » Sun, Mar 21, 2021, 4:30 PM UTC

This is quite late, but I thought I'd add my two cents. I use Linux as my only daily driver, and in general I use my distro's package manager. I keep secure by not running random executables and keeping updated, but I'm no infosec engineer and there is a 0% chance that anyone who knew what they were doing couldn't work around everything I have.

Flatpak for me is incredibly useful in a narrow use case; other people put in the work to make stuff work without cluttering my damn home directory! Specifically it's helpful for Steam. Why every game on the planet feels the need to fill my home directory with UNHIDDEN directories with spaces in the name (!!!) is absolutely beyond me.

Re: Flatpak – a security nightmare – 2 years later (2020)

#218

Post by psanford » Sun, Mar 21, 2021, 4:33 PM UTC

jart wrote: post #52

Am I the only one who sees the irony in it being a scandal for free software to fail to adequately restrict freedom? I just can't imagine an iPhone style restrictions model ever gaining momentum in open source. As much of a prize an App Store would be, it's just too at odds with the culture. I think what makes more sense for open source is to have better tools for monitoring what it's doing. The behavior of some of t…

I see flatpak and snap as potential solutions to the problem of distributing proprietary software to Linux. Its in that usecase that I really want sandboxing and where the current solutions are lacking.

Right now I'm most happy with Firejail for sandboxing proprietary applications. It doesn't solve the packing problem but seems to do the best job at actually limiting what applications can do.

Re: Flatpak – a security nightmare – 2 years later (2020)

#219

Post by pcr910303 » Sun, Mar 21, 2021, 4:35 PM UTC

Pxtl wrote: post #214

Ar-Curunir wrote: post #43

Earlier quoted context omitted.

The problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.

This. I would expect a modern permissions model to be: App has access to its own config/cache folders, and is implicitly and temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box. Possibly something more liberal could be granted for read permissions for like a gallery app…

> temporarily granted access to a file or directory on a process-lifespan basis when that file or dir is fed to that app through the file browser or through the application's "open file" file dialog box.

I’m not sure if it’s temporary or process-lifespan basis, but AFAIK macOS’s sandbox does have a model where the user must grant access by using the system-provided out-of-process file dialog for the application to be able to access the files.

Pretty interesting. For an example, try renaming a file in MS Words by clicking on the document icon — you’ll see MS office asking for permission for the access of the parent directory. (Apple does provide rename functionality by it’s APIs, but MS Word does it by it’s own, which requires the permission.)

Re: Flatpak – a security nightmare – 2 years later (2020)

#220

Post by danShumway » Sun, Mar 21, 2021, 4:36 PM UTC

gspr wrote: post #160

higerordermap wrote: post #71

Earlier quoted context omitted.

The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.

> We know some things are objectively better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Absolutely. That's why the comment that makes you characterize me as a luddite explicitly referred to the "sandbox everything wave". Sandboxing has its place. Sandboxing everything (i.e. the "Flatpak way") is what I'm commenting on.

I think that GP's point still stands. Application security on most native platforms right now is a disaster. But application security on Linux is a dumpster fire. Yes, there are ways to do it better with SELinux, yes there are ways to isolate apps, but they're overcomplicated, inaccessible, and the end result is that most consumers don't use them.

Flatpak, for all of its many faults (and there are a lot of them), is still a strict improvement over the current security model running on most desktop Linux computers. Sandboxing native applications (even partially sandboxing them) is objectively better than the status quo.

It is embarrassing that the Linux community is still having this debate. It is exhausting, it feels like the community has to be dragged kicking and screaming away from a 20-year old security model that every other platform has moved on from.