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

261–270 of 296 posts

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

#261

Post by als0 »

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.

On average, I've found Snaps to be better sandboxed. But there are plenty of things to dislike about Snap e.g. not respecting XDG base directory spec, persistent daemon running as root, requiring sudo, unable to control when it decides to autoupdate, coarse grain "connection" system ...and more. A lot of obvious design mistakes that don't get fixed for one reason or another.

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

#262

Post by necovek »

takluyver wrote: post #249
necovek wrote: post #185

Earlier quoted context omitted.

Thanks for a detailed reply and correction on the extent "proprietary APIs" apply (I hope my use of proprietary as in not-an-open-standard does not rub you the wrong way — perhaps "custom APIs" is better): I am happy to hear that it's at least a shared implementation between both for some, very limited things. Even if I want to ignore the "exec()" differences, you are still limited to standard OS file selector (for i…

The upside of having the system draw file dialogs is that file dialogs from different apps look consistent, rather than getting out-of-place dialogs depending on what toolkit the app used. It might sound silly, but it's a real annoyance, and there are plenty of apps that don't implement any custom preview.

Oh sure, but it's hard to make a one-size-fits-all file chooser. The case in point: Gimp, not using GtkFileChooserNative, even though Gtk started off as the "Gimp ToolKit". Otherwise, Gimp does not get image previews.

Even if you do build support for previews in the file chooser, you lose the sandboxing since that preview-generating app now has access to any file a user simply previews. Unless you start introducing a separate, orthogonal previewing system, you also lose caching of generated thumbnails and such.

But it's not only previews: there's also the File-Roller (archive manager for GNOME) "Add File" file picker.

So, while it would be great to have consistent file choosers UX- and UI-wise, you'd be forcing some apps to do away with useful features. And suddenly, you are now into how much consistency matters in this particular case?

FWIW, some issues will remain forever (or well, a long time): in the days of gnome-vfs vs pure Gtk+ file choosers, one could give you non-local files [nfs, smb, sftp...], and the other couldn't, yet they looked exactly the same.

The same is true for Gtk file chooser today (local vs networked files), simply because some apps can handle them, and some can't. These UX issues always annoyed me more than the look of file choosers between apps.

In a sense, I am actually arguing for orthogonal, system-wide file chooser infrastructure with support for everything and your kitchen sink. These would now not be sand-boxed (I don't want to wait an hour for my gallery image previews to load, so caching FTW), so it's a big attack surface (all the previewers, with some like ghostview executing turing-complete PS programs), and it makes you question why would you need sandboxing for the rest of the stuff :)

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

#263

Post by blacksmith_tb »

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.

Well, they are also marketed as a way of isolating dependencies, which they do actually manage to some degree. So they could be weak security-wise without being completely pointless?

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

#264

Post by antimba »

tzs wrote: post #207
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.

I've long argued for applications to use file choosers they do not control, but not for security reasons. I've wanted it for UI reasons. Somewhere I've got a screenshot of a Linux system I had with half a dozen applications trying to open a file. Each used a different GUI framework or widget toolkit, each of which had its own file dialogs, and so the user gets presented with half a dozen different file choosing UIs.…

Major GUI frameworks agree with you and have already adopted this approach and it is already used by many applications, and this has already been the case for years.

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

#265

Post by jart »

e_proxus wrote: post #59
jart wrote: post #52

Am I the only one who sees the irony in it being a scandal for free software to fail to adequately restrict freedom? I just can't imagine an iPhone style restrictions model ever gaining momentum in open source. As much of a prize an App Store would be, it's just too at odds with the culture. I think what makes more sense for open source is to have better tools for monitoring what it's doing. The behavior of some of t…

Security and open source philosophy are two completely orthogonal problems. You can a have an open source system that is the most secure, sandboxed implementation there is. Likewise you can have a completely insecure closed source proprietary system. The freedom in open source could be the freedom to structure your system in the most secure way possible for running untrusted applications. It’s just that no one manage…

Not entirely. A few months ago I was reading about a controversy where the Emacs dev team was concerned about the ethics of conducting an online survey. Can you believe that? That's why I like using their software. You just know people who are that extreme philosophically will never in a million years betray you.

Don't you think tools like Bochs, QEMU, gVisor, etc. are reasonably satisfying? Security is a hard problem since there's an endless push and shove around its tradeoffs hence why sometimes the best one can afford is monitoring.

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

#266

Post by isaiahg »

Am I alone in that I really don't like using flatpaks or snaps over debs. All the software I've installed from both tends to be buggy and unoptimized. Inkscape from flatpak crashes, Kate can't access system themes, steam barely works and doesn't understand the permission system. It feels so much like these projects are taking software and stuffing it into a box it was never meant to fit. Also I don't really think the problem it fixes really exists. People who use Linux know what they're installing and I don't sandboxing really achieves anything other than getting in the way.

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

#268

Post by antimba »

ziftface wrote: post #254
AdmiralAsshat wrote: post #235

Earlier quoted context omitted.

>The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many. The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc. It'…

Couldn't it be possible to ask the user to allow certain directories or files? It might be kind of annoying but it would be safer. Also, it could integrate with the open file dialog and only allow the application to access files selected by the user, and nothing else. That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care. Bu…

> That would be tough because the developer would have to integrate with flatpak APIs, and I don't think flatpak is big enough for developers to care.

For GTK apps, they don’t need to do anything different, as GtkFileChooserNative[1] is recommended for non-sandboxed apps as well. GtkFileChooserNative has glib call the D-Bus API (which is proxied inside the sandbox) for the FileChooser portal[2]. The backend running outside the sandbox (xdg-desktop-portal-gtk for GNOME/GTK; there are also backends maintained by KDE and wlroots developers) shows a file chooser and makes any file (since March 2020, there is also support for folders) selected by the user available inside the sandbox using the Documents portal.

Also the portal APIs are not specific to Flatpak. They can be used by any sandboxing framework that wants to benefit from the work already done to integrate them.

Some apps don’t use GTK or Qt, some apps (like GIMP) still use GTK 2, which doesn’t have GtkFileChooserNative, and some apps haven’t been ported from GtkFileChooserDialog to GtkFileChooserNative (or can’t be ported yet because of missing features in the latter). And the Documents portal doesn’t work perfectly for all use cases: There are issues with getting notified when a file is modified externally and with getting the path of the file outside the sandbox (to display it to the user, if that’s desired).

[1]: https://docs.gtk.org/gtk4/class.FileChooserNative.html

[2]: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

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

#269

Post by Koliakis »

__turbobrew__ wrote: post #258
Koliakis wrote: post #170

Earlier quoted context omitted.

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…

How is this different than running FreeBSD with a jail per application?

Harder boundaries? From what I understand, a hypervisor is much harder to break out of than a FreeBSD jail and provides more isolation between the VMs.

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

#270

Post by djeiasbsbo »

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…

I use flatpaks all the time and I almost always have to adjust these permissions to be more restrictive.

It's really not an issue with flatpak itself, it's the maintainers who give permissions that are not restrictive enough. It's understandable because it makes it easier to package and maintain.. but it also kind of makes the whole concept useless.

What I personally want is apps which are as, if not more restricted than mobile apps.

Post reply on HN