How strong is the Firejail sandbox?

[curiosityseeker]

In a German security forum I found this discussion about Bubblejail which expanded to a discussion about Firejail as well.

One participant writes (translated with DeepL):

I don't see a way to effectively sandbox browsers on Linux with bubblewrap alone. Either you allow the necessary syscalls required for the browser sandbox, and end up with an additional bubblewrap sandbox with known escapes, pretty useless so to speak, but at least it doesn't break browser sandboxing. Or you block them and make browser sandboxing and site isolation much worse, but this is not compensated for by the bubblewrapsandbox, so you end up with worse security than before.

Firejail basically has a similar problem as Bubblewrap, as both primarily rely on namespaces+chroot/pivot_root+seccomp, in addition to a few other features such as no-new-privileges. To prevent a relatively easy escape from the namespaces and chroots via a few syscalls, these must be blocked via Seccomp.

The problem is that this also includes the syscalls that are required to create the namespaces and chroots. So if you block them at Firejail/Bubblewrap/Flatpak level, the browser running in them can no longer use them to build the sandbox structure as intended. However, if you do not block them, the additional sandbox is not of much use, as there are known escapes for the namespaces and chroots.

I have installed Firejail as a test and it does not actually block the FF sandbox. The necessary syscalls are allowed, but nothing significant in terms of syscalls is blocked, which makes the sandbox correspondingly weak.

The Seccomp filter blocks almost nothing and the generic Apparmor profile is also extremely lax. This leaves the namespaces and chrooting, which are not supported by any significant Seccomp filters. The attack surface is huge compared to the browser-internal sandbox. There is a whole range of syscalls that are blocked in most namespace-based sandboxes and containers, as they offer high potential for escapes. See Seccomp filters from Flatpak, Podman, Docker, etc. which all contain a similar base set.

As an example, the availability of subnamespace syscalls such as unshare and chroot syscalls such as chroot should be viewed very critically. Although these are necessary for the browser sandbox and therefore it is good that they are not blocked, this does not change the fact that it weakens the Firejail sandbox. The availability of unprivileged user namespaces within the sandbox allows an attacker access to part of the kernel attack surface. I don't think anyone seriously thinks that an attacker savvy enough for an RCE and SBX on a browser is going to be stopped by a lax Firejail sandbox.

Comments by the developers would be highly appreciated.
@netblue30 @rusty-snake

[rusty-snake]

I read the most of the thread (I skimmed through some of the comments). I will not correct all the half-knowledge, only the selected quotes and some general clarifications.

Security is not black and width, there's security and security. If we talk about user-to-root security (e.g. "firejail is suid") we talk about a different thread model than sandbox-to-user (i.e. sandbox escape). I already wrote in #4601 about that. It's three years old, but the https://xkcd.com/1200/ summary still applies.

How strong is the Firejail sandbox?

Depends ...

• ... on the profile.
• ... on the thread model.

If we assume a xkcd 1200 thread model (there are different ones! but it is a common one), ~50% of the profiles have a (very) weak profile.
_{This number does not reflect how common these profiles are.
i.e. written 5 years ago by one person vs. used by the most developers and constantly improved;
only packaged in AUR and 100 downloads vs. preinstalled in debian, ubuntu, fedora, ...}

I don't see a way to effectively sandbox browsers on Linux with bubblewrap alone.

Right, don't use bubblewrap, use a high-level tool like bubblejail or flatpak.

Or you block them and make browser sandboxing and site isolation much worse, [...], so you end up with worse security than before.

I have been preaching for years to people who think --no-sandbox, WEBKIT_FORCE_SANDBOX=0 and others are a good idea

Either you allow the necessary syscalls required for the browser sandbox, and end up with an
additional bubblewrap sandbox with known escapes,

seccomp is used to reduce (kernel) attack surface and not to create sandbox policies¹. You can use it to enforce sandbox policies, but you can also enforce them with different technologies.

Right now I can not think of any syscall that can be used to escape the sandbox². Under one condition: you keep root out of your sandbox (nonewprivs, caps.drop all, noroot). Properly sandboxing a program running as real root is much more difficult (=likely to fail), see rootfull docker, podman, ….

_{¹ by the usage in firejail, other sandboxes create and enforce policies with it (e.g. syd) or require it (yet) because of their thread model (see flatpak).
² not counting kernel vulnerabilities or things like general IO syscalls. If you can escape by writing to a file/socket, write access to this file/socket is the problem and not the syscalls used to write.}

Firejail basically has a similar problem as Bubblewrap, as both primarily rely on namespaces+chroot/pivot_root+seccomp, in addition to a few other features such as no-new-privileges. To prevent a relatively easy escape from the namespaces and chroots via a few syscalls, these must be blocked via Seccomp.

If the author could share their knowledge how to escape "namespaces and chroots via a few syscalls" assuming an empty capability bounding set. And what syscalsl that are. I would be interested (also for my own projects).

_{Again, access to files/sockets does not count. A weak firesystem policy does not make namespaces for itself insecure. A lot technologies used for sandboxing only work well when used together.}

The problem is that this also includes the syscalls that are required to create the namespaces and chroots.

No

https://www.kuketz-forum.de/t/erfahrungen-mit-bubblejail-gui-fuer-bubblewrap/9378/10 and "I have installed Firejail as a test and it does not actually block the FF sandbox."

as there are known escapes for the namespaces and chroots.

See above.

The necessary syscalls are allowed, but nothing significant in terms of syscalls is blocked, which makes the sandbox correspondingly weak.

The blacklist approach on seccomp used by the most tools (firejail, bubblejail, ...) is used to reduce kernel attack surface. Every blocked syscall is a win then.
Using a allowlist approach for a profile that should work for the average DAU from Debian to Arch, with Intel, AMD, Nvidia, nouveau and common native messaging such as keepassxc-browser will not be much stricter.

I have to admit that the defined syscall groups are horrible out of date for newer (5.x, 6.x) kernels.

The Seccomp filter blocks almost nothing

See above.

There is a whole range of syscalls that are blocked in most namespace-based sandboxes and containers, as they offer high potential for escapes. See Seccomp filters from Flatpak, Podman, Docker,

EVER LOOKED AT THE SYSCALL FILTERS OF THE LISTED PROJECTS?

firejail block a few times more syscalls that flatpak by default.

_{Both have much space to improve their syscall filters. For crabjail I also still examine how to create good syscall filters}

I don't think anyone seriously thinks that an attacker savvy enough for an RCE and SBX on a browser is going to be stopped by a lax Firejail sandbox.

To some extend true.

You could argument that the attacker needs to be aware of firejail i.e the "I've wrote my on OS, it's absolutely secure because there is no malware for it written yet" security. But that's not the point, if you have full code execution inside the sandbox, you can escape from I guess around 80-90% of the profiles. If you only have a limited vulnerability (e.g. arbitrary file truncation) or mass-targeting attacker (e.g. ransomware with only 1% successful entered systems) firejail can safe your ass.
_{For crabjail I try to drastically lower these numbers for the high risk focused jails.}

[rusty-snake]

I believe firejail can block easy ways for web browsers to scan files.

Exactly

Some people succeeded in inserting backdoors

They could also succeed in inserting a backdoor into firejail. I don't see why firejail should be more trustworthy and/or trusted than Firefox.

[amano-kenji]

firejail is far smaller than firefox. If I use firejail, I have to only trust firejail. If I trust web browsers, the attack surface becomes at least 2,000 times larger. Each web browser's codebase is at least 1,000 times larger than that of firejail. I use many web browsers on my computer for browser fingerprint isolation.

If I have profiles for every user application I use, I only have to trust firejail and nothing else. It's about reducing the attack surface.

Plus, mozilla started espousing authoritarian mindset and adding more surveillance features to firefox. As far as I know, firejail is not owned by woke capital which increases authritarianism in anything it touches. Google is controlled by woke capital. Google android was trying to report people's location information to government. Mozilla is funded a lot by google. Google has control over who's hired in mozilla.

I trust the mindset behind firejail more than the mindset behind firefox. The codebase is smaller, and the mindset is better.

I want to at least make it difficult for backdoors to gain unbridled access to my system.

[valoq]

Some people succeeded in inserting backdoors into linux kernel in plain sight. The backdoor was discovered later and removed.

And you can provide a source for that? The only thing close to this would be some researchers trying this and it wasnt even nearly as close as the xz case which shows clearly what kind of expertise is required to hide a backdoor in open source code and it way beyond any expertise required to overcome userspace isolation like firejail provides.

Browsers are as complex as linux kernel. Some people might have inserted backdoors somewhere.

And if they did, firejail wont help prevent that. Why would someone who manages to built a backdoor in a popular open source project not use a kernel exploit to gain full system privileges? That would be required anyway to hide malicious payloads. And even if firejail worked, it would still be pointless as browsers themselves represent https://xkcd.com/1200/
Nearly everything you do, is managed by the browser. That theoretical backdoor can still read your credit card information, see/manipulate everything you do on the web, record all login credentials but somehow you would feel safer because it cant access the files that most likely were once downloaded by the browser anyway? This is a prime example of security theater.
Its also the reason why internal browser sandbox isolate every single tab from each other, so a successful compromise through a malicious website will not be able to gain access to other tabs and their respected data. A theoretical perfect firejail sandbox would not even get close to 1% of the isolation that modern browsers archive. Use some hardening guide to reduce firefox most significant attack vectors and you have gained a lot more then any firejail like sandbox ever could come close to.

If firejail can't block user applications from accessing my files, why does it exist in the first place?

Antivirus products exist too, even though they do more harm then good. Misconceptions about security are very common.
If I wanted to argue in favor of firejail, you could potentially gain some benefits from isolation applications that do not have build in process isolation, though the suid nature of firejail defeats that benefit many times over in my opinion.

[amano-kenji]

• I don't expect firejail to protect me from kernel exploits.
• Not all backdoors are kernel exploits. For example, google android keyboard just sends keys to google. Microsoft windows tried many times to send screenshots to microsoft. None of them required kernel exploits. Backdoors are mostly plain spywares because most people don't really care much about security. Most backdoors try to pick low-hanging fruits. Mozilla could just try to slip some sort of filesystem scan into firefox.
• Nothing can prevent web browsers from leaking our private information entered inside the web browsers, but firejail is better than nothing.
• Most of my sensitive information is on my hard disk, and I use many web browsers for browser isolation. I use a specific browser for my government identity and other browsers for pseudonymous identities. Most of my web browsers don't keep cookies and site data.
  • Preventing file system access is more important than preventing cross-tab access. When I do sensitive things, I don't keep other tabs open.
• Firejail can be modified to work with bubblewrap sandbox in web browsers.

[amano-kenji]

And, javascript malwares aren't just going to gain information from other tabs if there is no bubblewrap sandbox.

Each tab is a separate process. Without some sort of exploit, you can't just escape a tab.

Web APIs aren't just going to let malwares access other tabs.

But, if a web browser is deliberately backdoored to allow cross-tab information sharing, then cross-tab backdoors could ignore bubblewrap.

[curiosityseeker]

@rusty-snake Thanks a lot for your reply! Very instructive!

I have to admit that the defined syscall groups are horrible out of date for newer (5.x, 6.x) kernels.

According to /usr/share/doc/firejail/syscalls.txt the default-group is defined as:

@default=@clock,@cpu-emulation,@debug,@module,@mount,@obsolete,@raw-io,@reboot,@swap,open_by_handle_at,name_to_handle_at,ioprio_set,ni_syscall,syslog,fanotify_init,add_key,request_key,mbind,migrate_pages,move_pages,keyctl,io_setup,io_destroy,io_getevents,io_submit,io_cancel,remap_file_pages,set_mempolicyvmsplice,userfaultfd,acct,bpf,nfsservctl,setdomainname,sethostname,vhangup

Which enhancements would you suggest?

[rusty-snake]

Modifying @default needs to be done careful.

• 3. from seccomp groups (next round) #3106
• update obsolete syscalls
• add new syscalls from new kernels
  • You can not build an seccomp.keep (i.e. allowlist) a filter that allows the program to use Landlock.
  • seccomp.drop @mount allows you to remount rw,suid,dev,exec.
  • ...

[curiosityseeker]

What about io_uring? It‘s not mentioned in syscalls.txt at all.

[rusty-snake]

firejail/etc/templates/syscalls.txt

Line 30 in 897f12d

@aio=io_cancel,io_destroy,io_getevents,io_pgetevents,io_setup,io_submit,io_uring_enter,io_uring_register,io_uring_setup

There is no io_uring syscall, the io_uring interface consists of three syscalls.

Setting sysctl kernel/io_uring_disabled >= 1 is generally good.

[valoq]

This is an interesting discussion and I would like to add some thoughts as well.

As @rusty-snake has already pointed out much of this comes down to the threat model you have but there are some details between the different tools that should be explained in more details to allow for a better picture.

When designing or adding security measures, one of the fundamental question is about how much benefit do you gain for what costs in light of your threat model. Every measure takes time and resources and this is especially true for measures done by individual administrators (unlike measures build into a system by upstream developers which are build and maintained once)
The first question I would therefore ask is whether the "security enhancement" you select can objectively reduce the risks that your threat model pictures or if there is even additional risk that is introduced by that measure. Famous example are anti malware tools on windows, which run highly dangerous code in kernel space, leading to a highly increased attack surface #CrowdStrike

Firejails use of suid and especially the way it never drops these privileges effectively #510 #3046 is one concern that lead me to stop contributing to firejail and look for alternatives years ago and it looks like it is still valid today. There have been at least 100 18 vulnerabilities in firejail (most of which privilege escalation) which would (for the most part) not exist if it was not for the use of suid https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=firejail&search_type=all&isCpeNameSearch=false .
I still believe firejail to be an interesting project that has taught me and likely many other valuable insights about process isolation on linux but I would not recommend its use on production systems. In comparison the approach taken by bubblewrap (and anything build on top of it) is a lot more sane as there is no additional privilege that can be exploited and it is also a fairly small code base that is easy to audit.

The next question is what we gain for which effort and inconveniences. In my experience no manual sandbox tooling is without drawbacks as there are always compromises to make and new individual use cases that get in the way of any profile build for the average user. That may be fine though if we get some solid risk reduction in return, so lets look at the potential risks first:

Threat model A)
The average system that may or may not be part of a critical infrastructure but that is not targeted individually or that is targeted only by opportunistic adversaries.
One example for malware relevant for this threat model could be the recently discovered Perfctl
The tldr; It targets common misconfiguration (a huge collection) and hides very well once it infects a system, basically requiring forensic tools to discover it.
Protection against this is a very realistic objective and sandboxing as discussed here can be a vital part of it, since this kind of malware does not use sophisticated exploits but rather known vulnerabilities in user space applications.

Threat model B)
Any system that may be targeted by a more sophisticated adversary with a budget, which includes a wide area of critical infrastructure systems from water treatment systems to some random 3 person company that just so happens to supply a government facility with services. This is the threat model that faces malware like Pegasus and other sophisticated tools that use zero day exploits.
Here we are not exclusively talking about Stuxnet level attacks where government agencies use every possible attack vector to overcome even air gapped perimeters. This is commercial stuff that almost always targets the kernel (syscalls) and not the userspace environment.
And sometimes these zero day exploits are also leaked and used against anyone not patching fast enough even without being a target deserving of attention.
Just recently firefox had a 0-day https://blog.mozilla.org/security/2024/10/11/behind-the-scenes-fixing-an-in-the-wild-firefox-exploit/ which was actively used against the tor browser.

Ignoring the details and differences between the available tools and considering all of firejail, bubblewrap, flatpak, crabjail etc as isolation tools that are intended to address the issue depicted by xkcd 1200, they can all provide quite similar benefits while also including common drawbacks.

The benefits are the isolation of userspace resources (as in user files) and IPC features that would allow sandbox escape.
The shortcomings they all have in common is that they miss the more serious attack surface of the kernel API and there isn't really much to be done here to change this. While syscalls can be filtered by all of these tools, they also still need to allow all the syscalls that are required by the target applications, which is usually the majority of the available attack surface.

This leads to the conclusion that we can use these sandboxing tools to try to address Thread Model A) but it would be self deception to believe it will help anything at all against Threat Model B)

While this could be the end of the discussion, there is another approach that does address both threat models and which is build into modern browsers. That is what google described a decade ago as a "broker architecture sandbox" and which is build into the protected software itself. I believe openssh was actually the first to implement this in 2003 and there is a paper about it somewhere describing it in detail. In essence it splits the application process in two parts and does all the dangerous things in a child process that does not get any access at all. Read that as in 0 syscalls and 0 file access. All the resources and communication this child process needs is handled by the broker (parent) process and while this API between the two process can still include vulnerabilities that trick the broker into passing on unwanted permissions, it has lead to significant improvements and skyrocketing exploit prices for browser exploits (a good indicator of a security measures effect I would argue).

And now we need to ask again what is gained by using the above mentioned sandbox tools on applications like firefox that use this broker architecture to isolate every single browser tab and not just the entire application process.
Recently firefox users running the browser in bubblewrap (or any tool that restricts user namespaces) received this warning

I have yet to find a detailed analysis about how relevant the reduction in process isolation is when firefox is run like this but it is obviously not good. And as I have already pointed out, the isolation provided by the sandbox tools above is not a substitute for the internal process sandbox of firefox, it is a far cry actually.

And now to the last question to ask when looking at the sandbox tools above: What do we gain from running firefox in firejail/bubblewrap/etc. compared to running firefox without it. The isolation we build with these tools is what I would describe as a solid brick wall that will keep the neighbors dog at bay and certainly helps to prevent unwanted visitors. But when we run firefox inside it, there is already the internal sandbox that would be more akin to a bunkers blast doors that may protect against an indirect nuclear blast. And now we go ahead and put a brick wall behind the blast doors... Who are we kidding here?

To address a xkcd 1200 thread model we can use any of the sandbox tools discussed here but there is no use case to use it with applications that already implement far superior process isolation internally. Even worse, we may end up reducing the isolation features like described in the mozilla help page above.

Personally I believe that more development efforts need to be invested into building real process isolation into high risk applications, things like vlc, libreoffice and any application that would touch files from untrusted sources like the net. And we do not even need highly controversial features like linux namespaces for this as there are quite solid and easy to implement alternatives like landlock available. And for more complete process isolation like browsers use there are projects like sandboxed-api that help to build broker architecture isolation and completely isolate the kernel syscalls from dangerous parsing child processes.

There is also this upcoming project that may be a good starting point to consolidate efforts for linux sandbox implementations.

In the meantime there may be good reason to use the sandbox tools above to isolate some application that lack this internal privilege separation, however I am not sure why we do not use the mandatory access control features that linux has come with for decades.
There is an active project maintaining apparmor profiles that does the same and using the new upcoming userns feature that allows the use of user namespaces for confined process only (as the mozilla page also mentioned) there is at least no reduction in internal isolation that results from using this, even if the effective security gain for firefox would realistically still be zero. It makes the configuration of profiles a lot more easy at least, which is why I ended up there after extensively using and experimenting every other tools mentioned above.

[rusty-snake]

There have been about 100 vulnerabilities in firejail (most of which privilege escalation) [...] https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3&keyword=Firejail .

Wrong number because of wrong search. This is the list of "products", one entry for each firejail "product" (=version). The "View CVEs" on the overall "product" finds 11 which is factor 10 of and a bit to low (compare https://firejail.wordpress.com/download-2/cve-status/).

Searching with https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=firejail&search_type=all&isCpeNameSearch=false lists 18 which is factor 5 of and a reasonable number.

[rusty-snake]

The shortcomings they all have in common is that they miss the more serious attack surface of the kernel API and there isn't really much to be done here to change this. While syscalls can be filtered by all of these tools, they also still need to allow all the syscalls that are required by the target applications, which is usually the majority of the available attack surface.

For reference, projects like Qubes OS (VM), Kata Containers (VM), gVisor (Application Kernel) or syd (Unikernel) try to defeat this.

This leads to the conclusion that we can use these sandboxing tools to try to address Thread Model A) but it would be self deception to believe it will help anything at all against Threat Model B)

👍 👍 👍

That is what google described a decade ago as a "broker architecture sandbox" and which is build into the protected software itself.

The sandbox of firejail/bubblewrap/... is what I call "wrapper sandbox". A "broker architecture sandbox" is far more secure as it can isolate the high-risk task to virtually nothing. However, it needs to be "build into the software itself" and can not be implemented with static permissions (e.g. mounts, seccomp-bpf ret allow or errno/kill, ...). "wrapper sandboxes" on the other hand can be applied afterwards. syd tries to be a wrapping broker which is an interesting approach.

I have yet to find a detailed analysis about how relevant the reduction in process isolation is when firefox is run like this but it is obviously not good. And as I have already pointed out, the isolation provided by the sandbox tools above is not a substitute for the internal process sandbox of firefox, it is a far cry actually.

👍 👍 👍

Thanks, for years I try to tell people to not turn off internal sandboxes to be able to run those programs in a holey firejail sandbox.

[valoq]

Searching with https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=firejail&search_type=all&isCpeNameSearch=false lists 18 which is factor 5 of and a reasonable number.

Right, thanks for pointing this out. I will correct that in the text.

[curiosityseeker]

I'm far from being an expert in this area. I agree that turning off the built-in sandbox in browsers is a very bad idea. But I'm not sure that we don't gain anything from running a browser with, e.g., Firejail.

As far as I understand it, there is still the risk of a sandbox escape via IPC. And there have been corresponding weaknesses and attacks in the past (example). In my understanding a "wrapper sandbox" (as @rusty-snake calls it) would protect against such an attack. Please correct me if I'm wrong.

That said, I'm using the apparmor.d project and am running Firefox with the profile from that project in combination with firejail-git with Landlock enabled.

FWIW, these are my landlock rules in firefox.local:

landlock.enforce

landlock.fs.write ${HOME}/.cache/mozilla/firefox
landlock.fs.write ${HOME}/.mozilla
landlock.fs.write ${HOME}/.local/share/pki
landlock.fs.write ${HOME}/.pki
landlock.fs.write ${HOME}/.cache/mesa_shader_cache
landlock.fs.write ${HOME}/.cache/mesa_shader_cache_db
ignore landlock.fs.write ${HOME}
landlock.fs.write ${DOWNLOADS}
landlock.fs.write ${RUNUSER}/*firefox*
landlock.fs.write ${RUNUSER}/psd/*firefox*
landlock.fs.execute /usr/lib/firefox
landlock.fs.execute /usr/bin/bash,/usr/bin/dbus-launch,/usr/bin/dbus-send,/usr/bin/env,/usr/bin/firefox,/usr/bin/sh,/usr/bin/which,/usr/bin/keepassxc-proxy
ignore landlock.fs.execute /usr/bin
ignore landlock.fs.execute /usr/lib
ignore landlock.fs.execute /usr/local/bin
ignore landlock.fs.execute ${HOME}/bin
ignore landlock.fs.execute /usr/local/games
ignore landlock.fs.execute /opt
include landlock-common.inc

[rusty-snake]

The kernel exploits are use-after-free, doublefree, race conditions, ...

The most syscalls do not operate on files. An if a exploit needs a file it does not matter which file, just a file. Protecting files is user-space protection/isolation.

What LL can do here is to restrict ioctls and access to "special files".

[topimiettinen]

There are lots of methods to block access to parts of the file system: simple permissions (DAC), MAC like LL, SELinux or Apparmor, and mount namespaces as used by Firejail. These don't help to protect the kernel itself (except perhaps in a limited sense for kernel ABI file systems like /proc, /sys or /dev). To protect the kernel, something like seccomp or VM to filter the system calls is needed.

There are other important elements that should be controlled besides files, like access to network. Landlock isn't very advanced in this area (yet).

[curiosityseeker]

There are lots of methods to block access to parts of the file system: simple permissions (DAC), MAC like LL, SELinux or Apparmor, and mount namespaces as used by Firejail. These don't help to protect the kernel itself (except perhaps in a limited sense for kernel ABI file systems like /proc, /sys or /dev).

Thanks! This is what I was thinking about. Could you specify where those limitations are? Or suggest some documentation where this is detailed?

[rusty-snake]

Could you specify where those limitations are?

The majority of the kernel attack surface is not in API filesystem's.

[topimiettinen]

Thanks! This is what I was thinking about. Could you specify where those limitations are? Or suggest some documentation where this is detailed?

There's for example Netlink socket interface which can be used to talk to various kernel subsystems.