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

61–70 of 264 posts

Re: Flatpak – a security nightmare

#61

Post by zeroname »

iforgotpassword wrote: post #49
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.

> Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not.

It is isn't being sold as "secure". It's sandboxed in the same way that Python virtual environment is sandboxed, i.e. you're not messing with the system software installation. Real security sandboxing is a completely orthogonal feature that package managers do not deliver either.

Re: Flatpak – a security nightmare

#62

Post by Natela »

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.

What ? No it's exactly the opposite ! I think you're confusing with AppImage maybe which is indeed download from the browser & run.

The (long) goal of flatpak is that the user would never download and execute from the browser, everything is updated through the flatpak repos (like the PPAs for .deb) but with the addition that the apps are sandboxed and follow a runtime model for dependency instead of packaging everything or depending on other packages.

Basically the goal is to have something like on Android or IOS , so exactly the opposite of the "download from the browser and run an untrusted executable"

Re: Flatpak – a security nightmare

#63

Post by viraptor »

geofft wrote: post #40
kilburn wrote: post #34

Earlier quoted context omitted.

> his other major gripe is that the security updates for non-official flatpaks I don't know whether it is true or not, but the author explicitly states that it is the official applications AND runtimes that aren't properly maintained. > 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 No you don't, becaus…

The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. The Debian security team is a volunteer team, and it's entirely realistic that someone may actually have seen delays in the packages they care about getting security updates. "No you don't" is arrogant - you have no way of knowing that.

> The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen.

Actually they do. Debian does carry local patches when necessary. It will also backport patches to release in older versions which may not be updated upstream. They literally make the updates happen.

In this case, it's valid to ask - where/when did you see the issue with this working.

Re: Flatpak – a security nightmare

#64

Post by TheDong »

kilburn wrote: post #24
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…

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

> 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

They are using those features. flatpak has network namespaces for applications that don't need access to the network and bindmounts for applications that use very limited parts of the filesystem.

Sure, in reality many desktop apps have more far-reaching permissions, but all they're saying is that flatpak can make use of those features in some cases.

> This is flat out lying to try and get mindshare

Usually that's just called marketing. I don't think any of the above statements are actually lies in any way though. Can you point to what's actually a lie, or what lie is implied in your mind?

Re: Flatpak – a security nightmare

#65

Post by TheDong »

gmueckl wrote: post #15
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.

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

Until then, this issue will be tricky to fix. I, of course, agree with your main point that things like updating packages more is fixable and the post is overly harsh and critical of what's effectively "things aren't perfect" with no empathy for how complicated stuff can be.

Re: Flatpak – a security nightmare

#66

Post by Natela »

aritmo wrote: post #55
nickysielicki wrote: post #48

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…

But Flathub is flatpak. Also, does flatpak have the full support of redhat?

No. Flathub has nothing to do with flatpak technology itself. Flathub is just one server hosting some flatpack repos.

It's like saying .deb is Ubuntu Store. Well no, it is just one PPA among many other you could add to get your apps

Re: Flatpak – a security nightmare

#67

Post by Natela »

nickysielicki wrote: post #48

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…

Thank you ! This should be 1st. Many people don't understand this it seems

Re: Flatpak – a security nightmare

#68

Post by linuxftw »

RX14 wrote: post #56

What a lot of people are missing is that flatpaks put the flatpak author responsible for the security of every package inside the flatpak. If you use a package from an unofficial rpm or deb repo, they're nearly always still dynamically linked, so security updates for things like openssl still apply.

> they're nearly always still dynamically linked, so security updates for things like openssl still apply.

Could be, or might not be. It's easy enough to ship compiled libraries in the same rpm/deb as the software you ship, or put your defunct versions into the same unofficial repo under a different name and have your application pull from there. In fact, they might not use openssl at all, possibly some other half-baked library. Of course, that's for languages that are compiled; people can vendor in all sorts of stuff into python sources. Don't even get me started on golang.

Installing software from any source involves risk. Distribution repos help mitigate some of that risk. Flatpaks as a technology don't change the risk (significantly) from a bit-rot point of view IMO.

Post reply on HN