Make the system calls jail_set, jail_get, jail_attach_jd, and jail_remove_jd capsicum-aware. Add capabilities for jail operations. The jail system calls that don't work with jail descriptors remain prohibited in capability mode.
The capabilities cover the jail operations that can be done on a jail descriptor: CAP_JAIL_GET, CAP_JAIL_SET, CAP_JAIL_ATTACH, and CAP_JAIL_REMOVE.
There is a (nearly) parallel set of capabilities for operating on jails accessed jail_get/set's JAIL_AT_DESC flag: CAP_JAIL_GETAT, CAP_JAIL_SETAT, CAP_JAIL_CREATEAT, CAP_JAIL_ATTACHAT, and CAP_JAIL_REMOVEAT. Note the addition of CAP_JAIL_CREATEAT, since it's impossible to create the already existing jail that you have a descriptor for.
If a jail descriptor is obtained via both the JAIL_AT_DESC and JAIL_GET_DESC flags being set, then the "own jail" set of capabilities is replaced by the "at jail" set. For example, "jail_set(JAIL_AT_DESC | JAIL_ATTACH)" is functionally equivalent to "jail_get(JAIL_AT_DESC | JAIL_GET_DESC, ..., desc); jail_attach_jd(desc);", and the capability shift matches that.
This is because of the essential difference between the current jail (including the base system), which a jailed user is restricted from changing, and a child jail that properly credentialed users can see, change, create, attach to, and remove. This idea of the current jail is extended to the the "described" jail, i.e. the one the descriptor refers to. It is intuitive for a jail descriptor to be "here's a jail you may modify" (CAP_JAIL_SET), or "you may create/modify/remove sub-jails under the context of this jail" (CAP_JAIL_CREATEAT, CAP_JAIL_SETAT, CAP_JAIL_REMOVEAT). This is somethwat against the idea that capabilities only turn off and never back on, but it really more a space between "system calls like open(2) have all rights" and "system calls like openat(2) inherit the rights of the originating descriptor."
Jail parameters should also be capsicum-aware, and that will need some deciding which parameters are acceptable for capability-mode jails. I expect it to be most of them at least when jails are created, maybe fewer as they're modified. Currently, the only restricted parameters are those that work with global namespaces that capsicum doesn't like: jid and path. descriptors (not jid) are the only way to specify a jail to act on, and newly created jail can only have automatically assigned jids. path's use of the filesystem root space isn't capsicum-compatible, and is replaced with the "root" parameter that is the jail root in file descriptor form (a descriptor that requires CAP_FCHROOT). Both jid and path can be read though. The jail name is not restricted, but is made relative to the passed-in jail (a part of jail descriptors independent of capsicum).