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

161–170 of 264 posts

Re: Flatpak – a security nightmare

#161

Post by eikenberry »

altfredd wrote: post #104
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 wa…

> I have been using a directory-per-program sandboxing setup for several years (and still do).

I'm curious how you do this? What's your setup?

Re: Flatpak – a security nightmare

#162

Post by altfredd »

eikenberry wrote: post #161
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 have been using a directory-per-program sandboxing setup for several years (and still do). I'm curious how you do this? What's your setup?

I have a heavily-patched version of less-popular sandboxing program (appjail). When I want to handle some files from questionable origin, I create a directory (~/jailboxes/gregs_avi_files) and use appjail to switch to that directory in terminal. Unlike firejail, appjail defaults to full $HOME isolation (and have knobs for Xorg support, so X11 apps work out of box without access to parent /home). There are command-line switches for X11-based and pure terminal environments. It is also possible to whitelist/blacklist individual files in /dev etc. from command line.

I don't use Flatpak etc. — all of my jails use system-wide libraries and executables. They are just launched inside sandbox environment.

Re: Flatpak – a security nightmare

#163

Post by AnthonyMouse »

comex wrote: post #160
AnthonyMouse wrote: post #136

Earlier quoted context omitted.

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

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

That works where it works, but it seems like the sort of thing that will cause so much trouble that people end up turning it off. For example, a lot of files come with meta files containing thumbnails or other data with the same name but different extensions, or an associated directory with related data, and the app will want to access those too but a framework that doesn't understand they're related won't provide it.

You also end up with lots of little bugs, like breaking apps that predict what file you might open next and pre-load it or generate their own previews of files in the app's format.

A possible fix is that if the app tries to access a file you didn't expect it to, display an access prompt. But if that happens a lot it only conditions the user to just click yes every time.

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

You also don't know what's implied. Most commands default to operating on the current directory when not otherwise specified (e.g. as the output location for a tar extract), but half the time that's the root of the user's home directory.

Re: Flatpak – a security nightmare

#164

Post by TheDong »

jessaustin wrote: post #78
TheDong wrote: post #64

Earlier quoted context omitted.

> The FAQ page states "We are explicitly using many features of the linux kernel (bind mounts, namespaces, seccomp, etc) to create the sandbox that Flatpak apps are running in." ... and then it turns out that they aren't, or at least they aren't enforcing it They are using those features. flatpak has network namespaces for applications that don't need access to the network and bindmounts for applications that use ver…

The part where they say it's a sandbox, and it doesn't even attempt to be a sandbox. That's a lie.

"sandbox" is an ill defined term, but what flatpak provides fits it perfectly well.

A sandbox is an environment where capabilities can be restricted in a set of ways.

The javascript sandbox lets you manipulate the website and make network requests, but not access arbitrary files.

The flatpak sandbox is configured per-app and can prevent all fs access, all file io (with seccomp), all networking, etc.

The article is simply pointing out that most popular applications do not use the sandbox features well.

That doesn't mean flatpak does not have the sandbox they claim to, merely that it does not mesh well with many popular apps currently.

I still see nothing that merits the word "lie".

Re: Flatpak – a security nightmare

#165

Post by c487bd62 »

anon_cow1111 wrote: post #46

Random mint 18.04 user here. I just noticed about a week ago that flatpak was downloading huge amounts of data (like hundreds of MBs). I had all system updates set to download and install manually, and hadn't installed anything new for at least a month. All this data was getting sent to /var/tmp as flatpak-cache folders. I don't know what it was doing but I've since turned it off in the startup list. Any ideas? What…

I'm not a flatpaker but maybe it was updating the runtimes? http://docs.flatpak.org/en/latest/available-runtimes.html

Honestly I would be more worried about running mint (a topic not suited for this thread, a quick search would probably show you what I've read about it in the past).

Re: Flatpak – a security nightmare

#166

Post by jbicha »

rhexs wrote: post #95
Ecco wrote: post #5

Wait a minute, did somebody get so pissed at flatpak that they bought a domain name just to specifically host that single blog post?

Guessing some other company involved with packaging formats?

It is far more likely that the website was created by an individual, probably by the guy who submitted the site to Reddit's Linux forum.

Re: Flatpak – a security nightmare

#167

Post by AnthonyMouse »

andrewflnr wrote: post #155
AnthonyMouse wrote: post #149

Earlier quoted context omitted.

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

It also feels a lot like just recreating the original unified $HOME, and requires everything to be sorted by type. If you wanted to organize files by project and each project contained its own images, code, documentation, etc. then if you map the project directory for GIMP it can read all the files even though it should only get access to the images.

Re: Flatpak – a security nightmare

#168

Post by Conan_Kudo »

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.

It'd be nice to see this stuff in (open)SUSE too. wink wink

Re: Flatpak – a security nightmare

#169

Post by mbreese »

altfredd wrote: post #158
mbreese wrote: post #146

Earlier quoted context omitted.

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

I'm not very invested in finding flaws in your workflow, but I am happy it works for you. It does sound interesting and I'd honestly like to know more about how you have it setup.

I stopped using desktop Linux a long time ago and now use a Mac for my desktop work. I take things a bit further and don't let anything write to my $HOME/Desktop -- it's read-only. I don't recommend that as a default for anyone either!

But as far as Flatpak, a few of the "featured" apps are things like Inkscape, Gimp, VLC, or LibreOffice. Not apps that you'd really want to sandbox isolate like you described. (And as you mentioned -- you wouldn't want to do that anyway).

Now a few of the others were Spotify and Slack. Things that you could (should?) definitely sandbox.

I guess I don't see the point in having applications (that is intended for a general purpose user) that (a) need access to your home directory to read/write files and (b) should only have access to a sandboxed pseudo-home directory. Either sandbox it so it doesn't have $HOME access at all, or don't. I'm not sure I see the benefit to this middle ground. Especially for the use-case of general user desktop applications. For server applications, I could potentially see the benefit (although, containers have probably already filled this scenario). What is the use-case you're thinking of?

I appreciate your point of view that no one should be able to decided for you how to sandbox software, but no one is forcing you to use Flatpak packaged programs[1]. Perhaps there should be some way to re-build a Manifest that limits access, or make it so that you can more easily switch granted privileges -- that would probably be a good thing. But someone has to set defaults. If a Flatpak packaged program has too liberal defaults, then maybe that's best treated like a bug and hopefully there is a mechanism to send a patch.

[1] yet... but it might be coming. I think the only way you'd see commercial applications like Photoshop for desktop Linux would be wrapped in something like Flatpak. I still think that most open-source applications will still be packaged by the main distro repositories, regardless of how well Flatpak does.

Re: Flatpak – a security nightmare

#170

Post by AnIdiotOnTheNet »

derefr wrote: post #152
tannhaeuser wrote: post #71

Earlier quoted context omitted.

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…

Hmm... it's almost like maybe applications shouldn't spew their files all over in the first place, then you wouldn't have to worry about putting them in the wrong places...
Post reply on HN