The author explains well that pledge(2) is all-or-nothing and that this design is intentional. Indeed, as more cap-safe APIs are designed, this sort of edge will only become sharper. Cap-safe languages can do even better fine-grained restriction of capabilities, but require a total rewrite instead of just an extra syscall.
This is about OpenBSD pledge(2), which was designed to allow developers to write software that can be sandboxed, not as a mechanism to sandbox arbitrary software with requirements for which you don't fully understand.
Well, the article actually attempts to use pledge to do just that. This results in a nice article that teaches a bit about pledge, sandboxing, and ktrace.
The conclusion does explain why pledge would be a poor generic sandbox.
This point has been made from the early days, but I think this exercise reinforces it, that pledge works best with programs where you understand what the program is doing. A generic pledge wrapper isn’t of much use because the program is going to do something unexpected and you’re going to have a hard time wrangling it into submission.
