Jump to: navigation, search

Dev/Firejail

< 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
  • 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[2][3]

  • A short term workaround until the proposed upstreaming of start-tor-browser [4] 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.


Integration Roadmap[edit]

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


See Also[edit]

Comments[edit]

Add discussion points here.


Deprecated ideas:

  • 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." [5]

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

"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.[8]

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.

Footnotes[edit]

  1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822693
  2. https://git.schwanenlied.me/yawning/tor-firejail
  3. https://lists.torproject.org/pipermail/tor-dev/2016-May/010947.html
  4. https://trac.torproject.org/projects/tor/ticket/19055
  5. https://wiki.archlinux.org/index.php/Firejail
  6. https://phoronix.com/scan.php?page=news_item&px=KDE-XDG-App-Experimenting
  7. http://flatpak.org/faq.html
  8. https://github.com/flatpak/flatpak/issues/66#issuecomment-223213288

Random News:

Bored? Want to chat with other Whonix users? Join us in IRC chat (Webchat).


Impressum | Datenschutz | Haftungsausschluss

https | (forcing) onion
Share: Twitter | Facebook | Google+
This is a wiki. Want to improve this page? Help welcome, volunteer contributions are happily considered! See 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, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.