Specifically I want to limit a cloud storage desktop app to only be able to access one directory. This is because I do not fully trust what these apps might do. I want to give it access to one directory and block everything else.
This sandboxing is what newer software package formats like flatpak and snap do. There exists a utility, firejail, that allows you to run any application in a sandboxed environment.
Another option occurs to me that may be no better or worse than Vanadium’s, depending on your requirements: Create another user that will be used to set up the cloud storage app who only has access to the directories you’ve shared with that user. While this approach may be more complicated initially, I can see a few advantages that would be attractive to me.
Now that I consider this more carefully, it is a bit complex. Do I add this new user to sudoers to install software, or do I install the software and then assign it somehow to new user?
I envision that the cloud storage app would be installed by a primary user with sudo capability and then available for use by all users of the system. The username created to accomplish the desired cloud storage would also be a member of a group created specifically to accomplish cloud storage - so definitely not sudo capability. You would create a new user and group, add yourself and new user as members of that group, and then create a directory to be shared with the new group. The new group would be given read access to the shared directory (ies) to be backed up. You would log on as the new user, config the cloud storage app to back up the desired directory (ies), and then verify all is working as you want.
Part of verifying that this scheme works as desired is to ensure that the cloud storage app can’t be configured by the new user to access storage beyond what that user has permissions for. Remember that there are system areas in Linux that allow read and execute access to everyone, and the new user would have everyone access by default. If that’s a concern for you, mitigations should be available and not difficult, depending on your requirements.
I’ve used this same approach to share a working directory with trusted team members whose permissions to the shared data varied based on the group(s) they each belonged to and their function on the team. I wasn’t worried about any of the members sabotaging the data or the OS so didn’t consider additional hardening actions beyond those already in the OS.
I’m sure there are nuances I haven’t considered or addressed.
Firejail looks very interesting however, it’s implementation with flatpak looks complex. You reminded me that flatpak does run apps in a (psuedo) sandbox. How reliable do you think using something like flatseal to limit an app’s access to my filesystem is?
On a different not, the cloud backup app I want to sandbox is not on FIrejail’s list (it is an rpm to be installed with dnf), so I am not sure what directories it will need to access in order to work. Does Firejail automatically allow an app to access its config files, etc.? Will it work if I run this app in --private mode within the directory I want to backup? The documentation is not very clear and leaves me with a lot of questions. If you have experience with Firejail I appreciate the help.
If an application runs through flatpak, it is already sandboxed and you can confine it further if the developer set the permissions too liberal. If you doubt about the reliability of the sandbox, then you may be guarding some secrets of at least national importance, and then it is time to consult a security IT adviser.
Lol, unfortunately no such secrets, but for example on a messaging app, it has no access to my file system according to flatseal, but I can access my filesystem and upload files without a problem with the app. This confuses me a bit.
Flatpak implements ‘portals’ for external access. If the application doesn’t have direct access to the file system, but uses the portal API for reading/writing files, then an external process can run to provide the file chooser for you, and then mount only that path into the Flatpak runtime. Similar portals exist for microphones, desktop capture, etc.
That’s interesting. So can the flatpak app access my filesystem through this mechanism whenever it wants, or must the user initiate it?
Including system directories? I suppose you could disable any setting under “Filesystem” in Flatseal, then add the directories where you want to grant access.
As Firejail had no predefined config for my app and creating a new one was too much work, I followed your solution and it works nicely. The only problem is I cannot get the system to maintain permissions globally. In other words, I set ACL and umask, so everything works nicely from the terminal, but if I use nautilus, things start screwing up. As this is how I will add new files, they are saved as read only for group and others despite my settings. I did some searching but have not found a solution. I have grown tired now of this and will probably just install the app normally and be done.
Flatpak uses bubblewrap for sandboxing, not Firejail.