Capsicum vs Seccomp: Process Sandboxing for Security-Conscious SREs

Modern applications handle untrusted input constantly. When a parser vulnerability leads to code execution, sandboxing determines whether the attacker gains full system access or hits a wall. Both Capsicum and Seccomp provide kernel-level process isolation, but they take fundamentally different approaches.

What is Capsicum?

Capsicum is FreeBSD's capability-based security framework. It uses file descriptor capabilities to restrict what a process can access. Once a process enters capability mode via cap_enter(), it loses ambient authority and can only use previously opened file descriptors with explicitly granted rights.

The model is intuitive: open everything you need, then drop into sandbox mode. The kernel enforces restrictions transparently. Applications like Chromium, OpenSSH, and Casper use Capsicum on FreeBSD.

What is Seccomp?

Seccomp is Linux's system call filtering mechanism. In seccomp-bpf mode, you write BPF programs that decide whether to allow, deny, or modify each system call. This gives fine-grained control over kernel interactions.

The model is explicit: define exactly which syscalls are permitted with which arguments. Tools like Docker, systemd, and Firefox rely on Seccomp for container and browser sandboxing.

Key Differences

Abstraction level: Capsicum works at the file descriptor level, making it easier to reason about. Seccomp operates at the syscall level, requiring detailed knowledge of kernel interfaces.

Portability: Seccomp runs on Linux only. Capsicum exists on FreeBSD, with experimental support in other systems. Linux adoption has stalled.

Complexity: Capsicum requires fewer code changes. Seccomp filters can grow complex and must handle syscall argument inspection carefully.

Granularity: Seccomp offers finer control over individual syscall arguments. Capsicum provides coarser but more maintainable restrictions.

Practical Usage

Enabling Capsicum in C:

# Open resources before sandboxing
int fd = open("/var/data/file.txt", O_RDONLY);

# Enter capability mode
cap_enter();

# Now only fd is accessible, no new files can be opened

Applying a Seccomp filter with systemd:

[Service]
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources

Which Should You Choose?

For FreeBSD deployments, Capsicum offers elegant sandboxing with minimal code changes. Its capability model aligns naturally with Unix file descriptor semantics.

For Linux infrastructure, Seccomp is the standard. Combine it with namespaces and cgroups for defense in depth. Tools like seccomp-tools and strace help debug filter issues.

Both approaches significantly reduce attack surface. The best sandbox is the one your team actually deploys.

Conclusion

Process sandboxing is essential for defense in depth. Capsicum excels on FreeBSD with its intuitive capability model. Seccomp dominates Linux with flexible syscall filtering. SRE teams should evaluate their OS platform and application architecture when choosing a sandboxing strategy.

For teams managing complex infrastructure, Akmatori provides AI-powered incident response that works alongside your security controls. Hosted on Gcore edge infrastructure, it helps you detect and respond to issues faster.