Skip to content

CONCEPT Cited by 1 source

Syscall allowlist

A syscall allowlist is the policy artefact that names the set of system calls a program is permitted to issue after entering a sandboxed mode. It is the thing seccomp enforces (concepts/seccomp) — separable because the allowlist is a design decision with its own engineering properties independent of the seccomp-bpf mechanism that applies it.

(Source: sources/2026-04-21-figma-server-side-sandboxing-containers-and-seccomp)

Why it's a design artefact in its own right

Every entry on the allowlist is a conscious trade-off:

  • Smaller allowlist = smaller kernel attack surface; a compromised workload has fewer kernel codepaths to reach.
  • Larger allowlist = broader program compatibility; more libraries and language runtimes work without rewriting.

Figma's framing: "every incremental increase in allowed system calls results in extra kernel attack surface to consider." The allowlist is therefore curated, not derived from program behaviour.

How the allowlist is usually built

Two practical approaches:

  1. A-priori enumeration — read the source, list syscalls the program can make. Only feasible for small, source-modifiable programs.
  2. Empirical observation — run the program under strace "on a representative corpus of inputs to exercise all possible codepaths", collect the union. This is typical for complex codebases.

The empirical path carries an inherent risk: codepaths not hit in the observation corpus are missed — and seccomp kills the process the first time production traffic hits one. Figma: "we hit very rare codepaths in the complex RenderServer codebase — which serves user traffic at large scale — that we didn't encounter during testing or internal use."

Brittleness failure modes

Sources of allowlist drift that trip seccomp in production:

  • Library / framework upgrades — new syscalls from a transitive dependency.
  • Language-runtime changes — JVM / Go / Python each have their own syscall patterns; upgrading a runtime version can introduce new calls.
  • Architectural difference between test and prod — ARM vs x86 glibc implementations call different syscalls for the same library function.
  • New program features — each feature PR is a potential allowlist-break.
  • Rare codepaths — as above.
  • Actual exploitation — a successful attacker trying a syscall that happens to be blocked.

Kernel logging on a seccomp kill is minimal: which syscall, which PID — and nothing else. Debugging requires reproducing the offending codepath, which is often the hard part.

Good CI practice

Figma: "Good continuous integration (CI) testing for seccomp can help catch some but not all problems like this early." The allowlist should be tested with the same breadth as any other configuration artefact; representative-corpus strace runs should be part of the release gate.

The narrowest documented allowlist

For "pure compute" workloads Figma restricts programs to:

  • Writing output to already-open file descriptors.
  • Exiting.
  • Allocating memory.
  • Fetching current time.

Explicitly excludes:

  • Filesystem operations (openat et al.).
  • Network / socket management.
  • Keychain.

This narrow allowlist is only possible because the program is engineered to not need those capabilities after the sandbox lands — either because it was always pure-compute, or because it was refactored so all dangerous syscalls happen before the sandbox is entered.

The historical anchor: original 1997 seccomp

The first seccomp shipped with a fixed allowlist of four: read, write, exit, sigreturn. That set is insufficient for almost any real program — no memory allocation, no time, no output to new files. seccomp-bpf replaced the fixed allowlist with programmable filters, but the "truly minimal" mental model still comes from that 1997 starting point.

Seen in

Last updated · 200 distilled / 1,178 read