Semantics of the Password-Capability System Dan Mossop and Ronald Pose School of Computer Science & Software Engineering Monash University, Australia.

Overview Background Introduction to the system System state State operations Security analysis

Background (1) What is the Password-Capability System?  Operating system kernel designed and implemented at Monash University  Capability-based access control  Global persistent address space  Formed the bases of other systems such as Walnut (Monash University), Mungi (UNSW), Opal (University of Washington) Why do we need it?  Allows for ease of sharing and access of objects throughout the world in a highly secure manner

Background (2) Conventional systems:  Have coarse-grained access control typically based on a form of access control list  Are complex and hard to analyse  Don’t support mechanisms such as process confinement or per-use charging for resources and services The Password-Capability System  Has fine-grained access control  Is compact and amenable to analysis  Supports process confinement  Incorporates a fully integrated economic model for resource allocation and management as well as service provision

Virtual Memory (1) Data, files, processes and programs all considered as ‘objects’ Objects reside in a persistent global virtual memory Virtual memory divided into volumes Each object has an object name (v, s)  v is the volume number  s is the object serial number Object name is unique

Virtual Memory (2) Objects in virtual memory: e.g. assuming a 32 bit volume number Note that a volume number identifies a volume, typically a storage device, but not its geographic location Vol 0 Vol 1 … Vol 2Vol … Obj (0, 82644) Obj (2, 94837) Obj (2, 29372)

Password-Capabilities (1) Access is controlled by password-capabilities A password-capability is a value Denoted (v, s, p1, p2), where:  v,s name the object to which access is allowed  p1,p2 are two halves of a random password The randomly generated password protects against forgery Each capability defined for an object affords a set of access rights that may be the same or different to those of other capabilities for the object

Password-Capabilities (2) A password-capability: Obj (2, 29372) ,394,506,7123,403,294,157 vsp1p2

Access Rights A password-capability affords access rights such as: Read, Write, Execute a range of words of the object Start, Suspend an object that is a process Deposit, Withdraw funds from the bank account that is intrinsic to all objects Rights to derive new capabilities or to Delete existing capabilities

Capability Hierarchy When an object is created, a capability is returned affording all access rights ever possible for that object This is the ‘master’ capability New capabilities can be derived from existing ones These ‘derivatives’ have a subset of the rights of their parent Deletion of a capability deletes all its derivatives as well Thus each object has defined a singly-rooted tree of capabilities affording various access rights Access to an object is only possible via a capability

Confinement (1) Each process has a 64-bit lockword that cannot be read Prior to checking the validity of a capability, the system first XORs the P1,P2 fields with the current lockword of the process A zero (default) lockword thus has no effect however a non- zero lockword in effect ‘locks’ the process so that it cannot use normal capabilities. If a process’s lockword is set the process will only be allowed to use capabilities whose use cannot allow the system’s state to be changed. One can allow a locked process to access objects by first XORing the password fields of the capabilities with the lock value. This will cancel out the System’s XOR and allow normal operation.

Confinement (2) An unconfined capability: ,394,506,7123,403,294, ,394,506,712 xor L1 3,403,294,157 xor L2 System tries to check the password after XORing with the process’s lockword (L1,L2). The result is not a valid capability, so it cannot be used. Note that the capability presented to the system will be allowed to be used without the XOR if it does not allow the system state to be changed.

Confinement (3) A ‘confined’ capability: ,394,506,712 xor L1 3,403,294,157 xor L2 System tries to decrypt the password by the process’s lockword. The result is a valid capability, so it can be used. 3,403,294,1571,394,506,712

Type Management (1) A type manager can create objects and XOR capability passwords before giving to clients The clients can’t alter the objects directly – they must use the type manager Operations (such as derive a new capability) which do not alter the object’s contents can be carried out without consulting the type manager

Type Management (2) Type management ,394,506,712 3,403,294,157 xor K The type manager knows K, so it can recover the above capability. This capability is valid and can be used on behalf of the client. 3,403,294,1571,394,506,712 Client is given the above capability, but can’t use it as p2 is invalid. Instead it must pass it to the type manager.

Money (1) The system has a mechanism for paying for resource usage Objects act as stores of ‘money’ Processes have an amount of ‘cash’ from which usage payment is taken Processes can deposit cash in objects and/or withdraw it Processes can send cash to one another

Money (2) The monetary mechanism System Process Object Send Receive Deposit Withdraw Pay for resource usage

System State (1) The state, S, of the virtual memory is determined by the state of all the volumes: S = {V v : v is a volume number} With V v giving the state of the volume with volume number v. The state of a volume V v is given by: V v = {O v,s : (v,s) is an object name} With O v,s being the state of the object, (v,s).

System State (2) The state of an object O v,s is: O v,s = {data v,s, caps v,s, status v,s } data v,s is the state of the object’s user data caps v,s is the state of the hierarchy of capabilities existing for the object status v,s is the information used when the object is seen as a process

State Operations (1) There are different types of operations which use the virtual memory:  Object operations  Data operations  Capability operations  Status operations

State Operations (2) Object Operations  Make_obj – creates a new object Note: Objects are deleted when there are no extant capabilities defined for them

State Operations (3) Data Operations  Read – read data from the object  Write – write data to the object  Execute – execute instructions in an object

State Operations (4) Capability Operations  Cap_info – get information about a capability  Derive_cap – derive a new capability  Delete_cap – delete a capability  Rename_obj – delete all capabilities for an object and create a new master capability

State Operations (5) Status Operations  Withdraw – withdraw money from an object  Deposit – deposit money into an object  Suspend – suspend a process  Resume – resume a process  Lock – confine a process  Send – send a message to another process  Receive – retrieve a message  Wait – wait for a message

Security Analysis (1) The Password-Capability System seems secure, but can we convince ourselves? The semantics presented give a foundation for doing a thorough security analysis There are a number of security aspects we are interested in analysing

Security Analysis (2) How well do capability passwords protect against forgery?  Subtleties in the use of passwords introduce some interesting properties  Does this reduce their security?  How long should passwords be to prevent forgery?  Current proposed password length is 64-bits  Initial analysis suggests 128 or 256-bits needed  Can modifying the system reduce this length?

Security Analysis (3) Is the confinement mechanism secure?  Can we prove no covert channels exist?  Which rights can change the system state?  Is there any way for a process to discover its lock?

Security Analysis (4) Can the system support arbitrary security policies?  How can this be achieved?  Are any modifications to the system necessary?

Formal Semantic Analysis (1) No operation occurs without a capability and money to pay for it pays() A capability exists only if its password is associated with the object check_pass() A capability defines access rights to an object that are not encoded in the password has() Access rights may operate on a subset of the words in an object can_see()

Formal Semantic Analysis (2)

Conclusion We have presented the Password-Capability System Outlined a formal specification of its semantics This can be extended to a formal analysis of the security

Questions?