1 / 23

Capability Based Security

Capability Based Security. By Zachary Walker CS265 Section 1. Access Control Issues. Preventing Access Prevent users form accessing privileged data or resources Limiting Access Need to allow some access but not full access Granting Access Give new access or greater access.

winona
Télécharger la présentation

Capability Based Security

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. Capability Based Security By Zachary Walker CS265 Section 1

  2. Access Control Issues • Preventing Access • Prevent users form accessing privileged data or resources • Limiting Access • Need to allow some access but not full access • Granting Access • Give new access or greater access. • Revoking Access • Take back some or all of granted access.

  3. Access Control Lists Access control associated with the resource Can prevent and revoke access Cannot limit or grant access Capability Lists Access control associated with the user Can prevent , limit , and grant access Can revoke but not like expected ( more later ) Methods of Access Control

  4. Lampson Access Matrix

  5. Why the Lampson Equivelency Model isn’t exactly accurate • What happens if an attacker somehow slips a Trojan Horse virus into the system with the intent to steal funds via the accounting program • We examine the differences between the cases where the CEO and the CFO are attacked by the Trojan Horse

  6. The CEO gets the virus The Trojan horse is run by the CEO The CEO lacks access to write to bank records The Trojan horse in unsuccessful in stealing money The CFO gets the virus The Trojan horse is run by the CFO The CFO has access to write bank records The Trojan horse is successful in stealing money from the company Trojan Horse Attack on an ACL system

  7. ACL view of attack • OS checks the the bank records ACL to see if write is authorized • It is the CFO. No Problem Bank Records ACL Write CFO Trojan Horse

  8. The Dilema • The CFO needs write access to the Bank Records • Anyone with write access to the bank records will be susceptible to the Trojan Horse • What is the solution?

  9. Capabilities • With capabilities write access to the Bank Records are not implicit even if the CFO mistakenly downloads and runs the Trojan Horse • The CFO would have to grant the Trojan horse the write capability to the Bank Records for the attack to be successful

  10. Capability Delegation The CFO has capabilities to both the Trojan Horse and the Bank Records However, the Trojan horse has no notion of the Bank Records Bank Records Trojan Horse CFO

  11. Delegation cont. • For the attack to succeed the CFO would have to explicitly pass the capability (yellow arrow) to the Trojan horse. Bank Records Trojan Horse CFO

  12. ACL Diagram • Arrows go from resources to subjects

  13. Capability Diagram • Arrows go from subjects to resources

  14. Why are ACL’s the norm • When UNIX was being developed ACL’s and C-lists were both viable. • C-lists were known to be more secure but also more complex • ACL’s provided better performance and were deemed secure enough for the current computing environment

  15. EROS a capability based OS • EROS stands for “Extremely Reliable Operating System” • EROS is not the first capability based OS • Multics, KeyKOS, and Mach are example of previous attempts at capability based OS designs • Earlier systems have been criticized for being extremely slow.

  16. How is EROS different from other OS designs • Access control handled by capabilities • All data and processes are persistent throughout power cycles

  17. OS Persistence • Persistence means the state of the system is maintained even when powered off. • All registers, processes, memory contents, and of course disk data are stored when powered down. • Persistence is actually a necessity of capability based systems

  18. Why is persistence necessary • It is a “Chicken or the Egg” issue • Suppose the system isn’t persistent • When the system is started where would the startup process get it’s capabilities from? • There is no simple answer to this question and the startup condition is one of the most vexing in capability-based OS design

  19. How is EROS initialized • Every resource in the system is allocated an atomic level primitive object • There are Pages, Nodes, and Numbers at the lowest level. • The OS creates capabilities for every primitive object • Every capability every used in the system will be a composition of these base level capabilities

  20. How does persistence work • In EROS a snapshot of the system is taken every 5 minutes. • long enough to minimize the overhead required for repeated saves • short enough to minimize loss in the case of a system failure

  21. What to save and where • User data • Process List • List of open files • Save them in a partitioned section of disk set aside for persistent data • Note that network connections and open streams are not saved and must be re-established

  22. What if? • System crashes during a save? • The data is actually saved to a look ahead log • If the save is interrupted there is an older version to revert to • Consequence is that there must be two sets of persistence data maintained

  23. Summary • Capabilities provide much more granularity of control than ACL’s • Capabilities solve security issues unsolvable with ACL’s • ACL’s are much simpler to implement and provide for a faster OS

More Related