The difference between pledge and seccomp is not just a matter of fine-grainedness. There's some of that, but I'd say there's also a difference in philosophy:

The difference between pledge and seccomp is not just a matter of fine-grainedness. There's some of that, but I'd say there's also a difference in philosophy: sandboxing resources versus sandboxing kernel attack surfaces. At one end of the spectrum is the macOS sandbox, which pretty much only restricts how the process is allowed to interact with the outside world. It's not actually simplistic like the article claims; that's just the public API. If you look at the raw sandbox profiles, which Apple writes for daemons and such, it's quite fine-grained: sandbox profiles can specify which paths can be read and which can be written (with an arbitrary number of allow/deny rules, each of which can match on an arbitrary regular expression), which network ports can be opened or listened to, which preferences can be read or written, which IPC services can be accessed, and so on... there are a ton of categories. If you're on macOS, look in /usr/share/sandbox and /System/Library/Sandbox/Profiles to see what they look like. However, sandboxing only occurs when a given syscall's kernel implementation explicitly calls for it, and even the most locked-down process can access hundreds of syscalls and Mach kernel IPC calls, which based on their intended purpose should be harmless. And most of them really are harmless, but all it takes is a small oversight in one of them for an attacker to potentially corrupt memory in the kernel and gain control over the system. * At the other end is Linux seccomp, which is designed to allow minimizing kernel attack surface. Chrome's renderer processes only get access to a tiny set of syscalls, and even the arguments to the syscalls are locked down, corresponding as closely as possible to what the process actually uses. (This is possible in part because Chrome has an unsandboxed master process that handles things like reading files for it. The renderer sandbox doesn't even allow open(2).) Thus Chrome is protected from most vulnerabilities in the Linux kernel, because there's just no way to get to the buggy code in question from within the sandbox. This isn't perfect: I've found multiple Linux kernel bugs (only one exploitable so far) that are accessible from the sandbox. And of course it doesn't make Chrome immune to privilege escalation, since attacking the kernel directly isn't the only option; IPC communication with the master process is a much larger attack surface. But that's basically unavoidable, and the situation for Chrome is still a big improvement over other operating systems. Unfortunately, as the article says, it takes quite a lot of work to adapt to new applications. OpenBSD pledge seems somewhere in between. Unlike the other two, I don't have personal experience using it, but based on the manpage - an empty "promises" set restricts the process to _exit(2), which like seccomp should protect against kernel flaws. However, if you supply "stdio", suddenly the process gets access to 69 system calls, which is not terrible (many of the calls in the set are very basic and unlikely to contain bugs) but not as minimal as one might want. There are a bunch of random functionality lockdowns, which is good - for example, ioctl operations are locked down, "setsockopt(2) has been reduced in functionality substantially"... on the other hand, the promise categories generally seem more aligned to 'resources the program might want to access' than 'kernel API surface the program might need to use'. Overall, definitely not bad, and I'd like to see something comparable on Linux, but I'd be more comfortable if OpenBSD also supported a more fine-grained sandbox. * (Okay, that's a little unfair to macOS, since there are some sandbox filters that lock down kernel attack surface, such as the ioctl filter and the IOKit filters - the latter of which has been tightened over time. But that still leaves a ton of surface exposed.)