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

151–160 of 264 posts

Re: Flatpak – a security nightmare

#151

Post by mcguire »

viraptor wrote: post #63
geofft wrote: post #40

Earlier quoted context omitted.

The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. The Debian security team is a volunteer team, and it's entirely realistic that someone may actually have seen delays in the packages they care about getting security updates. "No you don't" is arrogant - you have no way of knowing that.

> The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. Actually they do. Debian does carry local patches when necessary. It will also backport patches to release in older versions which may not be updated upstream. They literally make the updates happen. In this case, it's valid to ask - where/when did you see the issue with this wo…

...and, as I recall, that got them in trouble with openssl.

Re: Flatpak – a security nightmare

#152

Post by derefr »

tannhaeuser wrote: post #71
gmueckl wrote: post #15

Earlier quoted context omitted.

Most of the issues that are expicitly mentioned are fixable bugs and not fundamental design errors. In the end it seems to come down to poor package repository maintenance, which many repositories for Linux distros suffer from. While I do not like the idea of flatpak very much myself, this criticism seems too harsh to me.

A poor package repository is a consequence of too many packaging formats, and lack of volunteer maintainers, though (I, too, could have made more to help). So coming up with package formats all the time - .deb, .rpm, .apk, Alpine's pm format, pkg, .dmg, flatpack, snap, docker and whatnot - is exactly the problem (cf. https://xkcd.com/927/ ). Maybe Slackware got it right after all by only building from upstream .tgz s…

Those aren't "package formats"; they're different names for a very small set of actual container formats (e.g. tar, zip), with the names there to namespace different incompatible OS file-layout hierarchies and sandboxing technologies.

If it was just about packaging, everyone would just have a build server that creates their binary once and then slams it through https://github.com/jordansissel/fpm.

But there are more fundamental differences between OSes than how the insides of their packages look. The packages are "differently shaped" to prevent you doing something stupid and damaging your OS by installing a package that will spew files in all the wrong places, and rely on classes of protections that aren't there.

Re: Flatpak – a security nightmare

#153

Post by comex »

michaelmrose wrote: post #118
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.

Nobody wants a packaging system that can't package existing apps not designed to be secure in a useful fashion. In a traditional app packaged as a deb/rpm the developer releases the source which then must be packaged and made to work with each distribution/platform. If the app is malicious or is sold to someone/compromised by someone who is then you are 100% hosed. In a flatpak not designed to be properly sandboxed y…

Well, the ideal solution is to fix the application to use the special file chooser that gives the app permission to access whatever files the user chose. I only know the basics about Flatpak, but I know it has such a file chooser; does Gimp not use it, or is there some other issue that makes it require full home directory access?

In the meantime – sure, package the app, but it shouldn’t show up as “sandboxed” in the GUI if the sandbox isn’t meaningful. Instead it should come with a nice scary warning that the app has access to all of your files… you know, for everyone to ignore and click through. (You can lead a horse to water…)

Re: Flatpak – a security nightmare

#154

Post by niemeyer »

bubblethink wrote: post #127
niemeyer wrote: post #108

Earlier quoted context omitted.

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

>Well, yes, it has created the project and maintains it actively for years now. You're welcome as a contributor. So, there cannot be a third-party/self-hosted snap store ? That seems like a major limitation.

There are self-hosted proxies, and there are publicly hosted stores, but all stores are part of the exact same hierarchy and share some of their knowledge. That's mainly a consequence of implementing the intended user experience as originally designed back then.

Re: Flatpak – a security nightmare

#155

Post by andrewflnr »

AnthonyMouse wrote: post #149
altfredd wrote: post #104

Earlier quoted context omitted.

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

> Sandboxed programs have their own $HOME. You can drag & drop files into their $HOME. Full stop. That is not very good. Suppose you create an audio file with Audacity and a series of images with ImageMagick and GIMP, then use ffmpeg to combine them into a video and VLC to view it. They're all operating on the same files. What we need is to add an application list to filesystem ACLs and then have security groups like…

It might work if you hardlinked the directory containing the shared files into all your apps' workspaces (aka $HOMEs). I would just be worried about leaking privileges through the link somehow.

Re: Flatpak – a security nightmare

#156

Post by bubblethink »

cyphar wrote: post #143
bubblethink wrote: post #112

Earlier quoted context omitted.

>There is no reason that these issues can't be ironed out going forward. That's true in principle, but selinux still doesn't see that much adoption outside of the distro configured policies for typical server usecases. A lot of desktop apps run unconfined. So I think this is where openbsd's approach to stuff like this is more practical. They iterate and wait before rolling out features like pledge or unveil so that t…

> selinux or any of the other security mechanisms are completely ineffective if users or developers are largely ignoring them SELinux works by default on Fedora, and even has a nice GUI popup that explains to you what happened when an SELinux policy blocked an action (so that you can reconfigure it). It's pretty neat, and is massive improvement to SELinux of old -- I would recommend trying it if you haven't recently.

Yes, I think my point still stands that a large number of desktop apps either have lax policies or run unconfined. I don't know if things have changed that much recently. Confinement is opposite of ease of use. So Fedora/RHEL have selinux in enforcing mode, but the policies are still more effective for servers. I don't know how far they go with the policies for desktop.

Re: Flatpak – a security nightmare

#157

Post by derefr »

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…

Ways macOS handles the this problem:

1. the File Open dialog is itself the permission prompt.

2. documents consisting of many files are structured into project bundles; you open—and thus grant access to—the entire bundle at once.

3. the GUI is structured to orient activity around documents rather than around applications. You hardly ever launch an app and then open a file in it. Instead, you open the document and the app is its default handler; or you right click the file and Open With the app; or you drop the file onto the app's launcher shortcut; or you drop the file onto the running app window. All of these actions implicitly grant the app permission to open the file, in the same way the File Open dialog does.

4. Apps can persist the token representing this granted permission in a serialized state file, and it will even survive OS reboots. There are some macOS utilities (e.g. DaisyDisk) that need access to your entire disk—but you only need to grant this access once. (DaisyDisk asks, on first startup, for you to open the Finder and drop the icon representing your primary hard disk onto the running app.)

Re: Flatpak – a security nightmare

#158

Post by altfredd »

mbreese wrote: post #146
altfredd wrote: post #104

Earlier quoted context omitted.

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

I'm sorry, but that solution isn't workable to many (likely a majority of) users. Most will expect that when you open two programs that need to work on the same file, that if you save the file to your $HOME/Desktop that it will appear in $HOME/Desktop in other programs. Sandboxing or not. I'm happy it works for you though.

Well, I have used it for years, and never encountered any issues. If you want to share a file between sandboxes you can hardlink it. Or use descriptor-passing. Or… But it feels like you are just looking for theoretical flaws in my personal workflow for the sake of coming up with flaws.

Of course, it is silly to sandbox your bread-winning software. I don't sandbox Android Studio. Or ffmpeg. Or VLC. Personally, I believe that nobody has a right to decide, how to sandbox software on other people's computers. I think, that such decision should be left to users of that software. Unfortunately, it looks like Flatpak does not make that easy.

Re: Flatpak – a security nightmare

#159

Post by ndnxhs »

wmf wrote: post #145
megous wrote: post #139

What's cross-platform experience for packagers/builders? Seems like you can't do cross-compilation, so expecting upstream to provide flatpaks for users is expecting upstream to manage virtual or real machines for every [desired] CPU architecture with all the annoying host distro installation/management, networking stuff, etc.? At least with the current model, upstream developers can offload most of that to distributi…

In reality every desired CPU architecture is x86-64.

That's not reality at all. Many laptops run ARM CPUs now. Especially on Linux.

Re: Flatpak – a security nightmare

#160

Post by comex »

AnthonyMouse wrote: post #136
voltagex_ wrote: post #120

Earlier quoted context omitted.

Have a look at AppV on Windows. It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home.

> It isn't great, but all I/O is redirected, so in your example, tar would think that it's writing to /home/voltagex but it might actually be writing to /run/sandbox/blah/home/voltagex - so if something ran rm -rf it'd only delete the sandboxed home. Then how do you get it to operate on your actual home directory when you want it to? Making it operate on some different structure has been possible with chroot() or LVM…

Well, Flatpak is designed for GUI applications, where the user indicates their intent to grant access to a file by picking it the file chooser (which is magic, runs outside the sandbox, and grants the sandbox access to whatever file the user picked). This is nice because the sandbox can be invisible from the user’s perspective. I think AppV is similar.

For a CLI application like tar, this would be a bit harder because every program has its own command line syntax and you can’t always tell what arguments are supposed to be filenames. Still, you can do reasonably well by just granting access to any argument that looks like a filename. The Plash shell, a forerunner of modern sandbox designs, took this approach, but as an additional security measure only granted read access by default; if you wanted to run a command that writes to a file, you had to use special syntax before the filename [1]. Still reasonably usable, although there are other issues, like the fact that many Unix programs default to reading and/or writing to the current directory…

[1] http://www.cs.jhu.edu/~seaborn/plash/html/shell.html#shell-d...

Post reply on HN