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

Arch guide: https://wiki.archlinux.org/index.php/Firejail#Using_Firejail_by_Default ^[archive]

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 ^[archive] 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.

Comments[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 ^[archive] Git ^[archive]

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.

Security[edit]

Generally[edit]

Vincent43 ^[archive]:

There are two distinct scenarios:

1. app/service runs inside firejail sandbox

2. app/service runs outside firejail sandbox

Firejail significantly reduces attack surface for 1 (it may vary across different profiles) and increases attack surface for 2 (more or less). Everyone have to decide themselves what net attack surface impact is for them.

Granting access to firejail for untrusted local unprivileged user may be not good idea (this is scenario for which most of past cve were applicable).

The question is if today's desktop linux systems are multi-user focused (with some of them being untrusted). I heard many opinions from developers of projects like kernel or systemd stating that's not the case.

Yes, bublewrap has less additional attack surface for scenario 2 but merely installing bubblewrap does nothing for scenario 1 unless someone write special wrapper for it with profiles for many specific apps. Something like that, let's call it Firewrap or Bubblejail would be interesting, perhaps more secure solution than firejail but for now it doesn't exist.

madaidan:

If you want full priv esc, then the attacker could have exploited one of the sandbox escape vulnerabilities I listed above and then exploited another priv esc vulnerability in firejail once they're outside the sandbox.

Patrick paraphrasing madaidan (posted only here):

Care about scenario 2. Because an attacker could use a sandbox escape vulnerability. Then once outside the sandbox, follow-up with a privilege escalation vulnerability in firejail to gain root.

Vincent43:

Yes, however I consider scenario when malware author writes script that will compromise some app and then go for firejail as rather unlikely. 95+ systems won't have firejail installed. The situation would be different when they have unlimited time and tries like local users have. Also when someone gets arbitrary code execution then they already won even without root access. Most things that matter will be available freely inside home.

netblue30 ^[archive]:

The attack surface visible to somebody outside the sandbox is large.

Don't use this on enterprise servers, or any other multiuser system. Firejail was built for single-user desktops.

Patrick (posted only here):

Would firejail have helped against past attacks against users in the wild? Is that a useful question to ask?
How likely is it that firejail gets specifically targeted?

netblue30 ^[archive]: recommends AppArmor over firejail for Whonix.

CVE Annotated[edit]

source cvedetails ^[archive] / github discussion ^[archive]

underline added by Whonix ™.

CVE-2019-12589[edit]

cvedetails.com:

In Firejail before 0.9.60, seccomp filters are writable inside the jail, leading to a lack of intended seccomp restrictions for a process that is joined to the jail after a filter has been modified by an attacker.

Vincent43:

It makes seccomp ineffective in certain, rare circumstances. It doesn't add additional attack surface on system.

CVE-2019-12499[edit]

cvedetails.com

Firejail before 0.9.60 allows truncation (resizing to length 0) of the firejail binary on the host by running exploit code inside a firejail sandbox and having the sandbox terminated. To succeed, certain conditions need to be fulfilled: The jail (with the exploit code inside) needs to be started as root, and it also needs to be terminated as root from the host (either by stopping it ungracefully (e.g., SIGKILL), or by using the --shutdown control command). This is similar to CVE-2019-5736.

Vincent43:

It works only when firejail is run as root, again it doesn't add additional attack surface on system.

CVE-2017-5940[edit]

cvedetails.com

Firejail before 0.9.44.6 and 0.9.38.x LTS before 0.9.38.10 LTS does not comprehensively address dotfile cases during its attempt to prevent accessing user files with an euid of zero, which allows local users to conduct sandbox-escape attacks via vectors involving a symlink and the --private option. NOTE: this vulnerability exists because of an incomplete fix for CVE-2017-5180.

Vincent43:

Exploit need to be run outside sandbox

CVE-2017-5206[edit]

cvedetails.com

Firejail before 0.9.44.4, when running on a Linux kernel before 4.8, allows context-dependent attackers to bypass a seccomp-based sandbox protection mechanism via the --allow-debuggers argument.

Vincent43:

It makes seccomp ineffective in certain, rare circumstances. It doesn't add additional attack surface on system.

CVE-2017-5180[edit]

cvedetails.com

Firejail before 0.9.44.4 and 0.9.38.x LTS before 0.9.38.8 LTS does not consider the .Xauthority case during its attempt to prevent accessing user files with an euid of zero, which allows local users to conduct sandbox-escape attacks via vectors involving a symlink and the --private option.

Vincent43:

Exploit need to be run outside sandbox

CVE-2016-9016[edit]

cvedetails.com

Firejail 0.9.38.4 allows local users to execute arbitrary commands outside of the sandbox via a crafted TIOCSTI ioctl call.

Vincent43:

This is sandbox escape but It doesn't add additional attack surface on system. Bubblewrap was also affected and fixed it couple of months after firejail did ^[archive].

Misc[edit]

smitsohu ^[archive]:

The descriptions are misleading, unfortunately. You need to read the code and understand the vulnerabilities. There is no sandbox escape there (from the running sandbox), the primary problem is the privesc (edited).

Anyway, the thing is that there is little point to discuss Firejail version 0.9.38 or 0.9.44.
Firejail changes very fast, and what will be upcoming 0.9.62 has not so much to do with the early versions that were hit by these vulnerabilities. It would be very cool if we could discuss the present and not the past.

Status of Firejail in Whonix ™[edit]

https://forums.whonix.org/t/tor-browser-hardening-hardened-malloc-firejail-apparmor-vs-web-fingerprint/7851/54 ^[archive]

Written by Whonix ™ developer Patrick.

summary

I am not fully convinced, that firejail is bad.
Decided to no longer install firejail by default in Whonix ™ anyhow.

firejail security

Can’t rely too much on Daniel Micay as security export because he’s (often justified…) critical on “everything”… Could as well as give up and go home following that sentiment. Reference: https://forums.whonix.org/t/daniel-micay-quotes/8509 ^[archive]

Obviously asking on the firejail github repo will get biased responses.

Firejail developers might be bias towards firejail.

Simon McVittie (Debian, bubblewrap, dbus, flatpak maintainer): https://github.com/containers/bubblewrap/issues/266#issuecomment-386867656 ^[archive]

Bubblewrap developers might be bias towards bubblewrap.

Under the bias thesis, both candidates aren’t ideal expert opinions here on judging the security of each tool vs each other. Their input is valued nonetheless.

Tried to wrap my head around this issue. Made some notes here: ../Dev/Firejail#Security ^[archive]

Trying to come up with essential questions.

Would firejail have helped against past attacks against users in the wild ^[archive]? Is that a useful question to ask?
How likely is it that firejail gets specifically targeted?

Please keep expert opinions pro/contra firejail / bubblewrap / apparmor / etc. coming.

installation by default

Whonix ™ doesn’t enable any firejail / bubblewrap profiles for anything by default yet. All such profiles are opt-in.
Whonix ™ comes with some apparmor profiles by default. Those for its own software and those profiles maintained by Debian. Other profiles are opt-in.

Decided to no longer install firejail by default due to

the controversy,
higher attack surface without other advantage by default (no profiles enabled by default).

Currently Whonix ™ has a by default a higher attack surface (due to firejail installed by default) but no security advantages (not making use by default of any firejail profiles).

Firejail was only installed decided to become installed by default for better usability. To make writing firejail profiles easier. This could be undone since we did not get any new profiles anyhow.

At the moment, major attack surface realistically is the browser, Tor Browser. If hypothetically upstream, The Tor Project maintained a firejail profile, then I would think that the security advantages outweight the security disadvantages of it. Until in-the-wild attacks proof otherwise. That would be a reason to keep firejail installed by default.

SecBrowser ^[archive] depends on firejail and uses it by default. But SecBrowser isn’t Whonix. For SecBrowser I’ll keep firejail enabled by default until I am convinced that it does more harm than good against realistic attacks (what happened previously in-the-wild).

future reconsideration for re-installation of firejail

Anyone maintaining firejail profiles in Whonix ™ for software not developed by Whonix ™ wouldn’t be installed by default - same as for apparmor profiles.
Anyone maintaining firejail profiles in Whonix ™ for software developed by Whonix, and re-installation for firejail by default would be reconsidered.
Anyone maintaining firejail profiles in Debian, and re-installation for firejail by default would be reconsidered.