piotr kaminski july 18 2003 l.
Skip this Video
Loading SlideShow in 5 Seconds..
Piotr Kaminski July 18, 2003 PowerPoint Presentation
Download Presentation
Piotr Kaminski July 18, 2003

play fullscreen
1 / 12
Download Presentation

Piotr Kaminski July 18, 2003 - PowerPoint PPT Presentation

reid
0 Views
Download Presentation

Piotr Kaminski July 18, 2003

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Capability Security Capability Security Piotr Kaminski July 18, 2003

  2. 30 Minute Roadmap • From traditional methods to capabilities • Problems solved by capabilities • Some objections addressed SEng 480a / CSc 586a: Capability Security

  3. A File1 resources B File2 subjects C File3 Rotate Tradition 90° • Firewalls, file permissions, stack introspection, … • open namespace + logic wall = a leaky sieve • difficult to code, performance suffers too • Authorization policies R Access Control Lists Capabilities RW R R W W RW SEng 480a / CSc 586a: Capability Security

  4. Capability Discipline • A capability is • a reference to a resource, • combined with authority to use that resource, • that cannot be forged. • Mechanisms that don’t change: • authentication • information security (encryption) • security testing (?) • Advantages • enable principle of least authority • no designation without authority SEng 480a / CSc 586a: Capability Security

  5. Mmm…Tight Security • A secure system ensures that subjects are only allowed to perform authorized actions on resources Principle Of Least Authority (POLA) Each subject is authorized to perform all and only the actions necessary for its work. SEng 480a / CSc 586a: Capability Security

  6. resources subjects Policy in the Matrix • POLA depends on: • fine resource and subject granularity • dynamic resource and subject creation • fine authority granularity • Not practical with ACLs • subjects per-user or per-role • authorities are often coarse • Trivial with capabilities • subjects per-object or per-process • authorities down to individual method level SEng 480a / CSc 586a: Capability Security

  7. Confused Deputy • Scenario: • Print spooler component is given authority to write to a billing file, “/etc/bill”. • Print spooler accepts a file name from user to save status information. • User asks for status to be saved to “/etc/bill”. • Print spooler overwrites billing information, user gets free printing. • How to prevent this scenariousing traditional methods? SEng 480a / CSc 586a: Capability Security

  8. Rebuttal If two subjects can communicate,even ACLs cannot prevent delegation. Small print: to guarantee the *-property, the system mustpartition capabilities from data. Objection: Delegation Claim Capability systems cannot prevent subjects from giving away their capabilities. SEng 480a / CSc 586a: Capability Security

  9. Objection: Revocation Claim Once granted, a capability cannot be revoked. Rebuttal Revocation is achievablewith a simple design pattern. SEng 480a / CSc 586a: Capability Security

  10. In Favour Principle Of Least Authority upheld Unseparable designation and authority Resilient in the face of lazy programmers Against Whole-system method, hybridization weakens security Requires design changes Doesn’t seem to fit static typing In the Balance SEng 480a / CSc 586a: Capability Security

  11. Practice Makes Perfect • Past: • KeyKOS • Present: • E • EROS • Waterken • Paper: • Capability Myths Demolished Future: Earthweb? SEng 480a / CSc 586a: Capability Security

  12. The End The End Thank You