Notes as I browse the documentation of Capsicum

First impressions of an impressively short list of new Unix kernel calls. It appears that the analogy of Unix file descriptors with caps is respected and extended.

Control over other processes is by a new set of kernel calls which take caps called process descriptors instead of the legacy process IDs.

Eschew ambient authority, for me and my progeny. Resulting mode is called capability mode and refers, I presume, to the process and threads therein. Its idempotent. I presume that these other new kernel calls are available in or out of capability mode.
Test capability mode for this process. (Careful, you may want to virtualize this mode and this call might then be a thorn.)
Create weaker cap from extant capability via provided bit mask.
Returns rights of a held cap as a bit mask. (Perhaps there is some commonality of bit positions; we shall see.) They provide names and connotations for 50 of the bits. Those suggest treating legacy kernel functions as objects. That’s a tall order but great if it can be done.
(typo: The description of pdfork refers to pidp in the synopsis, but there is no such field.)
returns the old fashioned process ID of some process whose cap you hold. Curious.
Sort of like delete a domain.

The TrustedBSD MAC Framework: Extensible Kernel Access Control for FreeBSD 5.0
Mac OS X kernel security hooks
You don’t have to be nearly so smart to build a secure capability system as to tack security onto Unix. On the other hand a simple capability system by itself will not run the vast collection of legacy Unix applications without complex Unix adaptor technology. But this latter technology will not impact the security and integrity of apps that don’t need it. To be fair there are performance advantages in running Unix apps on a foundation that evolved from Unix.
I must think, and maybe write about the old conflict of organizing invocations first by sort of object and then by particular object or vice-versa.