Does firejail improve the security of my system? thoughts by @rusty-snake

[rusty-snake]

Previous/related discussions:

• Does firejail worsen security? #3046
• Does changing $PATH affect the security? #3552
• The case for firejail over bubblewrap #4522
• "Warning: cannot find /var/run/utmp" but looks for "/dev/null/utmp" instead #4210 (comment)
• What would be THE answer to non-VM compartmentalization-based desktop linux security? #5779
• How strong is the Firejail sandbox? #6466

Related PRs:

• docs: mention risk of SUID binaries and also firejail-users(5) #5290

---

THIS IS MY OPINION

Virtually all the arguments against firejail can be summed up in "Firejail
worsens security by acting as a privilege escalation hole because it is complex
and requires to be SUID." We all know that complex means bugs and bugs in SUID
programs cause more damage. Normally we would be done here and could say "this
program worsens security". However, since firejail is a program that is
supposed to increase security, maybe the overall balance is positive (i.e. the
security gains outweigh the new risks introduced). But is the overall balance
actually positive or not? Well, it depends on your thread models.

Privacy Guides has a very good article about Thread Modeling (https://www.privacyguides.org/threat-modeling/)
that defines five questions:

1. What do I want to protect?
2. Who do I want to protect it from?
3. How likely is it that I will need to protect it?
4. How bad are the consequences if I fail?
5. How much trouble am I willing to go through to try to prevent potential consequences?

I will answer these questions for myself (a graphical Linux system used by only
one user) however, I think that these answers are at least roughly correct for
most of you.

1. What do I want to protect?

The Confidentiality and Integrity of my system. That includes that my password
and keys are kept secret, my emails private, my github account secure and my
pictures/documents/code/... are not being manipulated.

1.1. What do I not want to protect?

The Availability of my system because I break it myself more often than I am
even attacked.

The kernel and the root user. Although their integrity is a prerequisite for
the above points, it is not the goal. Meaning I scare remote>kernel>password
attacks but not remote>firefox>kernel attacks if remote>firefox>password is
possible too.

2. Who do I want to protect it from?

Cyber Crooks who loitering on the internet and preying on random victims.

2.1. Who do I not want to protect it from?

Intelligence and targeted attacks. If they are in your thread model
use Tails, Whonix or Qubes OS.

3. How likely is it that I will need to protect it?

Cyber Crooks usually attack Windows systems, IoT-the-s-stands-for-security-devices
and Servers.

Such attacks don't use unpublished zero-days. Instead they use publicly known
(and often patched) vulnerabilities or Social Engineering. Therefore install
updates! and don't follow "to install this cool program just curl | bash"
instructions.

4. How bad are the consequences if I fail?

It depends on the attack but one of the worsts would be that someone does criminal things and I am blamed for it.

5. How much trouble am I willing to go through to try to prevent potential consequences?

This is an important point, because you can have too much security. I could use

• Tails, however it has a lot restriction and make thing complicated. Too complicated most of the time.
• Qubes OS, however it has high hardware requirements.
• Bubblewrap, however I would need to write profiles (and even the concept of profiles)
  myself, compile seccomp filters myself, setup D-Bus filtering myself, do the desktop
  integration myself (TBH I did this for firejail) and know a lot of my system and
  the program I want to run. Except of a few experts no one of use can do this correct
  (and no you aren't an expert). You will either have a weak sandbox because you forgot
  things, don't know about things or made mistakes or you will have a strict sandbox, a
  too strict sandbox and give up sandboxing.
• an custom sandboxing program, however this has the same drawbacks a bubblewrap
• AppArmor/SELinux, however this is more complicated but if you have the knowledge, go for it.

Summary

I am worried that an attacker can execute commands with full user rights.
An attack who execute commands with full user rights is effectively already root.

https://xkcd.com/1200/

[TommyTran732]

This wasn't my main point in the PG discussion. I was comparing it to Flatpak. The problem with using SUID was just one thing I brought up.

The main reason I argued for Flatpak usage over Firejail is its usability (all Flatpak packages are confined by a set of permissions by default and the user can easily use a GUI like Flatseal to toggle those permissions), integration with the rest of the ecosystem (Portal, GNOME, etc). My ideal setup (especially for a new user who had just come to Linux) is Wayland + Pipewire API for audio + Flatpak (which, again, integrates nicely with Portal) + Flatseal. That way they have some what of a permission control system on their Linux computers. I just don't see how Firejail fits in. I also think modifying firejail profiles and making them would be easier for the user than just changing toggles in Flatseal. Firetools would have been nice if it could actually save the profile it creates for later use.

[crocket]

Firejail is a lot more flexible than flatpak if you want to do anything useful at low level.

How do you use piprewire for audio? Most applications don't support pipewire. I use ALSA currently.
I haven't tried piprewire's ALSA plugin because it might add too much latency to audio or crackle if CPU is overloaded.

[topimiettinen]

For xkcd-1200, Firejail could support using several UIDs (real, not subuids) under control of a main UID. This would of course need to be enabled at system configuration, not by an user. Then simple DAC controls (chmod 0700, groups) could be used to control which UID can access which files. Some folders could be shared (tradeoff of convenience vs. security). For example, Linux firewalls can use different rules based on the UID (NFT: meta skuid != 1000 drop).

Previous discussions in #3892, #208.

[matu3ba]

@topimiettinen What is the advantage to editing with visudo the sudoers file with NOPASSWD: /etc/myscripts/do-whatever to start the configured program? You need to setup the machanism for file sharing or copying between users anyway.

Also: If you want to automatize this brittle stuff, you end up adding the complexity of a full-blown user agent. And the advantage would only help for programs that can run as local user and not escalate to root, which is not too tricky with desktop complexity.
Or you would have them contained in the first place.

Regarding the information leakage: Most of (and all widespread) Linux Desktops are not designed with that in mind, which makes it unfeasible to aim for.

There may be hope, but I dont see a strategy to expand this yet. And hacks seem to be the essence of Linux.

[crocket]

If you like gobolinux, look into GNU Guix system, too.

[topimiettinen]

ssh localhost using authorized_keys is another option.

The advantage would be that Firejail could take over the UID and related home directory completely. The master version of data would be in the normal user's directory and the sub-UID directories would be just for setting up the stage.

GoboLinux seems to just rename the paths, like NixOS. I don't see much benefit from this, except maybe "security by obscurity". It could still mean that simple metasploit stuff, which expects to find commands in usual places, may fail.

Linux isn't perfect but the alternatives aren't either.

[topimiettinen]

I think there were also interesting discussions around BeEF (Browser Exploitation Framework), but I can't find it.

[SkewedZeppelin]

Weird. I know exactly the issue you mention, but I cannot find it at all! Tried a few ways too.

[rusty-snake]

GitHub hides it in search and in the list, maybe because the author is @ghost. Anyway here is it #4436.

[crocket]

For protection against executing arbitrary code with full user rights, firejail is great.
As I once wrote, the combined attack surface of programs that firejail restricts is more than million times larger than that of firejail.

I also think that it is far better than nothing against targeted attacks by intelligence agencies.

But, firejail's security can be greatly improved by splitting out privileged parts as separate binaries.
I think firejail will end up producing multiple binaries if it wants to split out privileged parts.

AppArmor can be combined with firejail, and I can introduce both firejail and AppArmor gradually per each application.

Firejail can protect users from targeted attacks to some degrees because most targeted attacks don't rely on exploits in SUID binaries or kernel. For example, firejail --net=none mpv can prevent mpv from fetching media metadata from a server run by an intelligence agency. Intelligence agencies insert their own servers into media metadata so that media players consult their servers for metadata. People usually use media players without tor, so they end up revealing their real IP address and thus their physical location to intelligence agencies. And then, they can send police officers to arrest political dissenters.

[rusty-snake]

That depends on the policy you use. Nothing stops you from doing so, but you are right that the policies used by e.g. Fedora run mostly all user programs unconfined.

[curiosityseeker]

That depends on the policy you use. Nothing stops you from doing so, but you are right that the policies used by e.g. Fedora run mostly all user programs unconfined.

Yeah, this was the post by SELinux pope Dan Walsh I had in mind. However, in Gentoo (Hardened?) it's done differently. And there is the SELinux sandbox, of course.

[curiosityseeker]

@smitsohu

Maybe there's a way to make profile transitions work. If I understand it right it involves an AppArmor profile for Firejail itself (the SUID Firejail) that allows everything. No restrictions whatsover.

Hm, it seems that this does not work. I created a profile which looks like this:

# Last Modified: Wed Oct 20 14:47:02 2021
abi <abi/3.0>,

include <tunables/global>

/usr/bin/firejail {
  capability chown,
  capability dac_override,
  capability dac_read_search,
  capability fowner,
  capability mknod,
  capability setgid,
  capability setpcap,
  capability setuid,
  capability sys_admin,
  capability sys_chroot,
  capability sys_ptrace,

  network inet dgram,
  network inet stream,
  network inet6 dgram,
  network inet6 stream,
  network netlink raw,
  network unix dgram,
  network unix seqpacket,
  network unix stream,

  signal receive set=exists peer=/usr/bin/firejail,
  signal receive set=kill peer=/usr/bin/firejail,
  signal receive set=term peer=/usr/bin/firejail,
  signal send set=exists peer=/usr/bin/firejail,
  signal send set=kill peer=/usr/bin/firejail,
  signal send set=term peer=/usr/bin/firejail,

  ptrace read peer=/usr/bin/firejail,
  ptrace readby peer=/usr/bin/firejail,
  ptrace readby peer=prelockd,
  ptrace trace peer=/usr/bin/firejail,
  
  / r,
  /** mrwlk,
  /** ux,

}

Further tests are necessary but right now it doesn't look as if something has changed.

[topimiettinen]

I don't understand what you mean because I haven't actually used apparmor or selinux. Can you say in plain english?

Firejail can confine Firefox by using a mount namespaces so that for example, it can only access ~/Downloads but no other files. But setting up the mounts so that Firefox can open pdfs by starting Okular would loosen the sandbox, because the mount sandbox in Firejail needs to be sum of both apps' needs. With AppArmor (and SELinux), it's possible to confine both programs separately, for example Okular doesn't need access to network but Firefox obviously does. Based on the comments above, AppArmor has problems when Firejail is also involved, but it's doable with SELinux. For me it's OK if Firefox can't execute anything, I can open the downloaded files without it.

[topimiettinen]

That depends on the policy you use. Nothing stops you from doing so, but you are right that the policies used by e.g. Fedora run mostly all user programs unconfined.

The first step to harden SELinux policy is to change from unconfined user unconfined_u to unprivileged user user_u (optionally also switch root to sysadm_u) and restorecon file systems. The next step is to fix "a few" bugs in policy. Still, TOMOYO doesn't have any policies readily available and AppArmor profiles are also pretty lacking, so nothing new here.

[dm17]

Wouldn't running browsers in docker or podman be even better?

[topimiettinen]

Docker etc. use the same technologies as Firejail: mount/PID/user/net namespaces, seccomp, capabilities etc. If they have cool ideas, maybe those could be used also in Firejail.

[dm17]

Relevant: https://crlf.link/log/entries/211008-1/

[rusty-snake]

If it is done right!, it can have the following benefits:

• a isolated network namespace (admittedly firejail has net eth1)
• a private base system
• runsc (aka gVisor)

[topimiettinen]

VM technology (gVisor or direct KVM) would be nice in Firejail. It would allow deep inspection of system call arguments without TOCTOUs, because it's possible to "stop the world" while doing so. Mangling the arguments would be also possible, which isn't allowed with seccomp.

[curiosityseeker]

Virtually all the arguments against firejail can be summed up in "Firejail worsens security by acting as a privilege escalation hole because it is complex and requires to be SUID." We all know that complex means bugs and bugs in SUID programs cause more damage. Normally we would be done here and could say "this program worsens security".

Shouldn't it be mentioned that the risk of Firejail being a SUID can be mitigated?

[crocket]

By the way, if intelligence agencies are your threat model, you should flash coreboot on a computer without CPU backdoors.
CPU backdoors can bypass all security measures.
https://freundschafter.com/research/system-alternatives-without-intel-me-iamt-and-amd-psp-secure-technology/

BadBIOS utilizes speakers and microphones as network interfaces because sound is a medium for wireless communication.

All of that cannot be blocked by virtual machines or firejail. Those highly privileged backdoors have direct access to RAM.

As long as CPU backdoors and other highly-privileged backdoors like BadBIOS remain as the lowest hanging fruits, finding exploits in firejail or virtual machines doesn't make much sense.

Intelligence agencies already got you by the balls with CPU backdoors and other highly privileged backdoors in UEFI and BIOS.

[dm17]

Right. But I don't know much about me_cleaner... The only way to verify lack of backdoors in these closed source firmwares is to bootstrap the CPU with open firmware... Which we can't do on any modern AMD or Intel CPUs - can you? Fastest AMD CPU without PSP is supposedly the Opteron? Still pretty old... :(

Another aspect of running with open firmware is being able to patch your own systems in the case of a cyber attack. A community could collaborate. In the case that you have to rely on AMD/Intel - the speed to react is way larger, the inability to have more people testing and looking through the code sucks, and the ability to turn off some 'network-enabled management engine' purposeful/accidental backdoor is vastly diminished.

I get what you're saying about the way they reveal things, but open firmware is the only verifiable way, isn't it?

[crocket]

Presence of AMD PSP seems detectable with some programs. There are programs that can analyze AMD PSP, but nobody has found a way to disable it.

[dm17]

Yep... And it seems Power10 will unfortunately have binary blobs until RaptorCS can get the help / resources to remove them somehow. They say it will be expensive. Power9 seems it will be decent for a while longer.

[crocket]

Power9 is expensive.

[amano-kenji]

The closest you can get to a computer without hardware backdoor is intel CPU computers from star labs, system76, and purism.

Their intel CPU computers come with coreboot that disables Intel ME during boot. They also stripped Intel ME down to the minimum size possible.