seccomp — Unsafe at any speed (2022)

I don't think the post is wrong, but I think it's overly pessimistic. Is it the best API out there? No. Is it "unsafe at any speed"? Also no - in fact, the author doesn't really talk about safety at all? My belief is that you're better off using it than not using it: it's a pretty robust, lightweight security boundary.

Yes, there are some related syscalls, such as open() / openat(), and every now and then, some new version of libc may start calling one when you think it should be using the other. But I don't see how that supports the thesis of the subsystem being unsafe. It's a hurdle for package maintainers, perhaps?

"And that’s just for the most trivial of examples where you have some unsafe code (e.g. a parser) that takes input on one fd and gives output on another." - the list of syscalls listed in the article is far longer than what you need for a parser. It's a list for a network service. And I think that overlooks one of the key principles you should be aiming with this type of static-policy sandboxing: you want to isolate each functional block. For example, a single policy that "fits" the entire SSH server cradle-to-grave is more or less useless because it needs access to everything. But if you split out networking handling, protocol parsing, and session management into separate processes, you can apply more sensible policies to each.

Well written (as is the linked follow up) and quite depressing.

Landlock is a really great alternative to unveil today. Unfortunately it cannot filter certain syscalls.