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

[kmk3]

(Offtopic)

@rusty-snake

s/thread model/threat model/

[amano-kenji]

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

But, the alternative is no firejail. I trust firejail more than webkit sandbox which still exposes everything in my file system to web browser.

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

You now have a 2.1 meter high wall. 😄

[curiosityseeker]

10 cm higher is not too bad 😅 But seriously, that ruleset should be vastly extended. I will probably create a new thread discussing such an extended ruleset.

Or do you think that the limitations of ABI v. 1 used in Firejail will allow just for another 10 cm gain?

[rusty-snake]

limitations of ABI v. 1 used in Firejail

Using only ABIv1 clearly limits possible restrictions introduced by later ABI version. And it limits compatibility because you can not move files. Every applications that needs to move files will not work.

will allow just for another 10 cm gain?

The one things is the applied ruleset, the other thing are the exposed commands. Enforcing stuff with landlock that is (or can) already be enforced by mounting noexec or ro gives virtually no more security¹ and is only "we use Landlock"-theatre. To bring landlock to its full power, you have to break out of thinking about filesystem restrictions in a mount-based way. We need to think of them in a LSM based way.

Crablock for example knows 6 relevant permission-groups for filesystem access (in context of LL ABIv1):

• execute files
• read files
• write files
• list directories
• manage (i.e. read, write, create, delete, rename, move, ...)
• unrestricted

Crabjail merges these permission-groups with the mount-based one and exposes them in a similar way. So instead of "Allow (anything) /foo/bar" you write "Allow read and execute access on /foo/bar".²

To bring this back to firejail, merging read on files and read on directories (for example) is a mount/dac based thinking that can be done but does not give full power. Splitting them allows one to write rulesets where an applications can read any file under /foo/bar if it knows the path but not to find files by using ls.

¹ a kernel bug in Landlock like the recent keyctl-bug is more likely than in the good old mount code.
² crabjail is deny-by-default

[curiosityseeker]

Hm. The idea was that - if something is able to bypass the browser sandbox and also namespace-based restrictions in Firejail - the hope is that Landlock-based restrictions (hopefully) cannot be bypassed. This may look redundant but I think that‘s a redundancy which makes sense. How is that „we use Landlock"-theatre?

[rusty-snake]

The idea was that - if something is able to bypass the browser sandbox and also namespace-based restrictions in Firejail - the hope is that Landlock-based restrictions (hopefully) cannot be bypassed.

The bypass will either be an exploit in the kernel or a to permissive sandbox policy. To effectively stop kernel exploits, you need to isolate the kernel (e.g. VMS). A to permissive sandbox policy (i.e. sockets, startup and config files, IPC, …) is independent of the implementation.

Do we know which sandbox escape vulnerabilities in the kernel of last years were technology specific (i.e. not code execution in the kernel).