The short version is that pledge and seccomp are implemented in the kernel, so any mistakes there let the attacker win immediately. As a result, they are implemented to be as simple as possible and don't let you express rules like "You can open /etc/ld.so.conf but nothing else in /etc". (Namespaces, which are also in the kernel but are more complex, let you do this sort of thing but definitely have had game-over bugs recently.)
The ideal way to deploy something like this is to stick seccomp/pledge on the userspace sandboxing process, and implement all your complicated policy decisions in that process.
> As a result, they are implemented to be as simple as possible and don't let you express rules like "You can open /etc/ld.so.conf but nothing else in /etc".
OpenBSD's pledgepaths (..soon to be renamed?) will address this, but in general "hoisting" the opening of files before pledge or "sandboxing" is often correct.
The proposed semantics for pledgepath are explicit paths/files are allowed, and must be done before any pledge including "rpath/wpath" or "cpath".
That seems cool, but I hope you don't end up in the place where namespaces ended up where there are too many security-sensitive codepaths in the kernel before you hit the sandbox. :) Unprivileged user namespaces exist but are disabled by default on many distros. It would be a shame for pledge to stay in the use case of "hardening programs that were previously running as root and that was okay" and not in the use case of "sandboxing actually untrusted programs".
OpenBSD has practically pioneered privsep and privdrop designs, including techniques like file descriptor passing. pledge() already works for privileged/unprivileged users/processes and most of the base system is pledged.
The ideal way to deploy something like this is to stick seccomp/pledge on the userspace sandboxing process, and implement all your complicated policy decisions in that process.