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

161–170 of 296 posts

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

#161

Post by gspr »

linmob wrote: post #55
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…

Confirming these settings at first launch is something that mostly annoys users. Remember: Most users just install software via Flatpak because this way they don't have to compile it themselves, deal with a tarball or use an outdated release their distribution ships. Also, if you want to review or change these settings, you can use Flatseal[0]. Arguably, it should be installed by default. The problem with flatkill.or…

> or use an outdated release their distribution ships.

And a good chunk of those people often would be just fine with that "outdated" version.

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

#162

Post by viraptor »

Jouvence wrote: post #92
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.

Sandboxing is fine, but it sounds like Snaps/Flatpaks don't actually do it because that would be too hard - so what's the point? I get that some packages do actually have sandboxing, but unless it is mandatory and enforced I feel like I'm better off avoiding the ecosystem entirely and dealing with app isolation myself, using containers or VMs.

Snap/Flatpak are not doing it because that's not the layer which "does it". They provide the framework which allows since sandboxing today and will provide better sandboxing tomorrow. It's up to the app distributors to support it or not. We won't get full support immediately either.

It may be too hard today. But that's less "Flatpak is a security nightmare" and more "we're not using the features we have very well yet". I feel like some people expected 100% targeted profile for each app or will declare sandboxing a failure. This stuff will take years.

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

#163

Post by loloquwowndueo »

Daho0n wrote: post #134
loloquwowndueo wrote: post #120

Earlier quoted context omitted.

Escaping from annoying micromanagement pop-ups is a big part of why I use Linux. If this changes and it becomes as naggy as Windows I might have to move to Openbsd :)

Flatpak != linux. Different conversation.

You apparently didn’t read the parent: “ I'm sure the same model can be applied to Linux.” I was replying to that, so perhaps your reply belongs one level up. I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction. I already know of a few packages I depend on which are only officially packaged as snaps - I’ve had to find alternatives or look into compiling from source (not always feasible - I don’t have a ton of time to tinker anymore).

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

#164

Post by viraptor »

cl3misch wrote: post #45
orf wrote: post #31

Earlier quoted context omitted.

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 A…

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

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

#165

Post by GordonS »

syockit wrote: post #135
krick wrote: post #125

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, a…

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

In some ways, things are better there on Windows here, because of code signing - if something isn't code-signed, you get a more prominent warning. I often wish for something like this on Linux (and it would have to be easy to use - no compiling your own kernel with additional modules for example).

It's really not easy to get a code signing certificate fraudulently (or to steal someone else's), but of course, there are some issues with code signing: for example, certificates are relatively expensive, so very few OSS/free software projects sign binaries.

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

#166

Post by GordonS »

loloquwowndueo wrote: post #120
bayindirh wrote: post #103

Earlier quoted context omitted.

If macOS, iOS and Android can get away with one-time permission pop-ups when access is first needed, I'm sure the same model can be applied to Linux. The annoyance doesn't come from the security, it's from un-refined UX.

Escaping from annoying micromanagement pop-ups is a big part of why I use Linux. If this changes and it becomes as naggy as Windows I might have to move to Openbsd :)

To he fair to Windows, if you really want to, you can disable UAC prompts. Obviously that's generally a very bad idea, but it can be done.

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

#167

Post by bayindirh »

loloquwowndueo wrote: post #163
Daho0n wrote: post #134

Earlier quoted context omitted.

Flatpak != linux. Different conversation.

You apparently didn’t read the parent: “ I'm sure the same model can be applied to Linux.” I was replying to that, so perhaps your reply belongs one level up. I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction. I already know of a few packages I depend on which are only off…

> I read the parent as “all next-gen packaging formats should adopt this pattern” and envisioned a hell where said packages are the only way to get new software, if any of them gains enough traction.

Parent here. Whoa, you're reading too deep into that. How do you think that I envision such a future? Even I didn't know I've envisioned such a future.

If I had time to implement such an elaborate subsystem, I'd do it as a user-configurable kernel level interface. Like a more user-configurable, more flexible version of SELinux or AppArmor.

The first thing I'd implement would be a global on/off switch, too. I've seen and worked in enough projects where keeping it on was the only sensible choice, and I know enough that some people (incl. me in some scenarios) would like to keep it turned off.

For clarity, I neither support snaps, commercialization of Linux distributions to create commercial lock-ins, centralizing packages like Snap and dumbing down Linux. I already don't touch Chrome, Electron, VSCode and other pseudo opensource and pseudo free software and use some paid, cross-platform closed source software since they solve some real problems of mine, but I wouldn't dream of a Linux like you're creating by reading my simple comment.

Wow.

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

#168

Post by necovek »

scatters wrote: post #85
necovek wrote: post #48

Earlier quoted context omitted.

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 to…

A capability model fixes this: the application launches a file chooser which it does not control , which can then return it an fd or other token giving the application the capability to read from or write to a specific file. Of course, this would be a considerable effort. But it's probably where we're going.

Ideally, not even getting the FD, but access to the data only (decrypted in flight)?

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

#169

Post by necovek »

AshamedCaptain wrote: post #114
scatters wrote: post #85

Earlier quoted context omitted.

A capability model fixes this: the application launches a file chooser which it does not control , which can then return it an fd or other token giving the application the capability to read from or write to a specific file. Of course, this would be a considerable effort. But it's probably where we're going.

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.

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

#170

Post by Koliakis »

syockit wrote: post #135
krick wrote: post #125

I don't want to downplay the importance of the problem, but it seems to me, that unfortunately the correct addressing of security concerns is rather an exception, than the norm on Linux desktop. Of course half of the your "ordinary apps" need home write permissions, whether they are installed via flatpak/snap or not. And most semi-technical desktop Linux users have some sort of ~/bin with a bunch of random scripts, a…

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

I've been experimenting with Qubes and it's the only OS I'm aware of that adequately addresses this issue. It's not usable for non-technical users though without a lot of learning/training and it can be a bit tedious to use sometimes.

I have all my personal data in its own isolated VM (Qube). I do all my browsing in another VM, which has its own home folder and no access to my personal VM. All my sensitive stuff like banking is done in its own VM. Every proprietary application gets its own VM (mainly Teamviewer and VS Code).

So if I do happen to run some program that's malicious, it has effectively zero access to anything sensitive unless it's aware of Qubes and knows how to break out of the hypervisor (non-trivial).

Post reply on HN