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

51–60 of 296 posts

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

#51

Post by pjmlp »

gspr wrote: post #28
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…

It's almost as if the people riding the "sandbox everything" wave have realized that an operating system is more than a set of disconnected pieces of software. And that to make it an operating system, those pieces must interact, and not be isolated from each other. Go figure. Soon they'll reinvent the classical Linux distro. Poorly. But with a cool name.

The people riding the sandbox everything have experience with platforms that are way beyond what GNU/Linux is capable of.

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

#52

Post by jart »

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 these programs with things like dns is like the hunger games and you can't trust the system to save you with a top-down permissions model when the system itself is the problem.

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

#53

Post by gigatexal »

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…

How better or worse is Flatpak than a chmod +x’d AppImage?

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

#54

Post by foobar33333 »

Iolaum wrote: post #37
foobar33333 wrote: post #29

Earlier quoted context omitted.

I think its more of a one step at a time thing. There is nothing about the design of flatpak which prevents permission popups. The problem is that every desktop program must be rewritten to support this idea and most linux desktop app devs are only vaguely aware of flatpak, let alone ready to start designing specifically for it. The current strategy seems to be having outsiders packaging all the desktop software in t…

> 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 literally no sandboxing. I am certain this is not an intentional misleading feature because Gnome Software is hardly functional and need serious work across the entire program.

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

#55

Post by linmob »

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.org is that it leads to users rather downloading a random deb off the internet or an AppImage than using Flatpak, which both have worse security stories.

[0] https://github.com/tchx84/Flatseal

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

#56

Post by KronisLV »

fulafel wrote: post #36
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…

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

> Oh and reverse engineer the high level intent of the user / application far enough to present an intelligible question to the potentially nontechnical user.

I don't believe that this is such a big problem, since Android is pretty explicit about this - a camera app asking for access to my contacts will simply get denied and will promptly be uninstalled.

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

#58

Post by necovek »

cl3misch wrote: post #45
orf wrote: post #31

Earlier quoted context omitted.

The “classical Linux disto” got us into this mess, so I doubt it.

No, I think what got us into this mess is Ubuntu being a server distro with a standard release cycle (as opposed to rolling release) getting incredibly popular on desktops. Desktop users want the newest version of their UI apps and don't care so much about stability. Ideally, the developers of e.g. Inkscape would offer the newest version on each Ubuntu version via apt, but that does not seem to be feasible. I am no A…

That would be quite surprising since Ubuntu Server appeared only after Ubuntu Desktop was already the #1 desktop Linux distribution (free CDs shipped worldwide, etc).

Canonical started developing sandboxed packages for Ubuntu phones ("click" packages which evolved into "snap" packages). At about the same time, Canonical was interested in getting other big distributions (RedHat, Suse...) to align on what software (kernel, glibc, GNOME, KDE...) to offer LTS on together, but there wasn't too big of an interest from other distributions (and tbh, I think that's a good thing: upstream open source projects would be strong-armed into caring about only a few versions that monopolist distros decided to base their LTSes on).

It is my guess that Canonical has (post-phones) invested in snaps to reduce the burden of maintaining the desktop and trying to earn some money in the process through the Snap Store. Flatpak seems to be Red Hat's slightly more open response that quickly followed.

The only benefit of Snaps/Flatpak for delivering newer versions of apps over just simply statically compiling everything into an app is that some of the things are shared between snaps (like frameworks, glibc...). You still get all of the same problems (theming, fonts,...).

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

#59

Post by e_proxus »

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 managed to achieve this yet in a satisfying way.

Post reply on HN