Transcript Capability Systems

Secure Operating Systems
Lesson F: Capability Based Systems
Where are we?

Half way through Windows, but I feel the
need for a break; I’m depressed about security
so I need to look at something hopeful:
Capability based systems
Capabilities


Old idea, goes back to the mid-sixties (Dennis
and Van Horn, 1966)
Capabilities provide:



Single mechanism to address primary and
secondary memory
Single mechanism to address both hardware and
software resources
Solve or simplify many problems, but also
create some 
Concept



A capability is “a token, ticket or key that
gives the possessor permission to access an
entity or object in a computer system”
Implemented as an object identifier and
access rights
In principle, the object could be anything at
all (file, array, sheep)

Rights define operations we can carry out (read,
write, shear)
Capability List


Each program would have a capability list – this
defines all the objects available
Thus, a capability provides addressing and access
rights to the object



Because of this, the system must prevent capability
object manipulation (i.e. forged capabilities)
Does this sound like HANDLES yet? 
When a new file is created, a new capability is
added to the capability list
Memory, Conventionally





System supports a segmented process virtual address;
virtual address is local, and is translated through the
process-local segment table
A program can construct any virtual address it likes; on
each reference, the OS has to check the validity of the
request
Loading a segment table is a privileged operation by the
OS
Sharing of segments between processes is messy – must be
moderated by the OS – and is worse if we want the same
virtual address (when would that happen?)
Dynamic sharing requires OS intervention
Memory, Capabilities





System has segmented virtual memory, but can
only be addressed if a capability for that segment
has been loaded
Loading a capability register is not privileged,
but the OS must control the contents
Address space can be changed dynamically
Sharing a virtual address with something doesn’t
necessarily imply access
A process can share by copying or sending the
capability to another process
Private capability lists

Capability systems work very well with
respect to objects



Allow a routine to have a private capability list
Can help isolate errors
We simply pass the capability to give access to a
particular object
Temporal advantages

A huge advantage of capabilities is that a
capability exists system wide



Thus, in a traditional system, an address is only
meaningful within a particular process
In a capability system, addresses (capabilities) are
independent of the process using it
Use the unique identifier to determine if
something should be freed
Default deny?


Capabilities are interesting, because in some
sense, they are default deny… if you don’t
have the capability, you can’t access
something
In a “normal” system, you can roll the dice
and see if the file/object will open for you
Real World Example

Carla has a safe deposit box. Sometimes, she
would like trusted friends to make deposits or
withdrawals


Approach 1: ACL
Approach 2: Carla gives you a key when she
allows you in
The trade off
ACL






Bank must maintain a list for
each box
Bank must ensure the validity
of the list at all times
Bank must prove identity
To allow a new person, Carla
needs to visit the bank
A friend cannot extend the
privilege
Removal requires a visit to
the bank
Capability





Once the keys are given out,
the bank is out of the loop
The lock/key system must be
very secure; hard to copy a
key
The owner can give out a key
to anyone, anytime
One a key is out of Carla’s
sight she doesn’t know what
happens to it
Carla can ask for her key
back when she is done
Issues: Storage



A capability based system doesn’t really have
a privileged mode of operation; it’s just about
what capabilities you have
The hardware must be able to detect every
attempt to forge or modify a capability
Remember, must store identifier or name and
the privileges the capability grants
Issue: Concurrency


Sharing of objects is now easy, but
concurrency can become a bit of a problem
Of course this isn’t specific to a capability
based system
Revocation



Dealing with revocation can be tricky – you
can design a system, but it’s hard
Once someone has the capability, how, as the
object owner, can you force it back?
Can you force the capability to be nontransferrable, while you’re at it?
To Do


Read Capability-Based Computer Systems,
Ch 1 and Ch 10
This will be on the final 
Questions & Comments

What do you want to know?