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

101–110 of 296 posts

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

#101

Post by microtonal »

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 limited to the sandbox (if sandboxing was enabled for the PDF reader).

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

#102

Post by cheph »

> 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 you don't even make it here. You just ignore that and then proceed to act as if your definition is the only reasonable one. And if that was the case the very least you can do is find a reference for your definition.

Try harder with the FUD.

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

#103

Post by bayindirh »

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…

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.

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

#104

Post by sjellis »

cl3misch wrote: post #47

All Linux users I know don't use Flatpack/Snap for their sandbox, but much rather for getting the newest version of some UI app (Inkscape) on an older Ubuntu release. I think this shows that a standard release cycle is not appropriate for desktop users.

Yes, for me the sandboxing is not the immediate benefit.

The instant value is providing channels for developers to ship apps to their users without either side having to mandate the OS that the other uses. Right now, even well-funded projects like Visual Studio Code have to pick and choose which Linux distributions and versions that they package for.

They don't provide packages to the main repositories for Linux distributions, partly because the release cycles are so wildly different. I don't want Debian stable to ship a completely new base system every few weeks, but the release cycle of my Web browser is a new version every six weeks.

In the ideal Flatpak world, I can run Solus or whatever distribution I choose, and the app developers that I rely on can not care about distribution market share, and just target Flatpak runtimes.

The challenge is going to be to ensure that Flatpak repositories and the Canonical App Store (the server end of snap) enforce good enough legal and security checks once vendors have started using them.

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

#105

Post by CuriousSkeptic »

foobar33333 wrote: post #89
Groxx wrote: post #73

Earlier quoted context omitted.

So the tradeoff is "weak sandboxing, or up-to-date security patches". TBH I don't know which I prefer. But I suspect the lack of security patches will continue to get worse and worse as time goes on.

The sandboxing is not always weak. On most apps its almost fully locked down and has access to only your downloads folder. Its only things like vscode which need everything. You can also manually set permissions using flatseal to lock it down as much as you want.

Access to a shared downloads folder doesn't sound “fully locked down” to me. I can imagine situation where I wouldn’t want one app to see what is downloaded by other apps.

Would be better if each process had its own downloads folder (it’s own file system namespace even).

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

#106

Post by foobar33333 »

josefx wrote: post #96
foobar33333 wrote: post #34

Earlier quoted context omitted.

Flatpak apps can not access root owned files. They run as the user and the typical linux permissions apply. They can only gain access to root if they have filesystem access so they can load malware in to bashrc. The thing is this is exactly the same as traditional packaged linux software. Flatpak only offers the ability for extra security.

> Flatpak apps can not access root owned files. I think I didn't make my point clear. I used that as an example of "needs to access files" not meaning "needs to access all files, including but not limited to configuration files". > Flatpak only offers the ability for extra security. With a permission model that apparently can't keep an image editing application from silently editing .bashrc .

>With a permission model that apparently can't keep an image editing application from silently editing .bashrc .

It can, you can cut off all filesystem access or select certain areas. The problem is that programs often need special attention to make sure they work properly using flatpak portals. Currently not many devs are interested in doing this work since flatpak is pretty small right now.

So for now we must assume that Gimp built from the official source, is not a malicious program. Like we have for the last 25 years.

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

#107

Post by foobar33333 »

CuriousSkeptic wrote: post #105
foobar33333 wrote: post #89

Earlier quoted context omitted.

The sandboxing is not always weak. On most apps its almost fully locked down and has access to only your downloads folder. Its only things like vscode which need everything. You can also manually set permissions using flatseal to lock it down as much as you want.

Access to a shared downloads folder doesn't sound “fully locked down” to me. I can imagine situation where I wouldn’t want one app to see what is downloaded by other apps. Would be better if each process had its own downloads folder (it’s own file system namespace even).

Thats why I said "Almost fully locked down"

Each flatpak app does have its own namespace and dir it can save whatever it wants to. Some packages like the MS teams one have been given access to downloads only so you can share files with people. You can turn off this access if you want.

Flatpak also has a thing called portals which let the program request a privileged filepicker so the user can select any file and the filepicker grants access to it for the program. The problem is not all apps are set up to work properly with this right now.

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

#108

Post by alerighi »

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 fork basically every application that you package for flatpack, and the filesystem access could be in various places).

A more acceptable solution would be to intercept all the filesystem related system calls, look if a path is accessible, and if not ask for the permission and either try again the system call and return the result or return to the application E_AGAIN (but is not ideal since not a lot of applications handle that correctly). But this approach would probably require a kernel module, or you can do that with eBPF but obviously you would need CAP_SYS_ADMIN capability so not really possible.

The approach of flatpack is create a container with all the paths that you know the application can access and then jump into the container. A simple solution that even doesn't require a daemon and doesn't require modifying the applications.

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

#109

Post by oxylibrium »

necovek wrote: post #81
foobar33333 wrote: post #32

Earlier quoted context omitted.

>The proper way to do this is to have the file/directory picker run in a separate process (managed by the sandboxing runtime), and the sandbox only grants access to files/directories explicitly picked by the user. Flatpak has this already. They call it portals and it covers more than just file pickers. The problem I have seen is that shoving existing software in to flatpaks and making them use portals ends up buggy f…

> ends up buggy for unknown reasons I think the reasons are quite clear: introducing asynchronicity (one requiring further user interaction at that) into what used to be synchronous code is one of the most common ways to introduce bugs. App devs would be right to sit tight and see who gets a higher market share (snaps/flatpak) before implementing any of the proprietary approaches they might employ. Apps which do impl…

Created an account just to reply to this - there is no "proprietary" API for actions like opening files.

Both Flatpak[0] and Snap[1] use the same xdg-desktop-portal spec[2], which covers stuff like opening files, taking screenshots, sharing screen, and sending e-mails, among other things.

The only major difference in the two sandboxing approaches (noted in [1]) is the ability to execute arbitrary code outside the sandbox - Snap requires you to disable the ("modern"?) sandbox and use "classic" confinement, whereas Flatpak has you send a command over D-Bus to `org.freedesktop.portal.Flatpak.Spawn` while still running the primary application in a sandbox.

This would only be relevant for a small number of programs like IDEs, which are, at the moment, a relatively poor fit for "application"-style sandboxes like Flatpak, or confined Snaps, IMO.

[0]: https://docs.flatpak.org/en/latest/basic-concepts.html#porta... [1]: https://snapcraft.io/docs/xdg-desktop-portals [2]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

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

#110

Post by tored »

foobar33333 wrote: post #54
Iolaum wrote: post #37

Earlier quoted context omitted.

> This brings you to the same state as traditional package managers with little security Does it? From the flatpak state you have a far more clear path towards a sandboxed destination.

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 is happening during install.

5. Buggy installation, common case, click on Install, nothing happens, click on Install again and get warning “hey it is already installing you fool!"

Not everyone is comfortable to use the terminal, fixing Gnome Software should be a high priority for distros.

Post reply on HN