Project 11: Container Syscall Filter (seccomp-bpf)

A syscall filtering system using seccomp-bpf that restricts what system calls a process can make, with policy generation based on observed behavior—similar to how Docker and Kubernetes apply security profiles.

Quick Reference

Attribute Value
Primary Language C
Alternative Languages Rust, Go
Difficulty Level 4: Expert
Time Estimate 2-3 weeks
Knowledge Area Security / Containers / Sandboxing
Tooling seccomp-bpf, libseccomp
Prerequisites Projects 1-6 completed, understanding of system calls

What You Will Build

A syscall filtering system using seccomp-bpf that restricts what system calls a process can make, with policy generation based on observed behavior—similar to how Docker and Kubernetes apply security profiles.

Why It Matters

This is where BPF began (Berkeley Packet Filter for syscalls!). You’ll understand how containers are sandboxed, write cBPF programs, and see the security model that protects containers.

Core Challenges

  • Understanding cBPF vs eBPF → maps to seccomp uses classic BPF
  • Policy specification → maps to allow lists, deny lists, argument filtering
  • Profile generation → maps to tracing to build profiles
  • Error handling → maps to SECCOMP_RET_ actions*

Key Concepts

Real-World Outcome

# Generate a profile by observing a program
$ sudo ./seccomp-profile --trace /usr/bin/myapp -- --some-args
Tracing syscalls for 30 seconds...

Observed syscalls:
  read, write, open, close, mmap, mprotect, brk
  rt_sigaction, rt_sigprocmask, ioctl, access
  execve, exit_group, futex, clock_gettime

Saved profile to myapp.seccomp.json

# Apply the profile
$ sudo ./seccomp-sandbox --profile myapp.seccomp.json -- /usr/bin/myapp
[myapp runs sandboxed]

# Attempt to use blocked syscall
[myapp] Killed: syscall ptrace blocked by seccomp filter

Implementation Guide

  1. Reproduce the simplest happy-path scenario.
  2. Build the smallest working version of the core feature.
  3. Add input validation and error handling.
  4. Add instrumentation/logging to confirm behavior.
  5. Refactor into clean modules with tests.

Milestones

  • Milestone 1: Minimal working program that runs end-to-end.
  • Milestone 2: Correct outputs for typical inputs.
  • Milestone 3: Robust handling of edge cases.
  • Milestone 4: Clean structure and documented usage.

Validation Checklist

  • Output matches the real-world outcome example
  • Handles invalid inputs safely
  • Provides clear errors and exit codes
  • Repeatable results across runs

References

  • Main guide: LEARN_BPF_EBPF_LINUX.md
  • “Container Security” by Liz Rice