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

221–230 of 264 posts

Re: Flatpak – a security nightmare

#221

Post by IshKebab »

JepZ wrote: post #203
jwildeboer wrote: post #199

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.

Why is it problematic when people hide their identity? I mean, if the criticism is valid, what does it matter who said it? I think hiding the identity is not the real problem here. To me, it looks more problematic, that the critique is not very constructive, one-sided and loaded with imputations.

Everything has some valid criticism, but if one side pushes their particular criticism a lot people might think it is worse than the alternatives.

For example if this site is by the Snap developers...

Re: Flatpak – a security nightmare

#222

Post by IshKebab »

androidgirl wrote: post #110
bubblethink wrote: post #60

I don't see any real benefits to using flatpak in its current form. You get worse integration with the rest of the system, poor tools that are inferior to your system's package manager, and no real security benefits currently. What's the point of launching all these rubbish proprietary apps on the store with no real sandboxing ? It creates a false sense of security, which is worse. All the proprietary apps will do wh…

I use flatpak on my system for the fact that packages can be had there I can't get through my package manager easily and officially. That's the only selling point!

That's a pretty huge selling point - I think it was the main reason for creating them.

The flaw this post seems to highlight is that they shouldn't claim that they are sandboxed when they aren't. But even without sandboxing they're still a good thing.

Re: Flatpak – a security nightmare

#223

Post by dralley »

XorNot wrote: post #191
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.

Take a look at Fedora Silverblue with rpm-ostree, it does basically what you describe

Re: Flatpak – a security nightmare

#224

Post by alxlaz »

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.

Or by a person who does not wish to be on a no-hire list. The job market for Linux developers working on this sort of stuff is not exactly enormous.

Re: Flatpak – a security nightmare

#225

Post by linuxftw »

cyphar wrote: post #138
linuxftw wrote: post #68

Earlier quoted context omitted.

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

> 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. I don't agree. There was a FOSDEM talk by one of my colleagues specifically about this issue, and why Flatpak is walking us backwards in terms of how packaging has worked historically[1]. Distributions are far from perfect (hell, some of them ship my packages and I'm d…

I'm with you, I prefer traditional packaging over flatpak. I usually build from source if I need a newer version than what a distro provides (or if the distro doesn't provide it at all).

Re: Flatpak – a security nightmare

#226

Post by dpwm »

finchisko wrote: post #217
dpwm wrote: post #215

Earlier quoted context omitted.

> 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. If by real you mean the kind of proprietary {ad,spy,toolbar}-ware encrusted "real" desktop software that Windows has become notorious for then I think we may be better off without it. If you're talking about OSX, then I think you're missing that it's…

I like what Microsoft did in UWP. App is allowed to read own files, files explicitly selected by user from Open Dialog. For anything else app developer has to ask for permission and user has to approve it (like in iOS, Android....). Specially the second option is nice, because you as user have a choice to grant access only for specific files and dirs you want app to have the access.

UWP sounds like it gets it right, but a lot depends on the granularity of the permissions. I'm not even sure you can win: too fine grained and the user ends up with permission fatigue and just clicks through, too coarse grained and the user has to choose between full access or no access. I think android gets this very wrong, but has improved somewhat.

I'm not sure if it's been tried but I think a better way might be to create some set of capabilities that can be applied, so you get complete confinement by default but can bulk set permissions of your choosing.

According to design docs, this is what is meant to happen with Flatpak. I'm not a user so I don't know how close it comes.

It appears that Flatpak falls short fo this with quite a few apps, which seems weird if they did implement the file portal they spoke of.

Re: Flatpak – a security nightmare

#227

Post by linuxftw »

zeroname wrote: post #207
pdonis wrote: post #150

Earlier quoted context omitted.

> I, as a developer, am not sure I care. I'm not saying you have to care. If your software is so good that I need to have it, then either my distro will have it, or you'll have set up some kind of distribution infrastructure that I can use securely, or, if I have to, I'll download your source code and build it myself. OTOH, if I don't need your software, and it's not easily available to me securely through my distro,…

> ...then I just won't use it. So far, that seems like a very reasonable compromise for both of us. > Yep, I sure am. I have to be picky to keep my information secure. Most people don't seem to care about that, which is why they're not as picky as I am. Sooner or later it will bite them. I don't see your point. If it's about Microsoft's data collection, that's orthogonal to how software distribution works. Otherwise,…

> Personally, the amount of times that this "packaging and updating infrastructure" has broken working applications or whole Linux installations leads me to believe that no amount of testing will ever make it work reliably.

What distributions have you been using? I rarely have a problem with Debian or Fedora in this manner.

> It doesn't stop at PPA, to really support all the other picky Linux guys with their distributions I need to provide dozens of packages built against the dependencies of whichever versions of those distributions are currently in use.

Get your package into Debian and Fedora, other distros might pick it up. If your software is popular enough, someone might volunteer to do the packaging for you. If it's something I care about and not available, I'll compile it (if it's a compiled language). If it's something I care about and it needs to go into production, I'd build and maintain my own rpms or debs internally.

Re: Flatpak – a security nightmare

#228

Post by irishsultan »

zeroname wrote: post #61
iforgotpassword wrote: post #49

Earlier quoted context omitted.

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.

Honestly, that's not what I would expect sandboxed to mean. By that definition installation in /opt/$vendor/$software/$version would also be sand-boxed.

Re: Flatpak – a security nightmare

#229

Post by MayeulC »

Shorel wrote: post #218
ricardobeat wrote: post #213

Earlier quoted context omitted.

The sandbox is there for portability. I don't see a promise of being _more secure_ than other app distribution channels on linux anywhere. Though the packaging & sandboxing model certainly opens a path for improvements in the area. Is it any less safe than installing something via aptitude or Ubuntu's app store?

The alternative if using Ubuntu is called Snap. It has a sandbox and it is better implemented, at the very least the part about reading and writing in home dir.

As far as I was told, snap sandboxing only works with a specially-patched (and apparmor-enabled) kernel [1], though I am not sure what the current status is.

I would like to know what's better implemented in snap, it seems this is simply a case of most applications requesting a r/w permission in the home directory. It might get complicated sandboxing vs code without that, don't you think? Or at least lead to a subpar user experience.

I am hopeful it will improve, though. Sandboxing needs to become the default.

[1]: https://web.archive.org/web/20170615042616/https://github.co...

Edit: Similar echo here https://news.ycombinator.com/item?id=18180877

Re: Flatpak – a security nightmare

#230

Post by MayeulC »

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?

For now, the GUIs are as far as I know, but there is a `flatpak override` command that seems promising for changing an installed application's permissions.
Post reply on HN