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

111–120 of 296 posts

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

#111

Post by vntok »

cheph wrote: post #102

> The sandbox is STILL a lie No it is not. If sandboxed means no access to filesystem, sure it would be, but that is not the only definition of sandboxed, that is not the definition of that under which flatpak said they would operate, that is not the definition of sandboxed under which other things operate. If you want them to use a different definition of sandboxed, by all means submit an issue making the case, but…

A single line of code allows any "sandboxed" program to escape from the sandbox. This is not what the word "sandboxed" means for any reasonable definition of "sandboxed".

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

#112

Post by incrudible »

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…

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

The POSIX APIs do not have such permissions. You can attempt to put something in between and have lots of stuff break, that's what Apple did. On Linux, there is no such authority.

There are alternatives as well, such as sandboxing all the way up to using a hypervisor for every program, which is arguably what you need to run an untrusted program.

> We are living in a day and age where applications ask for overbroad permissions for many reasons, laziness, privacy invasion, and even legitimate use.

Fair enough, but Flatpaks are mostly open-source software and closed-source software can be monitored far better on a Linux system.

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

#113

Post by hkt »

microtonal wrote: post #101
hkt wrote: post #27

Is there a security comparison somewhere of all the new fangled ways of getting up to date desktop software on Linux? snaps etc too? I suppose the real answer may always have been backports on debian distros - which is to say, trusted sources over technical solutions.

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.

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

#114

Post by AshamedCaptain »

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.

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.

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

#116

Post by josephg »

jcelerier wrote: post #65
littlestymaar wrote: post #21

Earlier quoted context omitted.

Look at how the Web standbox is designed: of course some websites must access to your camera (Zoom, Jitsi, MS Teams, etc.) yet you still have to give them the permission! And it's a fine-grained permission (don't want to share your microphone, Ok just don't). I want to be able to give programs exactly access to I want it to access, and just when I want to give it that access. This way I'm sure my SSH keys (or private…

But the web sandbox is terrible and an exercise in frustration when compared to using desktop apps ?

The web sandbox is an absolute delight for users. That users can run javascript code from malicious advertising companies without ill effect is a technological marvel. Consider all the shady nonsense advertising companies do today anyway - and imagine if they had full access to your filesystem when they do it! What a horrifying hellscape that would be.

"Oh, opened our website did you? Don't mind us - we'll just go ahead and install our own 'value add' daemons on your computer that show ads, and exfiltrate your data to improve ad targetting. You can trust us!"

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

#117

Post by cheph »

vntok wrote: post #111
cheph wrote: post #102

> The sandbox is STILL a lie No it is not. If sandboxed means no access to filesystem, sure it would be, but that is not the only definition of sandboxed, that is not the definition of that under which flatpak said they would operate, that is not the definition of sandboxed under which other things operate. If you want them to use a different definition of sandboxed, by all means submit an issue making the case, but…

A single line of code allows any "sandboxed" program to escape from the sandbox. This is not what the word "sandboxed" means for any reasonable definition of "sandboxed".

> A single line of code allows any "sandboxed" program to escape from the sandbox.

How is that what is happening here?

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

#118

Post by ddtaylor »

alerighi wrote: post #108
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…

Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to f…

> But that would require modifying the application

Technically it can be done using LD_PRELOAD on fopen() and such.

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

#119

Post by maffydub »

ddtaylor wrote: post #118
alerighi wrote: post #108

Earlier quoted context omitted.

Is not that simple. First you would need a flatpack daemon that manages that permission, that the application could ask for a path (e.g. by writing in a control socket) and the daemon asks the user and mounts that paths inside the container, and then inform the application that the operation is successful. But that would require modifying the application, and not in a trivial way, and it's unacceptable (you need to f…

> But that would require modifying the application Technically it can be done using LD_PRELOAD on fopen() and such.

Can it?

If my application invokes syscalls directly, that wouldn't hit anything interposed using LD_PRELOAD.

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

#120

Post by loloquwowndueo »

bayindirh wrote: post #103
linmob wrote: post #55

Earlier quoted context omitted.

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…

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 :)
Post reply on HN