Your Trust in OpenBSD’s Security Features Is a Dangerous Illusion

You’ve spent hours hardening your system. You enabled pledge. You called unveil. You felt that warm, fuzzy feeling of ‘security.’ Then you read the fine print: nobody else is doing it right.

A new measurement study on OpenBSD’s pledge and unveil adoption reveals a brutal truth: these security primitives are largely a theoretical fantasy. In practice, only a tiny fraction of packages actually implement them correctly. Most are either not using them at all, or worse, using them in ways that provide zero real protection.

The most dangerous security feature is the one you trust but never actually works.

Let’s be clear: pledge and unveil are brilliant ideas. They let a program voluntarily lock itself into a sandbox — restricting access to only what it needs. In theory, they should prevent the next buffer overflow from becoming a root compromise. In theory.

But theory and practice are having a custody battle over your security.

The study looked at the entire OpenBSD ports tree. What they found was sobering: fewer than 10% of packages even bother to call pledge. Of those that do, a significant number call it with overly permissive arguments — essentially promising ‘I’ll be good’ while leaving the door wide open. Unveil is even rarer. The cognitive load required to correctly specify the minimal set of filesystem paths is apparently too high for most developers.

We love to tell ourselves we’re writing secure code. We add a line of pledge, check the box, and move on. But the system doesn’t care about your intentions. It cares about what actually happens at runtime.

Partial adoption of security features isn’t better than no adoption — it’s worse, because it creates a false sense of safety.

Think about it: you scan a program’s source, see ‘pledge("stdio rpath")’, and assume it’s sandboxed. But if the developer left out crucial restrictions — like disabling network or writable paths — the attacker still gets everything they need. You’ve just been lulled into complacency.

I’ve seen this firsthand. A sysadmin proudly told me his entire server stack was ‘pledge-protected.’ I ran a quick audit. One of the core daemons had pledge("stdio") — which does almost nothing. It still had full filesystem access, network, exec. The pledge call was a talisman, not a shield.

So why do developers do this? It’s not malice. It’s friction. Defining the exact set of privileges for a complex application is hard. It requires understanding every code path, every library call, every possible future update. The easier path is to slap on a loose pledge and call it a day. And because nobody is measuring adoption, no one notices the gap.

This isn’t an OpenBSD problem — it’s a human problem. We’ve built sophisticated security primitives but forgot to build the culture and tooling to make them actually usable. The result: a system that looks secure on paper but leaks like a sieve in practice.

The real vulnerability isn’t in the kernel — it’s in the gap between what developers promise and what they deliver.

What should you do? Stop trusting features. Start validating them. Use tools like ktrace or systrace to see what your programs actually do. Demand that your dependencies provide measurable evidence of their security restrictions. And if you’re writing code, treat pledge and unveil like contracts — not decorations.

Because the next time you assume your system is sandboxed, you might be the one getting sandbagged.