Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak – a security nightmare – 2 years later (2020)

flatkill.org

Post reply on HN
Print view View original

271–280 of 296 posts

Re: Flatpak – a security nightmare – 2 years later (2020)

#271

Post by benibela »

ohazi wrote: post #236
benibela wrote: post #157

Earlier quoted context omitted.

I have run the browser on a separate user account for years

I don't understand why this isn't more popular. This has been the sandboxing method or choice since the 70s. Filesystem permissions were designed around users and groups, and now everybody's trying to bolt on intra-user access control lists and wondering why the experience sucks so much. Create a `browser` user. Add yourself to the `browser` group. Maybe give `browser` read access to an area in your docs folder for c…

I have a few problems.

In the default settings other users could not access the X server. I forgot how that is changed. I changed it once and now just copy the config

Biggest is getting the sound to work. Pulseaudio in system mode should do it. Although it is not recommended to use. And now my headphones do not work reliable anymore. Not sure if it is caused by system mode or by another setting.

And sharing files. Good that the browser cannot change my files, but it works both ways. My normal user cannot change the browser files, sometimes not even access the downloads.

Re: Flatpak – a security nightmare – 2 years later (2020)

#272

Post by antimba »

Blikkentrekker wrote: post #180
mands wrote: post #7

Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.

I find your takeway that it is f.u.d. from this response quaint. To sum up the issues: - We agree that write access to the entire home directory compromises any and all security, but we are aware of the problem and trying to fix it. - We checked the claim of “Many of the popular flatpack applications still have access to the entire home directory,” and conclude that 23 of the 50 most popular ones do. - We partially d…

There are several technical falsehoods on https://flatkill.org/2020/. For example, this one:

> Almost all popular apps on Flathub still come with filesystem=host or filesystem=home permissions

TheEvilSkeleton counts them and 23 out of 50 is not almost all, so that is a technical falsehood, albeit not one that invalidates the author’s point. There are other falsehoods that do invalidate the author’s points. This one, for example:

> Two years is not enough to add a warning that an application is not sandboxed if it comes with dangerous permissions (like full access to your home directory)?

This is wrong because GNOME Software did, before the flatkill author’s 2020 update, add a warning (which is missing from the author’s screenshot) indicating that the app has high permissions and can access all files and folders (it’s still described as sandboxed, which technically it is, just with the ability to escape the sandbox; further changes to GNOME Software to make this clearer are already planned). The author’s screenshot was presumably taken using an outdated version of GNOME Software; they should have checked more recent versions before making claims about what features developers did or did not add.

And here’s another falsehood:

> So I need to run multiple fcitx daemons on my desktop and switch between them as I switch flatpak apps depending on which fcitx libraries are bundled with that app

The flatkill author misunderstood the implications of the bug report (in addition to seemingly misunderstanding where fcitx comes from; it’s part of the runtimes, rather than being bundled with each app). The issue was caused by a change in Flatpak, fixed in fcitx, and there is no need for the fcitx versions to match going forward.

Re: Flatpak – a security nightmare – 2 years later (2020)

#273

Post by [deleted] »

ben509 wrote: post #201
viraptor wrote: post #164

Earlier quoted context omitted.

> Desktop users want the newest version of their UI apps and don't care so much about stability. [Citation needed]. Can you imagine telling this to someone who is about to present on a conference call, but zoom updated automatically and fails to start now?

If you define "care" as in, "random updates cause enough instability that they make alternate OS's favorable for accomplishing the same tasks," I'd cite Windows autoupdate as fairly hard evidence that people don't care. I imagine MS has crunched the numbers at some point, and decided that the amount of lost work and interruptions due to forcible updates (especially contrasted with the benefits of updates) is not caus…

[deleted]

Re: Flatpak – a security nightmare – 2 years later (2020)

#274

Post by Shadonototro »

Jonnax wrote: post #153
Shadonototro wrote: post #115

it doesn't matter what people think both snap/flap user experience is trash linux desktop is doomed to fail people the people who make decisions are clueless and tasteless

What's your idea that would save Linux desktop?

less fragmentation, i think Unity 8 could have been the answer, sadly it died way to early..

Re: Flatpak – a security nightmare – 2 years later (2020)

#275

Post by antimba »

GekkePrutser wrote: post #212

From the article: > The flatpak runtimes and apps do not get security updates This is exactly what I worry about with things like Flatpak and Snaps (Ubuntu). Instead of having the distro maintainer provide timely security updates, all they have to do now is shrug and point at the external package maintainer. So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer…

> So now instead of simply backporting a patch to the distibution's openssl library, every single app maintainer of each app that uses it has to do this and provide an update.

That’s false. OpenSSL is part of the runtime[1] and only needs to be updated there.

[1]: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/ma...

Re: Flatpak – a security nightmare – 2 years later (2020)

#276

Post by antimba »

mrweasel wrote: post #78

Security updates are a huge issue for most “container” formats. Even official image on Docker Hub receive almost zero security updates and most companies seem to have no policy on how to keep container, be it Flatpak, Docker or even LXC containers updated.

> Even official image on Docker Hub receive almost zero security updates

Are you talking about the Official Images program? Because if so, this is not true.

Re: Flatpak – a security nightmare – 2 years later (2020)

#277

Post by antimba »

smoldesu wrote: post #237

If Flatpak security is this much of a joke, why do people go through the trouble of using it? Flatpaks are outright cumbersome, and bar-none my least favorite way to install anything. Have a local GTK/Qt theme/colorscheme? Gotta manually patch it in. Have a small main drive? You can store maybe three or four Flatpak'd apps. Slow internet connection? Good luck, you'll be here a while. All of it boils down into the out…

> Have a small main drive? You can store maybe three or four Flatpak'd apps.

That’s not true. Even the smallest consumer hard drives are big enough to store as many apps as you will want to install.

> Slow internet connection? Good luck, you'll be here a while.

Flatpak uses OSTree to install and update apps. It is very efficient and generally faster than traditional package managers.

Re: Flatpak – a security nightmare – 2 years later (2020)

#278

Post by antimba »

foobar33333 wrote: post #54
Iolaum wrote: post #37

Earlier quoted context omitted.

> This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.

If the package has host fs access, the sandbox is essentially turned off. A few packages have this because they just don't work without it. The thing is, clickbait bloggers go nuts over this but the state is not any worse than if you had used a .deb The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to liter…

> The only real problem is that the Gnome Software program lists these programs with a green "Sandboxed" badge when the app may have anywhere from full sandboxing, to literally no sandboxing.

The current mockups[1] for a UI refresh of GNOME Software have the “Sandboxed” badge and the permission details replaced by a context tile giving an overall “Safe”, “Potentially Unsafe”, or “Unsafe” rating, with additional indications and a safety dialog giving the full information. The ratings are determined from the permissions as well as license, whether the runtime is no longer supported, and whether the source is known.

[1]: https://gitlab.gnome.org/Teams/Design/software-mockups/-/raw...

Re: Flatpak – a security nightmare – 2 years later (2020)

#279

Post by antimba »

kaba0 wrote: post #182
xvector wrote: post #84

Earlier quoted context omitted.

What is Nix and why is it a better alternative?

Basically, nix (and guix, which is based on it) is the only package manager that actually solves the dependency hell problem properly. It makes builds reproducible, and basically a package will depend on it’s inputs’ hashes. So you can not only install multiple versions of the same package that is solved by some package managers although in hacky ways, you can install multiple ones that only differ in eg which libc v…

Nix doesn’t guarantee binary reproducibility. It does help with reproducing build inputs and the build process, as do the tools used to create Flatpak applications and runtimes—flatpak-builder and BuildStream. Nix can build packages in a sandbox, but the same is true of flatpak-builder and BuildStream.

The Freedesktop SDK has a CI pipeline (run on schedule, not on every change, because it is expensive) that tests reproducibility, similar to r13y.com. Currently everything is reproducible except a few components.

There are also many respects in which Flatpak is objectively better than Nix (other than sandboxing, which is an important one). For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot (`nixos-rebuild boot`); `nixos-rebuild switch` can still break your running system, though the Nix store is safe and problems will not persist after a reboot, which is still a huge improvement over traditional package management. Still, using containers allows giving stronger guarantees.

Another example is that flatpak-builder and BuildStream are substantially faster than Nix. Evaluating Nix expressions is quite inefficient, even if they are convenient to write. Worse is the cascading rebuilds that come with the Nix approach when dependencies like compilers and glibc are patched or updated. Rebuilding after significant updates to gcc and glibc has advantages, such as benefitting from newer compiler features, but it is very desirable to have the option not to do that.

Also, Nix’s languages lacks domain abstractions for building packages, which makes tools to generate and update derivations have to rely on assumptions about their format or be unnecessarily complex. In comparison, flatpak-builder and BuildStream use JSON and YAML. The result is less expressive but more convenient, consistent, efficient, and simple to manipulate.

Similar to nixpkgs-update, Freedesktop SDK uses a simple auto-updater[1] for BuildStream and Flathub apps can use the Flatpak External Data Checker[2] for a bot to open merge requests or pull requests to update dependencies in the runtime and in application manifests.

OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free. Nix gets deduplication only with an expensive process (`nix store optimise`) that involves scanning the Nix store and replacing duplicated files by hard links.

Yet another advantage of Flatpak is that due to dependencies being “flat”—that is, apps can depend on runtimes and have extensions, but there are no complex dependency trees—there is no need for dependency resolution. This also reduces the amount of metadata that needs to be downloaded. This makes installing and updating software with Flatpak very fast, which is unfortunately not at all true with Nix.

So, there are tradeoffs, and overall Flatpak has the better of them. Employing Nix to manage dependencies or to build apps would cause Flatpak to lose many of its advantages.

[1]: https://gitlab.com/BuildStream/infrastructure/gitlab-merge-r...

[2]: https://github.com/flathub/flatpak-external-data-checker

Re: Flatpak – a security nightmare – 2 years later (2020)

#280

Post by higerordermap »

kabdib wrote: post #226
higerordermap wrote: post #71

Earlier quoted context omitted.

The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.

I dislike sandboxes that - have complicated permissions that users misunderstand or can be tricked into misconfiguring through inattention, misleading user interface or fatigue - aren't actually sandboxes because the isolation they claim isn't actually achieved (I usually call these "security holes") - are used to artificially force markets (e.g., Microsoft's UWP) Other than that, they're great. Signed, cranky, pre-m…

I think this is a valid criticism from flatpak / snap. But they are step in right direction about sandboxing (on the other hand bloat and developer trust are main problems abou these platforms for me).
Post reply on HN