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

71–80 of 264 posts

Re: Flatpak – a security nightmare

#71

Post by tannhaeuser »

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.

A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/). Maybe Slackware got it right after all by only building from upstream .tgz source archives. We'll see in a decade or two what software is even remotely in a usable state still.

Re: Flatpak – a security nightmare

#72

Post by linuxftw »

pdonis wrote: post #35
zeroname wrote: post #18

Earlier quoted context omitted.

This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. In other words, Linux is secure because nobody can ship software on it without going through massive hurdles and because everybody who is smart enough to install software on Linux does some diligence.

> This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. True, it isn't any less broken than that; it's more broken. First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downlo…

> is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process).

You can totally download binaries from the internet and execute them if they don't require libraries (if the binary even needs any libraries, ie not statically compiled).

You can also download a .sh installer and execute that to install software, it can even create an icon on your desktop (if you even still have one of those that has icons ;) ). Unfortunately, there's a ton of software that installs like this on Linux.

Edit: Grammar

Re: Flatpak – a security nightmare

#73

Post by WrtCdEvrydy »

tannhaeuser wrote: post #71
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.

A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/ ). Maybe Slackware got it right after all by only building from upstream .tgz s…

> We'll see in a decade or two what software is even remotely in a usable state still.

Fucking none of it, that's your answer.

Re: Flatpak – a security nightmare

#74

Post by xfer »

tannhaeuser wrote: post #71
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.

A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/ ). Maybe Slackware got it right after all by only building from upstream .tgz s…

> We'll see in a decade or two what software is even remotely in a usable state still.

Most distributions need non-free explicitly enabled, so almost all packages are open source, so it is irrelevant to distro packaging format.

Re: Flatpak – a security nightmare

#75

Post by rkeene2 »

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…

Such views can also be provided by userspace filesystems (fuse, coda, nfs, 9p, etc).

I have a fuse filesystem that shows different users different views of the filesystem, as a basic example.

Re: Flatpak – a security nightmare

#76

Post by newnewpdro »

This is what happens when you try escape "dependency hell" by turning the host into a composition of hosts-per-application.

Now you have a clusterfuck of dependency islands which all need updating and have their own unique sets of CVEs and upstream release schedules and policies.

It's not really flatpak-specific, this is the reality of containers (in the image/rootfs software distribution sense, not namespaces+cgroups) in general.

Re: Flatpak – a security nightmare

#77

Post by ambrice »

stephenr wrote: post #43
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…

I think the reference is to the fact that on Windows you download some random .exe installer from some place on the internet and trust it, rather than selecting a signed package from a trusted repository that gets automatically updated. Should have been "download it, drag it to your desktop, and install it".

Re: Flatpak – a security nightmare

#78

Post by jessaustin »

TheDong wrote: post #64
kilburn wrote: post #24

Earlier quoted context omitted.

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

The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.

Re: Flatpak – a security nightmare

#79

Post by Conan_Kudo »

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

SELinux labels users and domain transitions, so it's "technically" possible to do so, but I see that incredibly rarely.

I don't think AppArmor has such a facility. It wouldn't make sense, given that AppArmor doesn't know these things like SELinux would.

Re: Flatpak – a security nightmare

#80

Post by pdonis »

Natela wrote: post #62
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 everyth…

> The (long) goal of flatpak is that the user would never download and execute from the browser

Just to be clear; the "download" model I was describing is not "download and execute the actual app from the browser", it is "download and execute an installer from the browser". Then either clicking on the installer or dragging it somewhere (on Macs it used to be dragging to the desktop, but I haven't used Macs for several OS X versions now) starts the installer.

> everything is updated through the flatpak repos (like the PPAs for .deb)

This I would have no problem with; I would be able judge whether I trust their PPA the same way I judge any other third party PPA (or the distro itself, for that matter). And the update would be through the normal mechanism I use to update everything on my system, which has well-tested security measures built into it.

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

I understand the benefits of this as far as fixing dependency hell. But it doesn't seem like the sandboxing part works as advertised.

> Basically the goal is to have something like on Android or IOS

I'm not sure this is a good way to phrase the comparison since it implies not just sandboxing/packaging, but an app store curated by a large corporation whose interests don't align with mine, various broken permissions models, etc.

Post reply on HN