1 / 17

Secure Operating 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.

quasim
Télécharger la présentation

Secure Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Secure Operating Systems Lesson F: Capability Based Systems

  2. 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

  3. 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 

  4. 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)

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. The trade off ACL 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 • 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

  13. 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

  14. 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

  15. 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?

  16. To Do • Read Capability-Based Computer Systems, Ch 1 and Ch 10 • This will be on the final 

  17. Questions & Comments • What do you want to know?

More Related