Capsicum
oshogbo.vexillium.org
oshogbo.vexillium.org
OpenBSD's pledge(2) and unveil(2) by comparison are seeing far greater usage, covering somewhere between 85% to 90% of the base operating system. Patches for 3rd party software, and programming languages are also appearing upstream, as they also serve as helpful annotation for other mechanisms and encourage privilege separation.
https://man.openbsd.org/pledge
https://man.openbsd.org/unveil
https://gist.github.com/ligurio/f6114bd1df371047dd80ea9b8a55...
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.
OpenBSD is a tightly nit (at least philosophically) group with a single leader.
FreeBSD is a loose federation of large commercial users, academics and industrial researchers, and end users with a broad range of needs and a bureaucratic core team without any one leader.
Let's buy your comment and say Capsicum is harder to use. Let's hypothetically say it takes twice as long to implement in an application. The FreeBSD community could easily absorb that cost, but there is nobody with earned or assumed authority pointing people in the direction to achieve that high base coverage. As in the original article, the author is doing this in his spare time and there are only a couple other people that assist occasionally. On the other hand Theo has made it a point to achieve high coverage, and quickly, for OpenBSD's new APIs.
The sandboxing functionality is philosophically important to most of the OpenBSD organization, and only seen as important to a small subset of FreeBSD's heavy movers. So that is why you see much lower application coverage.