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 non- transferrable, 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?