General notes about Firejail settings:
- The master firejail.profile contains global settings.
- New profiles or tweaked ones that override the default ones go under ~/.config/firejail (path configurable if needed). The default ones exist under /etc/firejail
specifies the ways to set programs to automatically start contained.
- Xpra is not a hard-coded dependency out of consideration for headless systems. TODO: Decide which anon-shared package to add it to.
- Creating symlinks to start programs automatically under firejail is as simple as running
sudo firecfg. This covers all software on the system that has a firejail profile. To list all symlinks:
firecfg --listand to reverse this action:
- Tor Browser
- To integrate with Firejail, the script developed by Yawning is meant to replace the one in this path: /home/user/.tb/tor-browser/Browser/start-tor-browser
- While the profile can reside under ~/.config/firejail
- Non-Qubes-Whonix: Would probably work. But why not use /etc/firejail? That way there can be cleanly packages. Packages writing to ~/ home anything is considered a grave packaging but (and really problematic indeed).
- Qubes-Whonix: One ~/.config/firejail modification per AppVM would not be great. Also modifications to /etc/firejail in TemplateVM would be much better so these are shared among all AppVMs.
A short term workaround until the proposed upstreaming of start-tor-browser  happens: is to append Firejail to all launcher commands under: /usr/share/applications. Reasoning: TBB folder not visible to users. For a user to accidentally execute Tor Browser without protection, they have to go out of their way to find and launch the start-tor-browser script in the hidden TBB folder. In TBB's use-model we don't have to worry about command line users because TBB is a GUI app first and foremost. Visual indicators further help warn against accidental execution in the unlikely event it happens. If they use command line the might as well put Firejail before the script name. This solution is tested and working and survives TBB upgrades.(That solution however does not survive tb-updater upgrades.)
- Firejail should probably get its own Whonix helper package to include custom profiles (Yawning's TBB). Xpra dependency should be coded there.
- Wait for version newer than 0.9.40 to hit Debian backport repos because it resolves Iceweasel profile problems.
- Decide if firecfg should be scripted to enable all profiles by default.
Add discussion points here.
- Changes to TBB launchers required.
- Decide on application launcher paths. Documentation in Arch is contradictory to Debian:
"Some applications use non standard paths. For these you will want to copy the .desktop launchers from /usr/share/applications/*.desktop to ~/.local/share/applications/ and then proceed to include firejail (and possibly seccomp) on the EXEC line. Some applications use non standard paths. For these you will want to copy the .desktop launchers from /usr/share/applications/*.desktop to ~/.local/share/applications/ and then proceed to include firejail (and possibly seccomp) on the EXEC line." 
There is no ~/.local/share/applications/ folder in Debian AFAIK. What is the difference between both paths? Shouldn't bother if the workaround works equally well.
tb-starter is the place where such changes belong. Playing with application launchers will break things.
- Decide on whether to introduce pinned packages and sid repos by default to access the newer version ASAP. Firetools is in sid and stretch only but its dependencies will create a mess even with pinning. Firejail sid is standalone and installs well on stable.
Won't work. Terrible idea as per Debian dev comments. Stick to version in Backports
Other Isolation Frameworks
"Is Flatpak tied to GNOME? No. While Flatpak has been developed by people with a long involvement in the GNOME community it is not tied to any desktop. In fact, it was designed with the explicit goal of allowing it to build applications using any library stack or programming language an application author might want."
Asked if multiple frameworks stackable and the answer is no. You can't run a setuid binary containment app under an unprivileged sandbox. Shipping flatpak by default does not imply running every app as a flatpak. Flatpak can be turned off if we choose.
Verdict: I like how Firejail can contain any program arbitrarily without changes needed to be made to it unlike Flatpak. It does not need any support from upstream software developers to support isolation - it remains the preferred framework for us IMO for that reason. Still, its good that DE developers are now going in the right direction to bring more security to users.
If flatpak is adopted and enabled by default in Debian upstream we can remove Firejail profiles that cover apps already supported by the former - might be complicated but increases protection coverage of system programs as its likely they will cover different sets of software with some overlap. Or we can disable Flatpak and stick with Firejail only.
Impressum | Datenschutz | Haftungsausschluss
Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation. Whonix (g+) is a licensee of the Open Invention Network. Unless otherwise noted above, the content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.