Live data from Hacker News

Flatpak – a security nightmare

flatkill.org

51–60 of 264 posts

Re: Flatpak – a security nightmare

#51
post #19
post #7

Earlier quoted context omitted.

Domains are cheap. Often free for one year.

Well they’re “free” if you buy them alongside hosting. Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc...

> that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it

Sounds fast to me if you know how. Just write the article (markdown + pandoc is fast) and...

With Zeit you can just type `now` and `now alias (url) mydomain.xyz` - and the website is up and running at your domain for $domain_price + 0.10USD/GB.

With DigitalOcean/Vultr/Some VPS Provider + Ansible you can do something similar.

Re: Flatpak – a security nightmare

#52
The sandbox is in a sense working, the problem is that the folder the app accesses is more critical than what the user thought. We should make sure nothing in home will get executed : no bashrc, no scripts, no executable. In the "ideal" world you would never download & run any script or any executable (like on Android or IOS). Everything the user should be able to do is install or run flatpak apps.

(Of course in practice as soon as you are programming a bit you'll want to open a terminal, run scripts and do stuff outside flatpak)

For the second point, well it's just that update are not frequent enough ? This has nothing to do with flatpak technology right ?

Re: Flatpak – a security nightmare

#53
post #35

Earlier quoted context omitted.

This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. In other words, Linux is secure because nobody can ship software on it without going through massive hurdles and because everybody who is smart enough to install software on Linux does some diligence.

> This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. True, it isn't any less broken than that; it's more broken. First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downlo…

> First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user...

There are no "average" Linux users. There's only Linux nerds and people who have had their Linux nerd friends install and maintain Linux for them. The whole "problem" is made up.

> Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.)

2525 Year of the Linux Desktop

> Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure".

I haven't seen Flatpak touted to have a security sandbox, nowhere on their site do I see "security" being even mentioned as a feature. So that accusation is made up as far as I am concerned.

> Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.)

Gee, a thousand FOSS applications, what more could a user want? Have you personally ever tried to ship software for "Linux"? Do you even develop software?

> So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security.

It's "security by inconvenience". This has nothing to do with real security. These users you are trying to protect don't exist, but even if they did, you wouldn't protect them by making it hard for them to install software, you would be making them use Windows instead.

Re: Flatpak – a security nightmare

#54
post #17
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,…

You're right! It's not the fault of the underlying system, it's the fault of the lazy people who work around it trivially.

With that said, some people might consider a system that is much easier to trivially work around than to use properly is one possessed of a wonderful, glorious, bountiful collection of opportunities to improve its design. Such systems are not bad! Not by any means! They just could, perhaps, be somewhat better.

All of that said, I do think a sandbox-based system probably shouldn't allow things inside the sandbox to say "Don't sandbox me bro". That seems less than maximally wise, even if it does also seem super convenient.

Re: Flatpak – a security nightmare

#55

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…

But Flathub is flatpak. Also, does flatpak have the full support of redhat?

Re: Flatpak – a security nightmare

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

Re: Flatpak – a security nightmare

#58
post #33
post #9

Earlier quoted context omitted.

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…

Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview here: https://github.com/projectatomic/bubblewrap/blob/master/READ... There is nothing against Flatpak using user namepsaces when the developers feel a bit more comfortable with that, though.

Are you one of the developers/speaking for them? That warning is pretty old.

Re: Flatpak – a security nightmare

#59
post #39

To be honest, this security nightmare also covers other contemporary "container" formats such as docker. Running docker containers as a non-root user is unfortunately still not a widespread practice. That means that any root process within a docker container has root on the host.

Only if you run with no isolation / user namespace. And even without that, you need to run with `--privileged` to get access to interesting capabilities. It's not as simple as container root == host root.

Re: Flatpak – a security nightmare

#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 what they used to. They've just been ported to flatpak as thin wrappers. If you get the dropbox flatpak, it will continue to litter your home directory with hidden files.
Post reply on HN