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

191–200 of 264 posts

Re: Flatpak – a security nightmare

#191

Post by XorNot »

djsumdog wrote: post #171

Ugh. This trade off again. Linux package management means you update a library once, and fix that security problem everywhere for all the apps that use that library .. except for Firefox, Libreoffice, Chrome and others which insist on packaging their own versions of libjpeg, libpng and everything under the sun for stability. A docker container contains all its own dependencies too. You gain stability .. but you could…

Linux needs a deduplicating filesystem though in the kernel. Something to make containers and docker handle the situation of "lots of mostly identical files" well. Even ZFS, which should be good at this, really isn't.

Re: Flatpak – a security nightmare

#192

Post by alkonaut »

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…

A document editor will want to write to the users documents directory.

Is the problem here that the user home dir both contains typical locations for user data and writing files with certain names to it will automatically execute ,such as ~/.bashrc?

Wouldn't it be better if the app only had permission to write to an actual user documents/data directory, rather than the home root? Which begs the next question: is there a standardized user document/data directory for desktop linux that isn't just "~"?

Re: Flatpak – a security nightmare

#193

Post by toyg »

dpwm wrote: post #142
gbraad wrote: post #100

Earlier quoted context omitted.

Fedora and Red Hat are not the same thing. Sure, there is a relation between the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion in RHEL. I just wonder why the author of this page does not disclose his name... And even hides this from the whois info. This could have been written by a person with a grudge for all I am concerned. Sure, improvements might be needed, but haa the author tried to…

> I just wonder why the author of this page does not disclose his name... > And even hides this from the whois info. The registrant country is listed as France and the registrar is OVH. They are simply adhering to the GDPR. I have domains that have been like this since May, even though I would be quite happy to have everything public. > This could have been written by a person with a grudge for all I am concerned. Yo…

The problem is that distro package managers are many and often complex to satisfy, which is one of the reasons people don’t develop “real” desktop software for Linux.

The new generation of installers (flatpak, snap etc) takes a cross-distro approach that is supposed to result, more or less, in “package once, run everywhere”: you build your app in a certain way and every distro should be able to run it, regardless of package managers. It’s basically a way to offload the compatibility headaches to flatpak developers and distribution builders.

Obviously that approach works only if flatpak does actually get good support in all distributions and becomes a de-facto standard, which is a challenge because there are many competitors (Ubuntu Snap being the most relevant one). If it remains just a glorified rpm (i.e. a redhat-specific tool), then there is no point.

Re: Flatpak – a security nightmare

#194

Post by im3w1l »

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

The reason applications spew files all over the place is because that's how you hook into other systems. Want a man-page? There's a folder for that. Want to autostart? Folder for that. Want your program to be runnable without specifying the full path? Put it in path.

The reason configuration sucks is because we use filesystems, which are necessarily hierarchical, when we should use a more general database.

If we had a table where the first column was "thing to be configured" and the second column was "program" things would be much better. We could query by the first column to get e.g. all programs that want to automatically start, or all programs in path. Or we could query the second column to get all configuration for a given program.

Database people have done a lot of work on how to prevent inconsistent state, and we are stupid for not leveraging that.

Re: Flatpak – a security nightmare

#195

Post by popey »

Conan_Kudo wrote: post #116
niemeyer wrote: post #111

Earlier quoted context omitted.

> I don't think it's the majority _per se_ (since Ubuntu Core can't run those), but most of the popular ones likely do. No, that's also incorrect if you slice it by popularity. We don't have a public chart easily filtered by these aspects together, but just pick some random samples. It's also easy to see that based on the low volume of classic snap requests in the forum, vs. the volume of actual snaps published and a…

My understanding is that we still can't fully confine stuff using Electron (VSCode, Atom, Skype, etc.). Did that change recently?

Not true. The snaps you list are not classic by virtue of being electron. There's plenty of electron apps in the snap store which are not classic, but strictly confined. It's the default for electron apps built with electron-builder.

Re: Flatpak – a security nightmare

#196

Post by v_lisivka »

djsumdog wrote: post #171

Ugh. This trade off again. Linux package management means you update a library once, and fix that security problem everywhere for all the apps that use that library .. except for Firefox, Libreoffice, Chrome and others which insist on packaging their own versions of libjpeg, libpng and everything under the sun for stability. A docker container contains all its own dependencies too. You gain stability .. but you could…

In Fedora, Firefox, LibreOffice, and Chromium are contain no bundled libraries. Main offenders of "no bundled lib" rule are Go and Rust applications.

Re: Flatpak – a security nightmare

#197

Post by laurent123456 »

jbk wrote: post #31

> VLC [...] filesystem=host See my comment on why it's not easy to fully sandbox software like VLC: https://news.ycombinator.com/item?id=14409234 The author is correct, in the fact that flatpak-vlc is not a secure sandbox.

Thanks for sharing the info. I'm just curious - how would splitting VLC into multi processes solve the permission issue, since the sub-processes will still need access anyway?

Re: Flatpak – a security nightmare

#198

Post by syshum »

gbraad wrote: post #100
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…

Fedora and Red Hat are not the same thing. Sure, there is a relation between the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion in RHEL. I just wonder why the author of this page does not disclose his name... And even hides this from the whois info. This could have been written by a person with a grudge for all I am concerned. Sure, improvements might be needed, but haa the author tried to…

>>I just wonder why the author of this page does not disclose his name...

That is a weak argument to rebut the article. The author should not matter only the facts

Either what this person has claimed about Flatpak is true, or it is not

You do not need the persons name, address, and background to form that conclusion.

The only reason to demand that is to exert public pressure on them likely in an effort to silence them. Anonymous Speech is a cornerstone of a free society

Re: Flatpak – a security nightmare

#199

Post by jwildeboer »

Disclaimer: I work for Red Hat

I strongly oppose these kind of attacks by people hiding their identity. No matter how valid the criticism might be, this goes against all the ethics of Open Source.

Just like the Devuan folks that vigorously attacked systemd and Lennart.

This must not be tolerated.

Yes, I’m very upset.

Re: Flatpak – a security nightmare

#200

Post by mfukar »

gbraad wrote: post #100
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…

Fedora and Red Hat are not the same thing. Sure, there is a relation between the two, but inclusion in Fedora is not an endorsement or guaranteed inclusion in RHEL. I just wonder why the author of this page does not disclose his name... And even hides this from the whois info. This could have been written by a person with a grudge for all I am concerned. Sure, improvements might be needed, but haa the author tried to…

> This could have been written by a person with a grudge for all I am concerned.

So glad that you can judge his points regardless of that irrelevant information, then.

Post reply on HN