Hacker News Reader

Comment by pdw | Hacker News Reader

seccomp is such a sad story. In theory seccomp can do a lot more than OpenBSD's pledge. In practice, the OpenBSD devs added pledge support with comparatively little effort to 100s of programs, while seccomp is a constant headache for the few programs which use it.

View on HN

Worse is better is a simple minded and wrong interpretation. In reality the outward simplicity of pledge(2) masks a great deal of high quality engineering and research. The categories for pledge were not just pulled out of someone’s ass.

Seccomp like so many Linux interfaces is the “fuck it” here’s an exhaustive yet half baked set of tools, you can do anything! This barely works out in gp programming, but is always an unmitigated disaster in anything security related.

Afaik it's not even possible to implement a pledge-like wrapper around seccomp because seccomp is inherited while pledge leaves the responsibility of securing itself to each process.

> Allows a process to call execve(2). Coupled with the proc promise, this allows a process to fork and execute another program. If execpromises has been previously set the new program begins with those promises, unless setuid/setgid bits are set in which case execution is blocked with EACCES. Otherwise the new program starts running without pledge active, and hopefully makes a new pledge soon.

https://man.openbsd.org/pledge

Pledge can be inherited by child processes too.

I keep getting raged at over e-mail/github because end-packagers and some users don't comprehend why it's broken. I completely regret adding seccomp support in the first place, since it breaks randomly, packagers enable it by default then don't run tests and ship broken binaries, then hurl abuse "because security" when you try to report it.

By comparison I've never gotten a complaint about pledge support (or the FreeBSD equivalent), which we also support.

Reply on news.ycombinator.com