Flatpak – a security nightmare – 2 years later (2020) • Hacker News Board

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

#171

Post by lambda_obrien » Sun, Mar 21, 2021, 1:36 PM UTC

foobar33333 wrote: post #29

dastx wrote: post #24

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when promp…

I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it. The current strategy seems to be having outsiders packaging all the desktop software in t…

Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.

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

#172

Post by gbrown » Sun, Mar 21, 2021, 1:40 PM UTC

tored wrote: post #110

foobar33333 wrote: post #54

Earlier quoted context omitted.

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…

Gnome Software is pretty much unusable for installing software. I use it to find software and read reviews, but never install. I always use the terminal for that. 1. Gnome Software does not tell what the package name is for deb, flatpaks, snaps etc 2. Gnome Software does not say what type of package it is (deb, flatpak, snap etc) except when it’s multiple choice. 3. No overview of dependencies. 4. No information what…

It also just seems sooooo slow. I also drop to the terminal for these tasks 100% of the time - including search. I’ll Google for software, and then dnf search to find the specific package if it’s offered.

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

#173

Post by zajio1am » Sun, Mar 21, 2021, 1:45 PM UTC

Hot take: Per-application sandboxing is (in general) fundamentally flawed idea, as applications are just tools to manipulate data, while data needs to be protected from unintended manipulations, but such protection should not encumber intended manipulations. What manipulation is intended depends on worflow, not application. Such setup can work on phones due to their limited use cases, but not on desktop.

What we need are tools for per-workflow sandboxing. Assign each data to worflow/project (with separate uid), and then execute applications as a part of the project. So applications would have access to data of the project in which they are executed.

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

#174

Post by hnedeotes » Sun, Mar 21, 2021, 1:48 PM UTC

eeZah7Ux wrote: post #68

hnedeotes wrote: post #14

Earlier quoted context omitted.

Why can't they be complementary?

Because distributions don't need flatpak. There are already methods to do sandboxing like systemd and firejail.

Ah sure, I was referring to the:

> Passing responsibility of not distributing evil software from the gatekeepers to the user.

As in, we can have gatekeepers but also force software to define explicit access policies. Like, maybe a program that needs regularly files will create a folder where they have access to files and any files placed there afterwards can be used by the program without asking for access. For all other files/folders it would ask for specific access, and the access could be given as session based or normal and apply to the selected files only?

Having a default folder (per application) could then be used by programs like word processors or wtv to have a place to save automatically so the ux doesn't suffer in the basic case. Saving files outside authorised folders would not need permission unless they were overwriting a file that wasn't permitted previously, but access to other things in a non permitted folder would require permission still?

This could live with existing package managers curation and sandboxing, but even if the programs somehow got into a compromised state they would be limited?

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

#175

Post by TheMagicHorsey » Sun, Mar 21, 2021, 1:49 PM UTC

It seems like some of OP's criticisms of Flatpak are not actually criticisms of Flatpak, but rather criticisms of the way Linux works.

Perhaps OP would be happier with a capabilities-based operating system (like Google's new Fuschia system).

It just seems like these complaints leveled against Flatpak are asking the authors to achieve nearly impossible goals given the complexity of doing sandboxing at the app level in Linux.

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

#176

Post by Blikkentrekker » Sun, Mar 21, 2021, 1:59 PM UTC

dastx wrote: post #24

One thing I've not understood about flatpak (or their competition for that matter) is why don't these permissions get prompted when they're used? Similar to iOS and Android, ping the user and confirm whether or not they want to give the application this permission. Perhaps even allow for customising the permissions (e.g. when it asks for permission to the homedir, you can override what the homedir would be when promp…

Because the system can't be intelligent enough for that.

Say the process wish to write to a particular file; — how far up the directory tree does the system ask for permission?; only that specific path? the home directory?; how can the system know this?

Of course, the other issue is that, say the system be implemented so that the write call blocks until the permission be given, that they will timeout with an error because they have limits on write calls that take that long, and assume there is something else that is wrong like mechanical storage failure, if a simple write call truly take seconds.

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

#177

Post by uneekname » Sun, Mar 21, 2021, 1:59 PM UTC

tored wrote: post #110

foobar33333 wrote: post #54

Earlier quoted context omitted.

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…

Gnome Software is pretty much unusable for installing software. I use it to find software and read reviews, but never install. I always use the terminal for that. 1. Gnome Software does not tell what the package name is for deb, flatpaks, snaps etc 2. Gnome Software does not say what type of package it is (deb, flatpak, snap etc) except when it’s multiple choice. 3. No overview of dependencies. 4. No information what…

When I install something using dnf for example it installs near-instantaneously! Makes me wonder wtf Gnome Software does in the background to make installs so slow :P

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

#178

Post by Spivak » Sun, Mar 21, 2021, 2:03 PM UTC

necovek wrote: post #169

AshamedCaptain wrote: post #114

Earlier quoted context omitted.

Flatpak already does this. It is called portal. The grandparent post is wrong. The problem is what haplens when the program does not use standard file choosers, file APIs, etc.

Flatpak in theory vs flatpak in practice are different things, as you highlight yourself ("...does not use standard file choosers, file APIs, etc."). Suddenly, it's now on app developer to support the packaging system and not the other way around.

I mean what do you want to have happen? ptrace every application, stop on every openAt(2) call and pop up a permissions dialog?

macOS can get away with solutions like this because they control the kernel and userspace but on Linux it’s a much tougher problem.

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

#179

Post by fnord123 » Sun, Mar 21, 2021, 2:06 PM UTC

XorNot wrote: post #127

varispeed wrote: post #123

Earlier quoted context omitted.

In my view these queries about permissions are a bit meaningless. If an app asks me if I want to give it access to my Photos I feel uneasy about that. Which photos? For what? What is it going to do with it? I think the filesystem should be sandboxed and if an app wants to read something I should be able to e.g. give it a directory where it can do anything or I should be able to select a file and the app will have a p…

This is where we need to require better programming languages. What we need to be able to prove from code is that when an application is asking for a particular permission, the code paths the data will be used for can be shown not to result in network transmission without going through a trusted transform (if we want to allow it) - i.e. that only SHA512 transforms of that data can end up on the network without gating…

Pretty sure this is not possible from a code inspection point of view through Rice's Theorem.

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

#180

Post by Blikkentrekker » Sun, Mar 21, 2021, 2:06 PM UTC

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 disagree that the “sandboxed” icon is misleading, because it does limit some things, even though we as per issue one agree that access to the full home directory gives malware carte blanche.

- We agree on the point that the outdated example library with a vulnerability used is true as stated.

- We agree with the issue, but we have a tool built that mitigates it by altering developers.

I hardly would say that this rebuttal amounts to showing “f.u.d.”; — it alleges no technical falsehood in the article, but at some points simply disagrees that it is as much of a problem as the article claims it is, not numerically in terms of facts, but simply disagreeing on whether full write access to the home directory is truly such a big issue as the original article makes it out to be.