bubblewrap is currently incompatible with any Qubes VM, meaning the alpha Tor sandbox doesn’t work in straight Debian VMs or Whonix VMs in Qubes-Whonix (see Patrick’s efforts); and
32 bit binaries are no longer being built for the alpha Tor sandbox, which I thought meant that this will now be incompatible with 32-bit non-Qubes-Whonix.
Thus, Firejail is the only working solution for Qubes-Whonix & non-Qubes-Whonix currently. I don’t expect either of these problems will be solved anytime soon (bubblewrap & 64-bit non-Qubes-Whonix).
This might be better for the Firejail instructions for Tor Browser i.e. how to properly incorporate the Firefox profile (haven’t tested it yet, but will soon):
The advantage of Firejail is it works with programs as is instead of needing them to be specially packaged for compatibility like Flatpak would. It would be very interesting to know more from the parrotOS devs about their implementation and approach to sandboxing their system by default. I see room for collaboration/use of their work for our benefit too.
Some great feedback from the ParrotOS dev. Its very doable with their technique. [0] @Patrick see if you have any further questions you would like to ask.
[0] They enable it automatically for all available programs and re-aply symlinks in event of package updates. Also the home folder is whitelisted for saving files the users wants persistent. I asked about the code and whether its deb packaged.
By automatic we mean out of the box. We don’t want people to type firejail X to take advantage of its security but rather the process is completely transparent to the user.
Problem is, it is these profiles is mixed up with all the C code provided by firejail. A full fork of firejail. That would be good if it was taken by firejail developers like this and merged upstream at firejail.
Just the parts they changed (added profiles; Debian maintainer scripts) in a separate package would a lot a lot better to avoid adding C code and compilation to Whonix source code. Otherwise I’d need to verify firejail by firejail upstream vs firejail from that package matches; and compile.
Could we add firejail to the default packages being installed so it would maybe also get some more testing? The version from backports looks close to the upstream version. Also the specific profile for the torbrowser seems to work, not just the default profile.
Tickets are a bit “disorganized” since now firejail is suggested as standalone without T804. Be that as it may…
The suggestion is to add Debian -- Details of package firejail in stretch to some Whonix meta package? Which one? Please send a pull request. Can you please test that installing firejail alone doesn’t add any regression? Does it activate by default?
I don’t think we can guarantee zero regressions, but anecdotally I have yet to find a program that doesn’t work with firejail.
From the ParrotOS thread, it appears that what happens is Firejail has a script which can automatically compare installed system binaries and reinstall symlinks as packages are reinstalled. Parrot runs this script (which I haven’t seen but haven’t really dug for yet) every time a package is installed via a post-installation step. This itself could be dangerous as perhaps a user is unaware that firejail is not reinstalled in front of a package reinstall, or perhaps they install a package that is not protected by default firejail profiles and also not ParrotOS firejail profiles and expect it to be automatically applied. User education will always solve problems where technology is lacking. We should make the user aware that firejail is in play on the system regardless of how seamless we can make the integration as they may want to review firejail and the available integrated profiles for themselves.
That all said, I am still learning and still educating myself on firejail and the current state of Whonix development itself. If I could send a pull request that would implement firejail as a default package on a meta package, and then create a post-install hook to implement firejail profile reinstallation, and then implement specific and tight firejail profiles, that would still not alleviate all of the potential problems. Again, user education is key, and I’ve noticed this mentioned a couple of times in the Whonix wiki and could not agree more.
That’s just my $.02 on the matter, for what that’s worth right now. Still learning.