Semantics of the
Password-Capability System
Dan Mossop and Ronald Pose
School of Computer Science & Software Engineering
Monash University, Australia.
{dgm,rdp}@csse.monash.edu.au
http://www.csse.monash.edu.au/~rdp/research
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 232 -1
Vol 2
Obj (2, 94837)
Obj (0, 82644)
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:
v
s
2
p1
29372
1,394,506,712
Obj (2, 29372)
p2
3,403,294,157
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 nonzero 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:
2
29372
1,394,506,712
3,403,294,157
System tries to check the
password after XORing with
the process’s lockword (L1,L2).
2
29372
1,394,506,712
xor L1
3,403,294,157
xor 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:
2
29372
1,394,506,712 3,403,294,157
xor L1
xor L2
System tries to decrypt the
password by the process’s
lockword.
2
29372
1,394,506,712 3,403,294,157
The result is a valid capability, so it can be used.
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
2
29372
1,394,506,712
3,403,294,157
xor K
Client is given the above capability, but can’t use it as p2 is
invalid. Instead it must pass it to the type manager.
2
29372
1,394,506,712 3,403,294,157
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.
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
Pay for resource usage
Process
Send
Deposit
Receive
Withdraw
Process
Object
System State (1)

The state, S, of the virtual memory is
determined by the state of all the volumes:
S = {Vv : v is a volume number}

With Vv giving the state of the volume with
volume number v.
The state of a volume Vv is given by:
Vv = {Ov,s : (v,s) is an object name}
With Ov,s being the state of the object, (v,s).
System State (2)




The state of an object Ov,s is:
Ov,s = {datav,s, capsv,s, statusv,s}
datav,s is the state of the object’s user data
capsv,s is the state of the hierarchy of
capabilities existing for the object
statusv,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?