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

181–190 of 296 posts

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

#181

Post by gspr »

Ar-Curunir wrote: post #43
gspr wrote: post #28

Earlier quoted context omitted.

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 problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.

Not saying it's perfect, but sure there is! https://en.wikipedia.org/wiki/POSIX for example.

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

#182

Post by kaba0 »

xvector wrote: post #84
jeppesen-io wrote: post #57

Shall I plug NixOS?

What is Nix and why is it a better alternative?

Basically, nix (and guix, which is based on it) is the only package manager that actually solves the dependency hell problem properly.

It makes builds reproducible, and basically a package will depend on it’s inputs’ hashes. So you can not only install multiple versions of the same package that is solved by some package managers although in hacky ways, you can install multiple ones that only differ in eg which libc version they link to.

In this way, I do think that it is truly revolutionary - but it is a package manager (and NixOS makes basically the OS a big package). Flatpak and snap try to do this as well, in an objectively worse way, but they also provide different features, so they are not in competition. I would rather like to see flatpak and snap employ nix for solving the package management problem and build on top of it. That would actually make the linux solution better than what we have on other OSs.

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

#183

Post by Blikkentrekker »

Ar-Curunir wrote: post #43
gspr wrote: post #28

Earlier quoted context omitted.

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 problem with existing OSes is that they do not offer any restrictions on how the pieces can interact. There’s no well defined API or principles.

That is because it turns out that everyday software often needs such permissions to operate gracefully.

What is wanted is some system that allows one to run untrusted sofware in without fear of it compromising one's system. — the problem is that the set of software that can be so ran is smaller than expected, as most software by design is capable of making changes to one's system, as one typically uses software for such tasks.

A text editor that cannot edit every file in one's home directory would be rather useless, but in doing so, it is of course capable of completely destroying one's system as well.

The dream of being able to run “entrusted software” is not a very realistic one.

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

#184

Post by vetinari »

lambda_obrien wrote: post #171
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…

Why not just fake stuff? If you give software no file permissions, show it an empty dir. Tell the software you saved it's file but don't, just keep it in an memory overlay just for that program's run. If it wanted the network, give it a dummy net.

And then have a barrage of users complaining that their app packaged in flatpak doesn't work.

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

#185

Post by necovek »

oxylibrium wrote: post #109
necovek wrote: post #81

Earlier quoted context omitted.

> 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 san…

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 instance no custom previews which is probably the most common thing apps customize): basically many apps will need to break backwards compatibility and move to a suboptimal solution (meaning expend effort for a worse UX) just to provide users with sandboxing.

Don't get me wrong, it would be great to get the best of both worlds, but since it means I have to trust individual app packagers to also provide security updates for each app, we are still a long way off from that best-of-both worlds.

(This explanation also adds some context to the recent Audacity release which mostly just moves all project files into a single file)

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

#186

Post by Wowfunhappy »

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.

As it happens, macOS didn’t get away with it for me. It’s the single largest reason I’m moving away from the platform.

On iOS the system works because of the type of tasks I do (and do not) perform on a phone. But when I start an automated Applescript and it pauses partway through with a permissions prompt, that’s a problem.

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

#187

Post by sdwvit »

Koliakis wrote: post #170
syockit wrote: post #135

Earlier quoted context omitted.

I don't have experience with MacOS to comment, but at least in Windows it's pretty much the same: as soon as you get the user to click OK in the UAC prompt, everything is fair game after that. Is there even a model desktop OS we can look to as being secure? Chrome OS perhaps?

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 slow is it?

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

#188

Post by vorticalbox »

> The most popular applications on Flathub still suffer from this - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC are still not sandboxed.

All of these require access to the users data to actually function.

GIMP, Inkscape: edit/view photos and save creations VSCodium, PyCharm: edit/create project files Audacity, VLC: play user media

these apps have the same "problem" in snap requiring --classic to allow access to the users files.

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

#189

Post by XelNika »

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…

File access should, by its very nature, be asynchronous. If you're only introducing asynchronicity to support Flatpak portals, the original code was flawed.

You could also argue the reverse: if synchronous file access was good enough before, there should be no real reason not to use Flatpak portals synchronously as well.

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

#190

Post by KerrickStaley »

A small nit about an aside in the article: Is fcitx "the" East Asian IME for Linux? As a speaker of Chinese as a second language, I use IBus (with libpinyin), which is supported out-of-the-box in GNOME and seems to provide a better user experience than fcitx the last time I checked (which was probably 10 years ago).
Post reply on HN