Sandboxing - what are the best options?

Support
1

Hi!

Having used other Debian based distros for many years, I am finally moving to Kicksecure (running in Qubes OS VM’s).

However, one thing that confuse me is sandboxing. I have been using Firejail up until now, but now considering to use something else due to the SUID issue.

For Firefox, Flatpak sandboxing break Firefox’s internal sandbox. Is there really no decent way of sandboxing browsers in Linux? The only thing that seems to increase security (without SUID issues or breaking Firefox internal sandboxing) seems to be writing an Apparmor profile, does that make sense?

For Evince and Libreoffice the choice seems to be between Flatpak sandboxing or MAC with Apparmor (AFAIK doing both is not an option). What would be the most secure option?

For other applications like GIMP and the file manager, Flatpak seems to be the only realistic option as they do not have Apparmor profiles.

I am trying to avoid malware/attackers getting access to certain files in my home folder, or becoming root. I know that no sandboxing can compare with VM isolation, but for me it’s important to prevent that the VMs do no keep getting infected as well. And running every suspicions file and webpage in a new VM would disrupt my workflow too much.

2 Likes
2

AppArmor under Debian Trixie is of very limited use. UNIX socket mediation and D-Bus mediation does not work (contrary to what the manpage claims), so if a process is permitted to open any single UNIX socket, it can open all UNIX sockets on the system that file permissions allow it to reach. This includes the D-Bus socket, which (among other things) allows a process to escape AppArmor confinement by loading a malicious LD_PRELOAD variable into a systemd user manager.

Difficult to say. AppArmor is frequently not very useful as covered above, but Flatpak has its own set of problems. See:

(Note that Flatpak isn’t necessarily useless or harmful if used carefully by a sufficiently skilled user, the point made by the above site is mostly that it provides very little real-world protection when used casually in the way a usual user would.)

Kicksecure is working on our own application sandboxing framework in an attempt to address the limitations of existing solutions:

The current plan is to use systemd-nspawn as a backend, and write a sophisticated wrapper around it that makes it user-friendly while discouraging unsafe uses. The system being build (sandbox-manager-dist) does not yet exist in any usable form, but systemd-nspawn is available from the Debian repositories. You may be able to use it to do what you want, though it will take some effort.

3

Thank you.

I decided against both creating an apparmor profile and using systemd-nspawn as it is too complex.

Sandboxing of browsers is really a sad story in Linux at the moment, cant wait until the Kicksecure sandbox is ready.

So I decided to give Firejail another chance, using the SUID mitigations described on the Firejail website. However using Firejail in Kicksecure seems to disable User Namespaces in the Firefox sandbox. How can this be fixed?

I tried “sudo permission-hardener disable /usr/bin/firejail” but it told me that Firejail was never hardened, so the SUID hardener does not seem to be the cause.

Unsandboxed Firefox has a fully working internal sandbox.

1 Like
4

This is a known issue with Firejail. See:

5

Thanks, that’s useful. Solved!

1 Like
6

Be careful with GIMP since you can run code inside GIMP’s Script Fu, its usefull for running a bunch of commands to modify an image and add cool effects but is an attack vector.
I believe you can remove its support with sudo apt remove gimp-python

Also need to disable GIMP’s access to the internet with the /etc/gimp/2.0/gimprc Firejails --net=none is better

# Disable online features partial defense
(user-manual-online no)
(check-updates no)
7

Was not aware of that.
sudo apt remove gimp-python did not work (no such package), but perhaps adding this to gimp.local (Firejail profile) could do the job?
ignore private-etc @x11,gimp,python*
private-etc @x11,gimp

Would be useful with a list of applications for different purposes that are the most secure and have the smallest attack surface.

8

I mean, it’s no more of an attack vector than any scripting language to my awareness. You can’t embed a script into a GIMP image, so I don’t think there’s much risk here unless one is installing untrusted GIMP plugins. Of course, malware could install malicious GIMP plugins, but malware could edit ~/.bashrc too, and that would be a much more useful target since it runs automatically so frequently.