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

201–210 of 264 posts

Re: Flatpak – a security nightmare

#201

Post by nickik »

Flatpak and Flathub are not hiding this and nowhere on Flathub does it claim that all Flathub apps are securely sand boxed. Flathub has unoffical packages and this it has the same issue like all other unoffical repos.

Flatpak CAN be used to do sandboxing, but that totally different from saying 'all application will be securely sandboxed'. I don't know where the authors got this idea from.

The simple fact is, that sandboxing on a legacy system is difficult and Flatpak can't magic away many of the security issues in the Linux desktop.

Also all the 'Red-Hat Developers' evil reminds me of the typical Systemd-hate rant and I really hope we don't have to suffer another iteration of this in the Open-Source community. The person that leads the project works for Red Hat, but its not a Red Hat project.

Re: Flatpak – a security nightmare

#202

Post by nickik »

wbond wrote: post #135
v8engine wrote: post #130

Earlier quoted context omitted.

I don't know about git integration but as for Flatpak version of Sublime Text, I found this: https://flathub.org/apps/details/com.sublimetext.three

Yes, it appears that the flathub maintainers have published Sublime Text under flathub. This is not an official distribution channel by us, and looking at the spec ( https://github.com/flathub/com.sublimetext.three/blob/master... ) it seems to rather automatically install Package Control, but also in a rather brittle way. Sigh.

If many distros and people want to use a flatpak to install software even with these drawbacks that would be a good indication that it would be worth doing upstream.

Re: Flatpak – a security nightmare

#203

Post by JepZ »

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.

Re: Flatpak – a security nightmare

#204

Post by JepZ »

confounded wrote: post #97
JepZ wrote: post #23

This is especially bad for projects like Linphone (open source SIP Client) which exclusively provide Flatpak-builds for Linux [1]. [1]: http://www.linphone.org/technical-corner/linphone/downloads

I think flatpak is probably the right choice for a phone. Assuming equal developer attention on both flatpak and deb repos, there's nothing inherently worse about flatpak. The nice thing about flatpak for a phone is that it could in the future offer something like the Android/iOS permissions interface.

Yeah, maybe I am a bit too negative about the format itself. My problem with the Flatpak only approach was that it was kinda hard to get it to run at all and it didn't work particularly well, so I ended up with putting some work into it while ending up with an unsolved problem (stable Linux desktop SIP client).

So maybe this is not an inherent problem of this technology and will work better in the future.

Re: Flatpak – a security nightmare

#205

Post by jwildeboer »

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.

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

And I think there is a strong correlation between those two things.

It definitely makes it impossible to enter in a productive discussion about how flatpak could work better. The way it stands now, this rant is useless, aimed to be destructive and simply unacceptable. IMHO.

Re: Flatpak – a security nightmare

#206

Post by linappdev »

niemeyer wrote: post #144
linappdev wrote: post #129

Earlier quoted context omitted.

> That's disingenuous. Canonical works with many parties, and has people working on LSM stacking for example precisely to support co-existence of the systems. I'm assuming with "LSM stacking" that you mean having both AppArmor and SELinux operate concurrently on a system, since you can currently have kernels that have both enabled, but only one at a time active. Are you going to convince Red Hat to enable AppArmor an…

> I'm assuming with "LSM stacking" that you mean The term "LSM stacking" is public. Search for it and you'll get good material. > Are you going to convince Red Hat to That's not how things work. Canonical and RedHat collaborate technically by improving parts of the system as necessary. Things are enabled or not based on market requirements. > What about helping to maintain AppArmor support in Fedora? Canonical alread…

> That's not how things work. Canonical and RedHat collaborate technically by improving parts of the system as necessary. Things are enabled or not based on market requirements.

Umm, but your ability to offer useful confinement literally hinges on this since you don't want to do anything else...

So, you'd have to do something to get Red Hat to consider enabling it. Otherwise you're stuck with nothing for Snappy on the most commonly used Linux distribution platform in the commercial space.

>> What about helping to maintain AppArmor support in Fedora? > Canonical already does that by working to upstream the patches. That helps Fedora and everybody else too.

It doesn't help Fedora at all today, since there is no AppArmor support in the distribution. The user-space tools aren't in there, and the kernels shipped by Fedora do not have AppArmor enabled. So, no, I can categorically say you are wrong there.

> Well, no need to guess.. there are open discussions about it.

Really? Because I searched, and outside of John Johansen's wishful thinking presentations, I've seen no evidence of anyone talking about it seriously. If anything, I've heard people say John is crazy for thinking that this is a reasonable idea.

Care to offer some proof to the contrary? Who knows, you might be right! It seems that the LSM mailing list has no functioning archive, so there could be something there that says otherwise.

> For legal reasons that are not unique to Canonical we do require a pretty straightforward CLA to be signed.

No other major Linux company requires one. Not Red Hat. Not SUSE.

Re: Flatpak – a security nightmare

#207

Post by zeroname »

pdonis wrote: post #150
zeroname wrote: post #132

Earlier quoted context omitted.

> My point is simply that I, as a user, am never going to use software that wants me to install it this way. I, as a developer, am not sure I care. It's tough for me to care about Linux in the first place (you guys are picky!), but let's say I went through the trouble of maintaining multiple third-party repositories for major distributions, how exactly is that more secure from your perspective? You still have to trus…

> 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, there's no reason to trust the competence of Canonical or RedHat employees (or even volunteers for other distros) over those of Apple or Microsoft. Either one can mess up, either one can expose your system.

> Also, even supposing downloading from your website is the only alternative you give me, to do that securely, you'll have to use HTTPS, you'll have to sign your binaries with a public key I trust, you'll have to provide signed hashes so I can verify the download, etc.--in other words, all the stuff you'd have to do if you maintained a third-party PPA.

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. That's the actual problem Flatpak is solving. If there was one package format that worked everywhere, it would be a different story. You can trivially download and install (compatible) deb or rpm files as well, why aren't you lamenting that being a security issue?

> And also again, if you don't supply a third-party PPA that my distro's package manager can pull updates from automatically, how are you going to ship me updates?

Your distribution could integrate Flatpak updates into its update mechanism, or you can run them manually or as a cron job.

> Or are you going to reinvent, poorly, the packaging and updating infrastructure that has already been field tested for years by distros?

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. On the other hand, the software that has all its dependencies in one place, where an update consists of overwriting or replacing the installation directory, has rarely failed. On Windows, this is called "portable", on Mac OS, this is simply a regular application.

Re: Flatpak – a security nightmare

#208

Post by Conan_Kudo »

v_lisivka wrote: post #196
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.

In Fedora, Rust applications don't have bundled dependencies, but since Rust doesn't provide a stable ABI, we statically link the libraries into the application for now.

Re: Flatpak – a security nightmare

#209

Post by zeroname »

alkonaut wrote: post #192
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 ther…

> Wouldn't it be better if the app only had permission to write to an actual user documents/data directory...

Well, would it? If the app went rogue, it could still encrypt all your documents.

Either way, dealing with that is not the job of package management or software installers. They can not solve the fundamental design issues of software that has been written without a finer permissions model in mind.

Re: Flatpak – a security nightmare

#210

Post by vanderZwan »

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…

I'm going to stay a on the meta-discussions level for a bit (all other points in this debate have already been made anyway). Hanlon's Razor is about assuming intent, about railroading others into perceived roles. You bring up interesting points, but they were not part of the article we are responding to. The conclusion was supposed to follow from the earlier arguments given. Within that context there is a big assumption being made.

So what am I being naive about, exactly? Note that I have merely called out the assumptions made by others. I have not stated anything about Red Hat's intentions myself, so if I'm being perceived as naive about that, it would be making another assumption. EDIT: I suppose the "mistake" wording does imply good faith behavior. But there too: bad faith should be looked out for, tested for, but not presumed about others.

Post reply on HN