Documentation
¶
Overview ¶
seccomp-compile reads an OCI seccomp JSON profile, builds an in-memory libseccomp filter from its rules, and exports the compiled BPF blob to a file. The output is loaded by bwrap via `--seccomp <fd>` at worker spawn time.
The program runs only in the variant Dockerfile build stage (the `seccomp-compiler` stage) and in the release workflow's seccomp- blob job. The runtime blockyard binary stays CGO-disabled; only this tool needs libseccomp.
Invocation:
seccomp-compile -in <profile.json> -out <profile.bpf>
The JSON schema understood here is the subset of the OCI format moby uses in profiles/seccomp/default.json: a top-level `defaultAction`, a list of `syscalls` rules with `names`, `action`, optional `args` matchers, and optional `includes.caps` / `excludes.caps` capability gating. Capability gating is flattened to unconditional rules — the build environment always has the cap, so an `includes.caps` guard is equivalent to an unconditional allow, and `excludes.caps` is equivalent to "don't emit this rule at all" (because a cap-restricted deny is a cap-allow for the CGO-enabled runtime, which isn't our threat model).
Unknown syscalls (for example, arch-specific ones not present on the build host) are skipped silently — matching libseccomp's own runtime behavior. This is important for multi-arch builds: the amd64 compilation step produces a blob that omits arm64-specific syscalls it has no numbers for, and vice versa. Bwrap's runtime doesn't care about missing rules; it cares about well-formed BPF.
Source Files