The following operations are available to capability holders:
When transferring a capability, not all access rights to a resource have to be transferred. For example, if the entity Bob has read-and-write permissions, it can transfer only read permissions to the entity Carol.
You can also use the transfer capability and derive capability operations, specifying the value INVALID_HANDLE as the capability. In this case, the capability will not be transferred, but the called security policy will return an "allowed" decision (KSS_GRANT).
The resource driver can initialize a new capability (initialize capability) with the specified resource SID. To finalize a capability and remove the access rights from all holders, all you have to do is finalize the link to the resource.
Initialize capability
Initialization of a capability lets you associate the resource SID with the object of the capability. The initialized capability can be transferred to other entities by using the transfer capability and derive capability operations.
In the ocap family, capability initialization is performed using the init and initR policies.
Transfer capability
This is the capability transfer method in which the initial entity does not receive permissions to revoke the capability from the recipient. Only the entity that is the parent of the initial entity in the CDT will be able to revoke the transferred capability.
For example, if only Bob receives read-and-write access to the file foo.txt from Dave, Bob will be able to transfer these permissions to Carol but will not be able to revoke these permissions. Only Dave will be able to revoke these permissions from Carol.
In this example, the CDT will look as follows:
Dave // driver
|
+--+--+
| |
Bob Carol
In the ocap family, the transfer and transferR policies are used for transfers without the permission to revoke. This operation requires the built-in Transfer permission.
A resource driver cannot transfer a capability in this way because no one would be able to revoke the permissions from the recipient.
Derive capability
This is the capability transfer method in which the initial entity retains the permission to revoke it.
In the ocap family, the derive and deriveR policies are used for transfers with the permission to revoke. This operation requires the built-in Derive permission.
In the ocap family implementation, only the resource driver can perform a revoke capability transfer.
Revoke capability
Revoking a capability involves removing an entity from the list of holders, as well as removing the entire subtree of derivatives from this entity. When a capability is revoked, all rights are revoked.
In the ocap family, the revoke policy is used to perform the revoke operation. This operation requires the built-in Revoke permission.
An entity can revoke a capability from itself (abandon its rights) or from its direct descendant in the CDT.
A resource driver cannot abandon its rights. A driver can lose rights only when the capability is finalized.