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

111–120 of 264 posts

Re: Flatpak – a security nightmare

#111

Post by niemeyer »

Conan_Kudo wrote: post #99
linappdev wrote: post #93

Earlier quoted context omitted.

With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers. So, for example, on Fedora, Debian, CentOS, or…

> There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too). Snappy packager for Fedora here! :) Yes, it's true there's an SELinux policy that confines snapd, but it does do some limited enforcement of limitations on snaps, too. It's just…

> 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 announced in the open.

Re: Flatpak – a security nightmare

#112

Post by bubblethink »

nickysielicki wrote: post #48

1. None of this has anything to do with Flatpak, it has everything to do with Flathub and how particular software is packaged. 2. Your preferred distribution can host their own Flatpak repository and ensure that things like security updates get dealt with properly. Flatpak is not Flathub. 3. This ecosystem is growing, so it's putting some things on the backburner, prioritizing application availability over holding a…

>There is no reason that these issues can't be ironed out going forward.

That's true in principle, but selinux still doesn't see that much adoption outside of the distro configured policies for typical server usecases. A lot of desktop apps run unconfined. So I think this is where openbsd's approach to stuff like this is more practical. They iterate and wait before rolling out features like pledge or unveil so that they know that 1) It can be made to work with at least 50 apps (read this is one of their slide decks) 2) They can tackle a complex enough application like chromium. Flatpak, selinux or any of the other security mechanisms are completely ineffective if users or developers are largely ignoring them.

Re: Flatpak – a security nightmare

#113

Post by p2t2p »

Trust me, nobody cares. The regular user doesn't go past "I can install Spotify in one click". It always were like that and it always will be like that. With more "normies" coming to Linux there will be more stuff like that. That is exactly why people were saying that there are no viruses on Linux only thanks to lower popularity.

And with all honesty - how many of us read script files when installing something from AUR?

But hey, nobody forces you to use it! You can always choose you distro repo or go DIY way.

Re: Flatpak – a security nightmare

#114

Post by the_duke »

briffle wrote: post #17
Kalium wrote: post #8

Earlier quoted context omitted.

As I understand it, from reading this page it doesn't actually matter much how secure the sandbox is as many applications effectively disable it.

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?

Re: Flatpak – a security nightmare

#115

Post by bubblethink »

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!

Yes, that's kind of true. You can get newer versions of things slightly easier. It can be major point if your distro is getting quite old (like RHEL or even xenial), but if you keep up with a 2 year cycle of distro updates like ubuntu LTS, you rarely hit that scenario.

Re: Flatpak – a security nightmare

#116

Post by Conan_Kudo »

niemeyer wrote: post #111
Conan_Kudo wrote: post #99

Earlier quoted context omitted.

> There is an SELinux policy that attempts to confine snapd itself, which was contributed by the guy working on the Fedora/CentOS package for snapd (though it looks like the policy would also work for openSUSE and Debian SELinux setups, too). Snappy packager for Fedora here! :) Yes, it's true there's an SELinux policy that confines snapd, but it does do some limited enforcement of limitations on snaps, too. It's just…

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

Re: Flatpak – a security nightmare

#117

Post by cyphar »

lvh wrote: post #9
glglwty wrote: post #4

Is the sandboxing of flatpak more or less secure than docker?

They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are wors…

> docker uses user namespaces

Docker has support for user namespaces but it's off by default, and I've never actually seen someone use them (I'm sure people do, but the way the support was implemented is fairly half-baked in a variety of ways, for a variety of understandable but still disappointing reasons).

LXC/LXD's user namespace implementation actually privilege-separates different containers from each other (while also being able to "punch out" parts of the mapping so that you can share stuff between containers without needing to share the entire uid_map).

> user namespaces requiring privileges to use

Not always. See https://github.com/rootlesscontainers (a project I work on -- currently you can run Kubernetes as an unprivileged user with some caveats about multi-node setups but we're working on it) or LXC's unprivileged containers.

And in cases where you need to have multi-user mappings (which isn't necessary for most user applications because they wouldn't be able to setuid anyway!) you can just use "newuidmap" and "newgidmap".

In fact, bubblewrap has supported precisely this usecase and the use of user namespaces for a while. Of course, user namespaces wouldn't really help with protecting against home directory attacks -- if you're running as the same user (but in a user namespace) and you bind-mount the home directory then it can obviously write to said home directory.

Re: Flatpak – a security nightmare

#118

Post by michaelmrose »

yzmtf2008 wrote: post #98
viraptor wrote: post #92

Earlier quoted context omitted.

The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided. It's like standard Linux permissions. If you install an ap…

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion.

In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed.

In a flatpak not designed to be properly sandboxed you are in fact no worse off than the alternative deb/rpm situation save that the issue of packing for distribution has been made easier.

It's in fact probably extremely challenging to package all sorts of applications without giving the user the option to provide an individual app elevated permissions.

At best we are relying on the user to decide which app ought to get those permissions.

If you think people can't be trusted to do this then the logical solution is to rely on packagers to decide what belongs in the official repo and keep malicious content out.

Re: Flatpak – a security nightmare

#119

Post by androidgirl »

bubblethink wrote: post #115
androidgirl wrote: post #110

Earlier quoted context omitted.

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!

Yes, that's kind of true. You can get newer versions of things slightly easier. It can be major point if your distro is getting quite old (like RHEL or even xenial), but if you keep up with a 2 year cycle of distro updates like ubuntu LTS, you rarely hit that scenario.

That's definitely true! It's also good for smaller distros with smaller package managers. It's easier for a dev team to support just Flatpak than to bundle/petition for pacman, apt, yum, eopkg, and so on.

I'd greatly prefer 'native' packages though.

Re: Flatpak – a security nightmare

#120

Post by voltagex_ »

viraptor wrote: post #107
yzmtf2008 wrote: post #98

Earlier quoted context omitted.

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

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.
Post reply on HN