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.
> 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 Video and Finances which contain apps. Because GIMP should be able to access your photos but not your accounting spreadsheet.
It should even be possible to do some of this automatically by file type, e.g. GIMP can access any PNG file the user can but not any spreadsheet file, or read a shared library but not write to it.
Very much this. Something resembling an arbitrary number of groups per file (essentially a set of tags) and an analogous (arbitrarily numerous) set of tags applied to a process which match the launched binary. Bonus points if file format or other characteristics can somehow be worked in to automate things a bit while still maintaining security. A simple tagged group membership approach like this seems like it would be reasonably easy to use without getting in your way.
Does anything remotely resembling this already exist?
Edit: Before anyone says that SELinux resembles this, as far as I'm aware SELinux policies are anything but simple to set up and use correctly. However, SELinux types are inherited from parent directories and do look an awful lot like this. The main thing missing would seem to be that I can't find how to apply multiple contexts or types to a single file, but perhaps I'm just failing to navigate the manual?
> What we need is to add an application list to filesystem ACLs and then have security groups like Video and Finances which contain apps. Because GIMP should be able to access your photos but not your accounting spreadsheet.
This isn't that hard in a technical sense. But I very much doubt you can get the casual users to actually do that. They'll just end up with one giant group, because it's the easiest and doesn't require understanding the concept of security boundaries.
Basically, it'd be Vista UAC prompts all over again.
If you are interested in trying something similiar, this is what Qubes OS [1] does, albeit with a different implementation (separate VMs for separate tasks).
It is more cumbersome to use than the current mainstream paradigm, but not that much!
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.
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.
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.
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.
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.