Dev/Firejail

Kicksecure ™

Download

On Computer USB Installation Debian morph to Kicksecure Windows (VM) Linux (VM) Mac (VM) VirtualBox (VM) KVM (VM) Qubes (VM) More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

development notes on Firejail and other security isolation frameworks in Kicksecure

General Topics

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

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 --list and to reverse this action: firecfg --clean

• Tor Browser
  • To integrate with Firejail, the "https://git.schwanenlied.me/yawning/tor-firejail/src/master/start-tor-browser" 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
    • Kicksecure: 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).
    • Kicksecure for Qubes: One ~/.config/firejail modification per AppVM would not be great. Also modifications to /etc/firejail in Template 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: 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

• Firejail should probably get its own Kicksecure 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

• https://forums.whonix.org/t/firejail-seccomp-more-options-for-program-containment/1030

Comments

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

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

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

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

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

Generally

Vincent43:

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:

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: recommends AppArmor over firejail for Whonix.

CVE Annotated

source cvedetails / github discussion

underline added by Kicksecure.

CVE-2019-12589

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

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

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

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

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

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.

Misc

smitsohu:

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 Kicksecure

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

Written by Kicksecure developer Patrick.

summary

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

---

firejail security

Can’t rely too much on Daniel Micay as security expert 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

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

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: https://www.whonix.org/wiki/Dev/Firejail#Security

Trying to come up with essential questions.

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

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

---

installation by default

Kicksecure doesn’t enable any firejail / bubblewrap profiles for anything by default yet. All such profiles are opt-in.
Kicksecure 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 Kicksecure 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.

---

future reconsideration for re-installation of firejail

• Anyone maintaining firejail profiles in Kicksecure for software not developed by Kicksecure wouldn’t be installed by default - same as for apparmor profiles.
• Anyone maintaining firejail profiles in Kicksecure 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.

TODO

man firejail-users

/etc/firejail/firejail.users

Footnotes

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!