From Whonix

< Dev

General Topics[edit]

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.[1] To list all symlinks: firecfg --list and to reverse this action: firecfg --clean
  • 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 [2]
    • While the profile can reside under ~/.config/firejail[3][4]
      • 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 [5] happens: is to append Firejail to all launcher commands under: /usr/share/applications. Reasoning: Tor Browser 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 Tor Browser folder. In Tor Browser's use-model we don't have to worry about command line users because Tor Browser 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 Tor Browser upgrades. (That solution however does not survive tb-updater upgrades.)

Integration Roadmap[edit]

  • Firejail should probably get its own Whonix ™ helper package to include custom profiles (Yawning's Tor Browser). Xpra dependency should be coded there.
  • Wait for version newer than 0.9.40 to hit Debian backport repos because it resolves Firefox-ESR profile problems.
  • Decide if firecfg should be scripted to enable all profiles by default.

See Also[edit]


Add discussion points here.

Deprecated ideas:

  • Changes to Tor Browser 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." [6]

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[edit]

XDG-App sandboxing pioneered in the GNOME camp is renamed to Flatpak now. Its cross-DE and cross-distro compatible.[7] [8]

"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."

Dev wiki Git

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.[9]

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.


[advertisement] Looking to Sell Your Company? Contact me.

Are you proficient with iptables? Want to contribute? Check out possible improvements to iptables. Please come and introduce yourself in the development forum.

https | (forcing) onion
Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Rss.png 1024px-Telegram 2019 Logo.svg.png

Share: Twitter | Facebook

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee of the Open Invention Network. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

Whonix ™ is a derivative of and not affiliated with Debian. Debian is a registered trademark owned by Software in the Public Interest, Inc.

Whonix ™ is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.