The difference is that while Capsicum provides you with very solid, easy to reason about protection model. Meanwhile... can you still escape the pledge by reexecuting yourself?
You can only call fork/exec if it's part of the pledge(2) promises, which you can later drop with subsequent calls to pledge. And with unveil(2) or even chroot(2) you can also place further restrictions on which binaries can be executed, and in which directories.
Systems like Capsicum would have you not be able to sandbox those programs at all. Users are left unprotected. So yes, if you pledge(2) a shell. It can call exec, but directly it can't call socket/connect(2), and the reduction of kernel attack surface is still significant. Software using privilege separation can safely leverage this.
The assumption that with Capsicum you wouldn’t be able to sandbox stuff is blatantly false. The proof is existing code - Chromium, Tor, or Irssi - that has been capsicumized, often much more easily than with seccmp (I’ve not seen that comparison with pledge(2) yet).
One advantage that pledge(2) certainly has is the community involvement. OpenBSD has applied pledge(2) in many places, while capsicum(4) was quite a bit slower until recently. This has nothing to do with technical differences, and more with the social aspects.
This makes no sense. Of course you know what the promises are, they're in the source code. You can also use ktrace/kdump(1) or even strings(1). The names of the promises are obvious and their intention is clear. There are subsets of POSIX.
> The assumption that with Capsicum you wouldn’t be able to sandbox stuff is blatantly false.
That is not what I said, I was specifically correcting your misinformed statement regarding pledge(2) and those programs that explicitly permit exec, like shells. Capsicum has no solution for this, and as such these programs cannot be sandboxed on FreeBSD.
> In its current implementation, the program is hardly a shell at all: it has no interactive mode, only executing a single program per invocation.
I don't know how you could meaningfully sandbox a shell without losing some functionality intrinsic to it being a shell.
I think there's a lot of value in sandboxing more constrained applications, especially with untrusted inputs, like web browsers, individual commands, etc. But I don't buy that you can meaningfully reduce the privileges of a shell without losing the quintessential features of a shell.
That's true, but not really the whole truth. Take "dns", for instance. It enables a number of system calls needed to perform DNS resolution. But as far as I understand, those system calls (sendto(2) for example) can then be used arbitrarily. So "dns" actually permits more than the name implies.
On the other hand, when a program is running in capability mode, we know exactly what is permitted and what isn't.
> Capsicum has no solution for this, and as such these programs cannot be sandboxed on FreeBSD.
... they can't be sandboxed on OpenBSD either. pledge("proc exec") doesn't give you a sandbox.
SOCK_DNS
For domains AF_INET or AF_INET6, only allow connect(2), sendto(2), or sendmsg(2) to the DNS port (typically 53).
Why is that significant if I can fork and exec nc(1)?
Having something be capcicumized (?) and exec capable seems to be mutually exclusive.
... That nothing uses. And even their flagship research example, Chrome, has never made it into the FreeBSD ports tree.
OpenBSD has pledge(2)/unveil(2) for Chrome.
The problem with Chrome is not that it’s hard to capsicumize - it’s not, it has been done and documented - but rather that the upstream developers are extremely uncooperative wrt accepting patches.
Google not accepting this upstream is a separate issue, albeit regretful, OpenBSD maintains the pledge/unveil patches and users benefit from this work today, whereas FreeBSD users cannot run Capsicum-ised Chrome.
Capsicum patches are also considerably more intrusive, and their intention and protection is less clear.