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

41–50 of 296 posts

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

#41

Post by lokedhs »

diffeomorphism wrote: post #26
oblio wrote: post #13

Earlier quoted context omitted.

So the solution is to have the package manager decide things for every user?

Yes, the point is to have the package manager set sane defaults for every user. Say you distribute a video app. It is completely counterproductive to have every user click on a permission dialog "I allow this video app to open videos". This only trains users to blindly allow everything to make software, you know, work at all. A much more sane approach would be to enable access to ~/videos and other reasonable places…

Flatpak allows this, but requires changers to the application so that it calls the correct API's when requesting files outside of the allowed directories.

The article does highlight some actual issues, but the author implies that the solution is to simply not use it at all and go back to the free for all smörgåsbord of access rights that an application installed from the regular repositories have.

Personally, I consider Flatpak the best solution available right now time minimise the attack surface for anyone not willing yo go all the way and run Qubes OS. If there is a better alternative I'd be happy to hear it, since I cannot run Qubes one of my machines.

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

#42

Post by alpaca128 »

kelnos wrote: post #16
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 don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying.

I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to copy any file I want to send into either ~/Downloads or ~/Pictures. Not a single other path is visible or accessible, if I click on "Desktop" in the list of favorites nothing happens. This is confusing and annoying for me, this would be super confusing for a user who doesn't know and care about file permissions.

I like flatpak as it can nicely fill gaps in official repositories whitout being bound to a single distro family once again. But honestly I understand why apps would just go "allow all", because anything else drives the user insane the way it is implemented now.

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

#43

Post by Ar-Curunir »

gspr wrote: post #28
kelnos wrote: post #16

Earlier quoted context omitted.

I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.

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

#44

Post by PhilippGille »

littlestymaar wrote: post #6
ampdepolymerase wrote: post #2

What is the security story for Snap and AppImage?

AppImage is a convenience layer which doesn't claim to add any security as it provides no sandboxing whatsoever. And the outdated dependencies in images are likely to exist in the AppImage world too.

The AppImage website mentions Firejail as a way to sandbox apps.

https://firejail.wordpress.com/documentation-2/appimage-supp...

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

#45

Post by cl3misch »

orf wrote: post #31
gspr wrote: post #28

Earlier quoted context omitted.

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The “classical Linux disto” got us into this mess, so I doubt it.

No, I think what got us into this mess is Ubuntu being a server distro with a standard release cycle (as opposed to rolling release) getting incredibly popular on desktops.

Desktop users want the newest version of their UI apps and don't care so much about stability. Ideally, the developers of e.g. Inkscape would offer the newest version on each Ubuntu version via apt, but that does not seem to be feasible.

I am no Arch user myself, but I think a rolling release is much more suitable for desktop use. I don't have the feeling most people use Snap/Flatpack for their sandbox, but much rather for getting a new version of some software.

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

#46

Post by mands »

ekianjo wrote: post #12
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.

note that the response partially agrees with the points raised, it looks like a constructive discussion overall.

Agreed, as far as constructive discussion can be had with a post from a domain called flatkill.org :)

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

#48

Post by necovek »

kelnos wrote: post #16
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 don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…

Snap and flatpak: they suffer from identical problems (in the snap world, these are "classic" snaps which get almost no restrictions).

Any app that needs to save files in your home directory, which all the traditional apps do (Gimp, Inkscape, *Office...), has to have r/w access to your home directory (duh).

So I would venture to say that this is all misleading marketing, which is mostly what the OP complains about too.

It all boils down to the same discussion we had 20 years ago: Linux proponents talked about how much better it was when it comes to viruses because only your $HOME would be affected, somehow missing to realize that in mostly single user desktops, that was the only thing anyone really cared about.

(I've exclusively used GNU/Linux systems since 1999, but not for made-up reasons like that :))

Flatpak/snap model is the one where app controls your data (which allows them to only need access to a certain subdirectory of $HOME—think Steam or Spotify), instead of allowing you to group files related by topic instead.

And that's exactly the model I don't subscribe to :)

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

#49

Post by [deleted] »

orf wrote: post #31
gspr wrote: post #28

Earlier quoted context omitted.

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The “classical Linux disto” got us into this mess, so I doubt it.

[deleted]

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

#50

Post by harporoeder »

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…

There is a mechanism for this called portals (1) available in flatpak. It gets integrated into the GUI toolkit, and certain applications are not supported. It is useful for things like accessing files from outside the default sandbox.

1. https://docs.flatpak.org/en/latest/portal-api-reference.html

Post reply on HN