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

141–150 of 296 posts

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

#141

Post by my123 »

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?

For Windows, there are the Win32 apps that you talk about, which aren't sandboxed.

And there are the modern applications from the Microsoft Store or self-distributed as msix/appx which are properly sandboxed.

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

#142

Post by pdimitar »

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?

People have praised Qubes OS for its security in the past but I've never tried it.

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

#143

Post by Zevis »

varispeed wrote: post #123
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…

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…

If it's anything like on Android, where you just give it blank permission to access your entire storage, it would be useless. There are plenty of programs you might want to use that have no business having access to everything, that you can't or don't want to trust 100%, but it's easier for the developers just to ask for everything (or it's the only option).

The "ask for permission" model is broken.

Everything should be sandboxed without giving the application awareness of being sandboxed. If you want to give additional access to a program, it should be through an external interface only accessible to the user.

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

#145

Post by Closi »

HenryBemis wrote: post #121
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…

Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work.…

> People hardly understand Applications. You want to ask them if they can write on X folder? On the OS? Good luck!

Well this is how it works in OSX (“Would you like to grant this application permissions to this folder?”), so I guess the answer is “yes - that’s exactly what Apple do”.

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

#146

Post by pdimitar »

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…

IMO we need a new runtime OS/system library for it. People have commented here that LD_PRELOAD wouldn't work so I suppose we need a software with which you can force a program to only see the libc.so you want it to see -- as a start.

Bringing in a new programming language might be valuable for it in the future but at least off the top of my head I can't see why can't this model be adapted relatively easily in most languages today.

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

#147

Post by megous »

HenryBemis wrote: post #121
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…

Simplistic response: Apple & Google (A&G) don't want people concerned with what's going on under the hood. It is difficult to explain. Also, imagine that you download something, you pay for it, then it asks a question you do not understand (rights 666 or 777? - what the hell? I don't want the devil on my phone!! NO to 666, Yes to 777)(maybe I will win in the casino). And assumming you 'Deny' and the app doesn't work.…

Reminds me of some bizarro Android permission issues, when I wanted to install a TLS client certificate (pfx) file. I downloaded it via web browser to a phone, opened the certificate management app, and the file was grayed out, no explanation, nada. No way to click on it, no error messages, no confusing permission flags in the file list. I thought the format of the file was wrong, so I tried regenerating it a few times in different formats, wasting an hour or two.

Turns out, you have to copy the file to some folder via adb command line, to make it usable by Android. Copying directly to a uSD card would have probably worked too, but how many people just have a uSD card reader lying around.

But I didn't get a confusing security prompt when downloading from a https:// url, that I might not have understood, so I was better off I guess. /s

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

#148

Post by oxylibrium »

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'm not too sure about "falling behind Windows", personally. The major lines of defense that Windows appears to rely on are code signing and a signature database, with behavioral AV being a relatively recent creation that still doesn't cover a lot of big holes. (for instance: What if I manage to fake my way through an OV/EV cert or use a leaked one? What if I use polymorphic code obfuscation that can generate hundreds of different signatures, but is also used by "legitimate" programs as DRM?) There's SafeSearch, but many people just click past those warnings anyway.

It's just as easy for a Windows .exe to create a service that runs when you log in as it is for a Linux app to write something to .bashrc - so its not a uniquely Linux problem.

macOS has the big Apple hammer to force developers to comply - Apple has the power to say "from this release on, all permissions need to be requested for or they won't work". Comparing the two companies, Apple uses the big hammer they have to force some compliance from app devs, while Microsoft often tries not to break stuff.

Linux doesn't have a big, central hammer like Apple does, so progress like Flatpak's isolation has to happen in steps, or else you end up in this chicken and egg problem:

- App devs won't support Flatpak with stuff like using portals because Flatpak has a small userbase - Users won't use Flatpak because it doesn't have apps that they want, and will instead go about doing things the old way

This "we'll give them $HOME for now and let them fix it eventually" is deliberate - you need to drive adoption for Flatpak before apps consider adding special code paths for it. The goal is to eventually fade out $HOME access or severely restrict it, but unfortunately this is the norm.

I've mentioned this on other posts, but this is deliberately why Flatpak's messaging on their website[0] is focused on ease of distribution instead of security. In addition, if you feel like you can put up with an app having a restricted view of the filesystem (for example, you don't think you'll touch anything outside ~/Documents/Models with Blender), you can adjust the sandbox to fit your needs.

[0]: https://flatpak.org/

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

#149

Post by microtonal »

hkt wrote: post #113
microtonal wrote: post #101

Earlier quoted context omitted.

which is to say, trusted sources over technical solutions This does not solve the problem where your a PDF reader from a trusted repository happens to have a zero day exploit. When it is exploited, the attacker could have access to all your files, since there are no further limitations unless you bubblewrap or firejail the application yourself. Since sandboxing is one of the goals of Flatpak, the exploit would be lim…

It doesn't solve that problem, but it does provide a channel that is likely to receive an update in most distributions. It would be nice to not have to choose between sandboxing and security updates, though.

I agree, but nobody seems to be really working on (user-friendly) sandboxing of applications distributed through traditional package managers.

You can use Firejail or bubblewrap, but they are not exactly user-friendly solutions.

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

#150

Post by pedro2 »

For me Flatpak is akin to Arch’s AUR.

As such, rebuilding Flatpak and its various layers should be easily rebuilt from source or equivalent as available as an option (but not the default). That would prevent some of the issues.

It would also introduce bugs, but at least you would have the option.

Post reply on HN