Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flatpak – a security nightmare

flatkill.org

Post reply on HN
Print view View original

101–110 of 264 posts

Re: Flatpak – a security nightmare

#101

Post by segmondy »

gmueckl wrote: post #26
dralley wrote: post #13

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action c…

This highlights a conceptual dilemma with access rights in file systems: if an image manipulation software wants to open .bashrc, this is potentially suspicious. But for a text editor this is probably ok. Likewise, a text editor that reads a binary executable is probably a little bit fishy. But a unzip program might so that for a valid reason (e.g. ZIP archive appended at end of program, a common thing for installers…

I'll just make a file link to .bashrc and call it /tmp/foo.png, what are you going to do? Not open links? Check if the file links to .bashrc?

If an image manipulation software wants to open .bashrc, allow it. If it has permission to write to one, so be it. If .bashrc is such a security nightmare, then perhaps the issue is that programs can write to it. Remove the write permission. Perhaps a security model where restoring permission asks for password.

Re: Flatpak – a security nightmare

#102

Post by dcbadacd »

mort96 wrote: post #96
dcbadacd wrote: post #85

Earlier quoted context omitted.

Maybe it's about time we break backwards compatibility and get rid of all dotfiles in ~ and move them to say .local/share/software_name and then start restricting access to those folders?

But I still want to be able to use my Flatpak VsCode to edit config files in .local or .config, and I still want to use my Flatpak Gimp to edit images in .local/share/icons.

The chances of those things happening are rather low for the average user a prompt would solve those and would be a way better solution that just allowing full access to ~ and any dotfiles.

Re: Flatpak – a security nightmare

#103

Post by untog »

yzmtf2008 wrote: post #98
viraptor wrote: post #92

Earlier quoted context omitted.

The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided. It's like standard Linux permissions. If you install an ap…

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.

Re: Flatpak – a security nightmare

#104

Post by altfredd »

dralley wrote: post #13

Cross-posting a comment from Reddit, because it nails one of the points mentioned: --- The list on the page is Gimp, VSCode, PyCharm, Octave, Inkscape, Steam, Audacity, VLC, ... With the exception of Steam all of those programs are used to open random files anywhere on the system. One could implement a permission prompt for accessing a file, but that would lead to a Vista-like Situation where basically every action c…

There is no reason to make it complicated. Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop.

I have been using a directory-per-program sandboxing setup for several years (and still do). It is very convenient, and does not require any additional effort to adapt. In fact, I now have less clutter in my actual $HOME than ever before.

Programmers like to come up with clever ways to solve nonexisting problems. I say — give user a way to bootstrap a sandboxed environment into a directory of their choice (no, using auto-generated directory names is NOT allowed!), and the "problem" would no longer exist.

Re: Flatpak – a security nightmare

#105

Post by cyphar »

geofft wrote: post #44
briffle wrote: post #29

Earlier quoted context omitted.

This is pretty much the whole point of SELinux (and probably AppArmour)

How does SELinux or AppArmor distinguish between those cases? More interestingly, how can it tell that VSCode spontaneously editing .bashrc is bad, but doing so in response to user input is good? (There are capability-based systems that permit distinguishing between these cases, but to my knowledge SELinux and AppArmor don't support this.)

SELinux and AppArmor would allow you to specify that your text editor is allowed to edit .bashrc, but some random other program isn't.

But I agree with you that this is not really a useful security feature -- you'd want something where a program has to be explicitly granted permission rather than some programs being able to do things that others can't (because then any attacker will just spawn "vi -c 'bad payload'" to get around the restriction).

Re: Flatpak – a security nightmare

#106

Post by wbond »

> CVE-2018-11235 reported and fixed more than 4 months ago. Flatpak VSCode, Android Studio and Sublime Text still use unpatched git version 2.9.3.

Wait, what? We explicitly do not ship a Flatpak version of Sublime Text, and no version of Sublime Text comes with git.

After such inaccurate information, I can’t help but question the rest of the article.

Re: Flatpak – a security nightmare

#107

Post by viraptor »

yzmtf2008 wrote: post #98
viraptor wrote: post #92

Earlier quoted context omitted.

The system is configured to run apps in a sandbox though - that's completely true. It's the app's part that declares: it needs full access to your home directory to work. If that wasn't possible, we'd get people complaining about apps not working as expected instead. The balance may not be currently on the right side, but they don't lie about what's provided. It's like standard Linux permissions. If you install an ap…

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

It depends on your use case. If you sandbox tar (for example), you'd do it be removing all network access and a few fancy caps, but you'd leave the rw access to the whole system. (within its standard privileges) If you sandbox netcat, you'd do the opposite: remove all fs access (unless you care about pipes) and leave open networking.

There's nothing about the idea of a sandbox that requires a specific approach.

Re: Flatpak – a security nightmare

#108

Post by niemeyer »

linappdev wrote: post #93
phaer wrote: post #12

Could someone knowledgeable enough comment on how this compares to Cannoicals Snappy https://en.wikipedia.org/wiki/Snappy_(package_manager) ?

With the exception of snaps running on Ubuntu and Solus, snap confinement is limited. Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement, currently. Solus imports these changes into their kernel, though I don't trust the changes much because they haven't undergone formal review and have been approved by the kernel developers. So, for example, on Fedora, Debian, CentOS, or…

> Snaps rely heavily on Ubuntu's specific flavor of AppArmor to be able to offer full confinement,

The AppArmor patches have been largely upstreamed by Canonical, and improvements continue to float upstream constantly. So claiming it's not being reviewed isn't accurate.

> * Canonical doesn't know how to work with SELinux at all, and doesn't want to learn how to

That's disingenuous. Canonical works with many parties, and has people working on LSM stacking for example precisely to support co-existence of the systems. We also had exchanges in the forum to discuss the implementation of actual backends in snapd to support it, but Canonical indeed won't pay for the cost of implementation until there's a reason to do it. That's business as usual and pretty straightforward.

> In addition, the majority of snaps are not sandboxed at all anyway, as they operate in "classic" confinement.

That's incorrect by a huge margin. I'm curious about where you could possibly have based that opinion on? Classic snaps require manual reviews, which need to be backed by public justification. You can see every single request floating by in the store category at https://forum.snapcraft.io. That means every snap people push without talking to anyone are not classic, and thus the vast majority.

> Finally, Canonical is the sole arbiter of snaps.

Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor.

> Disclaimer: I'm a Linux app developer that grudgingly deals with both formats. I'd rather just keep using RPMs myself

And I work on snapd (and have also worked on RPM back then, so enjoy :).

Re: Flatpak – a security nightmare

#109

Post by yzmtf2008 »

untog wrote: post #103
yzmtf2008 wrote: post #98

Earlier quoted context omitted.

“Sandbox” and “full access to your home directory” doesn’t compute. That’s literally one of the biggest reasons to sandbox applications.

It's true, but I'm not sure how e.g. VS Code would even work on a truly sandboxes environment. There'd be no file browser.

macOS does this via the open dialog — opening a directory gives an application full access to that directory

Re: Flatpak – a security nightmare

#110

Post by androidgirl »

bubblethink wrote: post #60

I don't see any real benefits to using flatpak in its current form. You get worse integration with the rest of the system, poor tools that are inferior to your system's package manager, and no real security benefits currently. What's the point of launching all these rubbish proprietary apps on the store with no real sandboxing ? It creates a false sense of security, which is worse. All the proprietary apps will do wh…

I use flatpak on my system for the fact that packages can be had there I can't get through my package manager easily and officially. That's the only selling point!
Post reply on HN