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

81–90 of 296 posts

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

#81

Post by necovek »

foobar33333 wrote: post #32
kelnos wrote: post #20

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. This does mean that some apps potentially do have worse UX; any app that implements a custom file picker will just stop working properly. Arguably in that case you just simply cannot sandbox that kind of app…

>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 implement them probably have an investment in the ecosystem already (eg. Canonical-developed apps will make use of Snap APIs, whereas Red Hat-developed apps will make use of Flatpak APIs).

This will however suck for end users because now software starts depending on packaging :/

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

#82

Post by foobar33333 »

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…

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

I don't think it is that clear. If your app uses GTK or QT, you should in theory get transparent and automatic support for portals. I suspect the problem is the app then tries to directly access the FS outside of the filepicker and gets blocked.

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

#83

Post by darkwater »

diffeomorphism wrote: post #22
littlestymaar wrote: post #8

Earlier quoted context omitted.

Something akin to the web's permissions notifications “This app wants to access ~/Images/ do you want to allow it. Checkbox: I want to remember this” and a centralized permission manager ?

In practice this has the same effect as windows vista had. You train users to immediately click away the annoying popups without reading them.

Or any Android/iOS users (which is perfectly normal, people want to use the app, not being constantly vigilant of not being pwned)

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

#85

Post by scatters »

necovek wrote: post #48
kelnos wrote: post #16

Earlier quoted context omitted.

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…

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.

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

#86

Post by alpaca128 »

brnt wrote: post #75
alpaca128 wrote: post #42

Earlier quoted context omitted.

From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying. I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to cop…

Took me a while to figure out that Signal can't save outside of Downloads as well, especially since its not the default dir it opens when trying to save an file. There's no feedback of any kind. I see flatpak more as a distro independent package format than a way to secure my system.

Exactly, the lack of feedback is the worst part of this. The way it's done right now it looks like the file picker is completely broken and riddled with bugs; the user goes in expecting it to behave normally(given that it looks exactly the same) but it won't show files in the home dir, refuses to even show user-created directories etc.

Even a horrible and annoying pop-up dialog saying something like "file access error" would be better, at least it would be easier to google.

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

#87

Post by fulafel »

KronisLV wrote: post #56
fulafel wrote: post #36

Earlier quoted context omitted.

This is probably quite hard to implement without modifying the packaged applications. Needs something like a mechanism of pausing, instead of denying, a system call in the kernel and calling back to userspace, which would then load new policy into the ruleset on the fly and resume execution. Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the p…

Doesn't this imply that Linux is falling behind somewhat in the area of permissions management? Personally, i think that limiting access to files and such based on users and groups simply isn't enough and instead the user should be prompted (or should be able to configure) which piece of software is allowed to do what (network access, file system access, talking to specific devices) based on their own individual need…

Depends on your POV I guess, whether you think this model is a worthy one. Personally I think we'd be better off building simpler and more understandable compartmentalization.

Re Android, it was designed from the ground up for this (the camera app request is even called "Intent"). So it's not really solving the question of running unmodified applications.

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

#88

Post by akvadrako »

necovek wrote: post #77
akvadrako wrote: post #38

Earlier quoted context omitted.

You can control the permissions with flatpak, it just doesn't ask you about each one by default. But if that's what you're asking for it isn't a major change. It could even be done by using a simple shell script for installation.

On-installation is hugely different from on-use.

That's what portals are for.

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

#89

Post by foobar33333 »

Groxx wrote: post #73
foobar33333 wrote: post #30

Earlier quoted context omitted.

The criticism and response typically boils down to "Yes, but its actually not any worse than what we have now" If you manually install a rpm, deb or add a new repo, your system is completely owned by the person who built that package or repo. The biggest problem is that flatpak advertises sandboxing when some apps disable it but I imagine in the future we will get better UI around showing the user exactly what gets e…

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.

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

#90

Post by danhor »

tim333 wrote: post #19
santoshalper wrote: post #11

Earlier quoted context omitted.

It seems pretty obvious to me. Some programs aren't going to be very useful if you don't let them access resources on your computer, like the filesystem. Some "stateless" apps will do fine without it (Spotify), but anything designed to create and edit files you want to live outside the sandbox is going to need to access them.

I'd be fairly happy for an IDE to stick to the /dev folder where I have that kind of stuff.

While I'd like for more portal-based file access integrated in applications, with flatseal you can pretty easily adjust what folders/files a certain flatplak application can access. E.g. I can limit firefox to only the ~/Download & ~/.mozilla directories, instead of the whole of ~. It also allows for configuring stuff like X11, wayland, network, printing and more.

There's obviously much more to do, but it already prevents many things like a pdf.js exploit being able to copy my ~/.ssh, without having to resort to some really clunky solution like a VM.

Post reply on HN