Features of Capability Systems

A Field Guide for Capability Systems
Early Design Freezes

  1. Can’t read the bits—cannot turn caps into bits.
  2. Can’t write the bits—cannot turn bits into caps.
  3. All interactions by caps.
  4. Caps are invokable by using them to address a message.
  5. Can pass caps in messages.
  6. Caps can be detected in messages and in memory.
  7. Non-delagatable caps (which cannot be included in messages)
  8. Stack or other continuation mechanism.
  9. Revokability
  10. Turn code into behavior—new behavior can be added.
  11. Caps can define memory. (RO or RW)
  12. Weak or Sensory memory caps
  13. Synergy—can compare caps for equality.
  14. Efficient Synergy—sealers or brands.
  15. Caps for space authority
  16. Caps for processing authority

Notes

#1 and #2 are redundant but beware that reading bits from caps may indirectly reveal secrets.
#3 needs qualifications concerning noise.
#6: If code comes from some untrusted source one may need to know what caps it holds before turning it into behavior. Membranes require searching messages for caps.
#7 is an anti feature, I think.
#8 is necessary if the code to define objects is itself subject to capability discipline.
#9 by indirection, I presume.
Without #14 (C++’s private attribute) and membranes are impossible.

I do not try here to analyze using secrets as capabilities. I do not claim that secrets cannot serve as capabilities. The art of using secrets for caps merges onto crypto, which is hard. Using secrets seems incompatible with some goals such as confinement.

These design freezes effect both (kernel or runtime) and application design. Some code will not care about #11 thru #16.

Similar note