Screen Version

School of Computer Science & Engineering
University of New South Wales
 Advanced Operating Systems 
 COMP9242 2002/S2 

Sparse Capabilities

Basic idea similar to encryption:

• Add bit-string to make valid capabilities a very small subset of the capability space.
• Can be encrypted object info or something like a password.
• Capabilities are pure user-level objects, which can be passed around like other data.
• Appropriate for user-level servers.

Example: Signature capabilities

``First Migration Scheme''[GL79], designed to allow migration of tagged capabilities in distributed systems.

+

tamper proof via encryption with secret kernel key

+

can freely be passed around

-

need to decrypt on each validation

-

users do not know which object capability refers to

• : one-way function (secure digest), : encryption function
  

``Second Migration Scheme''[GL79]

Object ID visible, yet still tamper proof.

Amoeba's capabilities

Appropriate for user-level servers [MT86].

Properties of Amoeba capabilities

• Port identifies server.
  • Kernel resolves server and caches server location.
• Port IDs are large (48-bit) sparse numbers.
  • Knowledge implies send rights.
• Creator (``owner'') has all rights.
• Server uses OID to look up rights, checks fields to validate.
  • Validation done by user-level server when invoked.
  • Propagation easy, as capabilities are ``normal'' data.
  • Restriction requires server to make new capability.
  • Revocation done by server removing entry from object table.
    But not very helpful if only one capability per access mode.
  • Amplification possible according to server policies.
  • Accessibility is impossible to determine.
  • Protection domain is impossible to determine.
    

Amoeba rights restriction

• Used by server to derive lesser capabilities on request.
• No need to store derived capability in object table.
  

Improved version (not implemented)

• Set of commuting one-way functions , one for each access mode bit:
  .
• To remove access mode , obtain new check field as:
  .
• Can be done by user without server intervention.

Server authentication: F-boxes

• Hardware device ``F-box'' at each network connection
  • When requesting messages for port , F-box will only accept messages destined for port , where is a one-way function
  • Server publishes as port ID
  • Intruder who does not know cannot access messages
• Scheme depends on physical security of F-boxes (or their implementation in the OS).
• Never been implemented (to my knowledge).