Learn Seccomp - Seccomp in Sandboxing Projects

#Introduction

In episode 18 you measured seccomp's cost and found that for a good profile, the overhead is barely visible. That's why seccomp is the favorite layer in the world's most serious sandboxing projects. Episode 19 is a field trip: we dissect how Chromium, gVisor, Firecracker, Landlock, and QEMU use seccomp — then close with practical guidance on choosing between seccomp, a full sandbox, or a virtual machine.

You'll see one common thread across all the cases: no project relies on seccomp alone. seccomp is always one layer among many, and the real power comes precisely from that combination.

#Chromium: Seccomp in the Sandbox Pyramid

Chromium is the most massive real-world use of seccomp-bpf. The renderer process — which handles HTML, JavaScript, and untrusted web content — runs inside a layered sandbox:

• Seccomp-bpf restricts the syscalls the renderer process may perform to a very small subset needed for rendering and IPC communication.
• Namespaces isolate the filesystem and processes, so the renderer can't see the host.
• Rlimit and cgroups limit memory and CPU consumption.
• A narrow IPC channel is the only communication path to the parent process.

The design idea is spot-on: each layer catches what might escape another. seccomp works here as the innermost gate — if an exploit succeeds, it still faces a syscall wall with only a handful of doors. Chromium maintains a list of allowed syscalls per platform and continuously updates it from crash and bug reports — a pattern you'll meet again in episode 20 as policy-as-code.

#gVisor: A Kernel in User Space

gVisor, run through the runsc OCI runtime, takes a different approach. Applications inside it never call the host kernel at all: every syscall is intercepted and reimplemented by Sentry, a "kernel" written in Go running in user space. The application gets the illusion of a normal kernel, but the host kernel's attack surface is never touched.

What's interesting for our story: seccomp is still there, but at a different layer. Sentry itself is restricted by seccomp to the small number of host syscalls it actually needs. In other words, seccomp cages the user-space kernel itself — the last line of defense if there's a bug in Sentry's implementation.

When to use gVisor? When untrusted code must run on a multi-tenant machine without virtual machine overhead. The price is performance: for some workloads, overhead can reach 10–40 percent — a reasonable trade-off for isolation this strong.

#Firecracker: A Small, Strict VMM

Firecracker is a virtual machine monitor (VMM) designed for microVMs without memory and startup weight. Each microVM has its own VMM process, and that process is the target of seccomp.

Firecracker applies a very strict seccomp filter: only a few dozen host syscalls are allowed, far fewer than a normal operating system needs. The goal is simple — if a bug occurs in virtual device emulation, dangerous host syscalls are already blocked first. Firecracker also adds a jailer that locks down directories, users, and cgroups, making seccomp one part of a "box within a box".

#Landlock and Seccomp: Complementary, Not Competing

Landlock is a path-based Linux Security Module available since kernel 5.13. It restricts filesystem access — for example "this process may only read /var/www and write /var/log/myapp" — without requiring root and without complicated label configuration.

The difference from seccomp is clear: seccomp restricts syscalls, Landlock restricts the filesystem objects that can be reached. Combining both is very powerful: seccomp blocks dangerous syscalls, Landlock locks down the filesystem areas that may be accessed. A real case in point: a web server that may only read certain directories, write to its own log, and touch nothing outside — all without running the application as root.

grep Seccomp /proc/<pid>/status

The command above — grep Seccomp /proc/<pid>/status' — is the fastest way to confirm a filter is truly installed on your production processes.

#QEMU: Sandbox for the Virtual Machine Monitor

QEMU also applies seccomp, but for the same reason as Firecracker: protecting the host from the VMM process itself. The -sandbox option activates a filter restricting the syscalls the QEMU process may call:

qemu-system-x86_64 -sandbox on,obsolete=deny -m 1024 -hda disk.img

If an exploit in device emulation manages to take over the QEMU process, it only finds a very short syscall list — not the entire host kernel surface. Same approach, different context: a VMM as small as Firecracker or as large as QEMU both consider seccomp a worthwhile cost.

#Practice: Choosing the Right Layer

Just like choosing a mode of transport, the sandbox choice depends on what's being carried and how dangerous the passengers are.

The short guideline:

• Use seccomp when the application is well known and you just want to trim the attack surface — this is the default pattern in containers.
• Add Landlock or capabilities when the application is partially trusted, such as a server processing user input.
• Move up to gVisor when the code is truly untrusted, like plugins or other users' code.
• Choose a virtual machine when isolation must be absolute, memory and startup aren't a concern, or regulations demand a hard boundary between tenants.

#Combining Layers: Defense in Depth

The best layer isn't one mechanism, but all of them in sequence:

kernel host
  -> seccomp          blocks dangerous syscalls
  -> capabilities     trims root privileges
  -> Landlock/AppArmor locks filesystem access
  -> namespaces       isolates resources
  -> read-only filesystem  makes persistence harder
  -> application

Each layer catches mistakes the layer below might miss. This is the heart of defense in depth you've seen since episode 12 on combining seccomp and capabilities — episode 19 extends it across the whole ecosystem.

#Conclusion

In this episode 19 you saw seccomp working on a real battlefield. Chromium uses it as the innermost gate of its sandbox pyramid; gVisor cages its own user-space kernel; Firecracker limits the VMM to a few dozen syscalls; Landlock complements it in the filesystem domain; and QEMU uses the same pattern to protect the host.

Key points to take with you:

• seccomp is always part of a combination, never the only fortress.
• Chromium: the syscall list is curated from real reports and continuously updated.
• gVisor: syscalls are intercepted in user space, and seccomp cages Sentry.
• Firecracker and QEMU: seccomp protects the host from a compromised VMM.
• Landlock restricts the filesystem, seccomp restricts syscalls — they complement each other.
• Choosing seccomp, a full sandbox, or a VM follows the degree of distrust toward the code.

In the next episode 20 we automate all of it: seccomp as policy-as-code, strace-based generators, CI validation, and staged rollout from LOG to ENFORCE. See you then!