March 9, 2026
The sandbox got spicy
FreeBSD Capsicum vs. Linux Seccomp Process Sandboxing
Security showdown or comment cage match? Readers roast the post with “fruit stands,” AI slop, and HTTPS drama
TLDR: A post compared FreeBSD’s “lock it in a tiny room” Capsicum with Linux’s “filter every move” seccomp. Commenters called the comparison unfair, pushed Linux’s Landlock, and roasted the site for AI-looking posts, unreadable grey text, and shaky HTTPS—turning a security explainer into a full-on comment brawl.
A blog pitted two ways to lock down misbehaving programs—FreeBSD’s Capsicum (slam the door and throw away the key) versus Linux’s seccomp (a picky bouncer checking every request)—but the real fireworks exploded in the comments. The top vibe: strong opinions, sharper elbows. One reader mocked the comparison as “apples to a fruit stand,” arguing Linux can be set up in a similar “open-then-freeze” way and even claims to have built a library for it. Another came in swinging: “not a fan of seccomp,” pointing to a critical post and saying Landlock—Linux’s newer, simpler file-access rules—is the better path. But then the plot twists: a commenter alleged the entire blog looks AI-generated, calling it more “resume-boosting slop” than scholarship, which set off a meta-debate about the state of tech writing. Cue the aesthetics brigade: someone blasted the site’s grey text as “unreadable” with a link to the complaint, and another dunked on the site’s HTTPS setup for a security article—oof. In short, the software got sandboxed, and so did the blog’s credibility. The take-home? Capsicum feels like a sealed panic room; seccomp is a strict doorman; and the crowd wants Linux to try Landlock while roasting the blog’s vibes as hard as its tech takes.
Key Points
- •The article contrasts FreeBSD Capsicum’s capability model with Linux seccomp-based sandboxing to address Unix’s ambient authority problem.
- •Capsicum (from 2010 research) was enabled by default in FreeBSD 10.0 (2014) and uses cap_enter() to irreversibly remove access to global namespaces, retaining only rights-limited open FDs.
- •Linux’s seccomp strict mode (2005) allowed only four syscalls, making it impractical for most uses.
- •Seccomp-bpf (Linux 3.5, 2012) uses a BPF program to allow or deny syscalls at runtime, enabling practical syscall allowlisting.
- •Philosophically, Capsicum restricts objects and capabilities, while seccomp-bpf filters syscalls; allowed syscalls can still operate on any already-open FD, preserving their full rights.