Sandboxing

Each Firefox child process runs inside an OS-level sandbox to limit damage if a renderer is compromised. The implementations live under security/sandbox/.

Per-platform back-ends

Platform	Mechanism	Source
Linux	seccomp-bpf + Linux namespaces (PID, NET, USER)	security/sandbox/linux/
macOS	sandbox-exec profiles + Mach service brokerage	security/sandbox/mac/
Windows	Chromium's sandbox library (vendored), AppContainer, low-integrity tokens	security/sandbox/win/
Android	SELinux + Android isolated process	(configured in mobile/android/)

Process types and policies

Different child processes get different sandboxes:

• Content — strictest; no direct network/file access; brokers I/O via IPC.
• GPU — needs GPU device access; sandbox tuned to allow that.
• RDD (media) — only the codecs needed.
• Socket — needs network access; everything else is locked down.
• Utility — multiple sub-kinds with tight per-purpose policies (audio, generic, …).

Levels are tunable for debugging:

• security.sandbox.content.level
• security.sandbox.gpu.level
• security.sandbox.socket.process.level
• security.sandbox.utility.level

Brokers

When sandboxed children need privileged operations (file open, font load, GPU device init), they call brokers in the parent or a higher-privileged sibling. See security/sandbox/chromium/ (vendored) and the per-platform brokers.

Anti-exploit hardening

Beyond sandboxing, Firefox applies:

• W^X memory — JIT pages are either writable or executable, not both simultaneously.
• CFI / CET — Control-flow integrity where supported.
• PageProtect in mozglue/ to mark sensitive structures read-only.
• MOZ_ASSERT_UNREACHABLE + crash on unexpected inputs.

Related

• Process model
• Security
• Fission