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

131–140 of 264 posts

Re: Flatpak – a security nightmare

#131

Post by cyphar »

the_duke wrote: post #114
briffle wrote: post #17

Earlier quoted context omitted.

And many docker users run privileged containers, because then they don't need to troubleshoot permissions.. It doesn't meant the underlying system is flawed, because people take the lazy way around it. I'm thinking of all the blogs back a few years ago for setting up things on Centos. Step 1, disable SELinux.. That was never recommended, but the blog writers didn't want to go into details about how to manage selinux,…

I almost never had to run a privileged container, and I avoid it whenever possible. As far as I have seen, privileged container use is rare. What lead you to the assumption that it isn't?

It should also be noted that bind-mounting docker.sock is equivalent (or much worse -- it's easier to exploit at least) to using privileged containers, and an exceptionally large number of people do this (you see it in many blog posts and project installation scripts).

Re: Flatpak – a security nightmare

#132

Post by zeroname »

pdonis wrote: post #83
linuxftw wrote: post #72

Earlier quoted context omitted.

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

I agree there's a ton of software out there that wants you to install it this way, not just on Linux but on any OS. My point is simply that I, as a user, am never going to use software that wants me to install it this way. The extra work involved in setting up secure distribution is a feature, not a bug.

> 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 trust that I don't ship malicious binaries, just as if you just had downloaded the package from my website. Worse yet, you also trust that I maintain all these repositories securely, which means a bigger attack surface for you.

> The extra work involved in setting up secure distribution is a feature, not a bug.

Except it isn't really secure from a technical perspective, it's literally just more work.

Re: Flatpak – a security nightmare

#134

Post by Conan_Kudo »

niemeyer wrote: post #124
Conan_Kudo wrote: post #116

Earlier quoted context omitted.

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

I don't think that was ever true? Docs: https://docs.snapcraft.io/build-snaps/electron Example: snap info electron-quick-start

I thought the seccomp-in-seccomp thing would have messed things up...

Re: Flatpak – a security nightmare

#135

Post by wbond »

v8engine wrote: post #130
wbond wrote: post #106

> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode, Android Studio and Sublime Text still use unpatched git version 2.9.3. Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and no version of Sublime Text comes with git. After such inaccurate information, I can’t help but question the rest of the article.

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.

Re: Flatpak – a security nightmare

#136

Post by AnthonyMouse »

voltagex_ wrote: post #120
viraptor wrote: post #107

Earlier quoted context omitted.

It depends on your use case. If you sandbox tar (for example), you'd do it be removing all network access and a few fancy caps, but you'd leave the rw access to the whole system. (within its standard privileges) If you sandbox netcat, you'd do the opposite: remove all fs access (unless you care about pipes) and leave open networking. There's nothing about the idea of a sandbox that requires a specific approach.

Have a look at AppV on Windows. It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.

> It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.

Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM snapshots or a number of other things for a long time.

Re: Flatpak – a security nightmare

#137

Post by emmelaich »

By default, flatpaks don't have r/w to your home.

And setuid binaries have been blocked for a while (as the article says). Plus, selinux will have these things locked down on a system that uses selinux.

I think the problem is part perception. Flatpak, like Docker is not primarily for security isolation. It's isolation for ease of deployment - to avoid dependency hell.

Not saying Flatpak's failings are not a problem. Just keep some perspective.

Re: Flatpak – a security nightmare

#138

Post by cyphar »

linuxftw wrote: post #68
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-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 definitely far from perfect) but they do solve real problems and going to a Windows-DLL-dump method of packaging is going in reverse.

If your "package format" makes developers maintain all of their dependencies, it isn't solving the problem that most people actually want you to solve -- to be able to do less work and build on top of other people's work. By using dependencies maintained by your distribution you also get security updates and maintenance for free -- many distributions have paid security and maintenance teams that deal with precisely this. I cannot overstate how much work it is to maintain your own distribution.

[1]: https://www.youtube.com/watch?v=mkXseJLxFkY

Re: Flatpak – a security nightmare

#139

Post by megous »

What's cross-platform experience for packagers/builders? Seems like you can't do cross-compilation, so expecting upstream to provide flatpaks for users is expecting upstream to manage virtual or real machines for every [desired] CPU architecture with all the annoying host distro installation/management, networking stuff, etc.?

At least with the current model, upstream developers can offload most of that to distribution packagers.

Post reply on HN