1 / 17

CACL: Efficient Fine­Grained Protection for Objects

CACL: Efficient Fine­Grained Protection for Objects. Richardson, Schwarz, Cabrera IBM Almaden OOPSLA’92. The Problem. Protection for OO Databases we want: fine-grain intuitive for programmer efficient implementation dynamic (i.e. granting and revoking rights on the fly) extensible

chaz
Download Presentation

CACL: Efficient Fine­Grained Protection for Objects

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. CACL: Efficient Fine­Grained Protection for Objects Richardson, Schwarz, Cabrera IBM Almaden OOPSLA’92 CS711 - 8 Sept 2003

  2. The Problem • Protection for OO Databases • we want: • fine-grain • intuitive for programmer • efficient implementation • dynamic (i.e. granting and revoking rights on the fly) • extensible • a model suitable for objects • Other approaches/related work • Pointer confinement and alias protection • OS level protection • too coarse • Read/Write/Execute model inappropriate • decentralized policies • Guide: OO distributed system CS711 - 8 Sept 2003

  3. CACL Protection Model • Principals • user, group, process, etc. • How principals are used: • Each object has: • an owner • the owner authorizes access to the object • a method principal (MP) • the object’s methods execute on the MP’s behalf • the MP is often (but not always) the owner • Each class declaration has: • an implementor • responsible for the correctness of the code. • The current principal is the MP of the currently executing method CS711 - 8 Sept 2003

  4. Access Control Lists • Every method on every object has an access control list. • Equivalently: • ACL(Object x Principal){Method} • Fine granularity: • Access can be controlled per-method, per-object, per-principal. CS711 - 8 Sept 2003

  5. The Protection Guarantee A method invocation o.m(…) succeeds if and only if the current principal is allowed to invoke the method m on object o. • Implications: • revocation/modifications to ACL take effect on the next method invocation. CS711 - 8 Sept 2003

  6. The Rules for Changing Stuff • The owner of an object can: • modify access control lists • give ownership to another principal • set him/herself as the MP • For a new object o: • the owner of o is the current principal • the MP of o is the implementor of o • ACL(o, current principal) = {all methods of o} • ACL(o, everyone else) = {} CS711 - 8 Sept 2003

  7. o:C Owner: Bob MP: Acme-Corp. ACL: Bob:{doStuff(int), doMoreStuff(char)} doStuff(int i); doMoreStuff(char j); … Example 1: Transferring ownership • Current Principal: Bob • Bob creates an object o, of class C, written by Acme Corp. • Default Owner is the CP • Default MP is the implementor • Default ACL lets Bob invoke everything CS711 - 8 Sept 2003

  8. o:C Owner: Bob MP: Acme-Corp. ACL: Bob:{doStuff(int), doMoreStuff(char)} Alice:{doStuff(int), doMoreStuff(char)} doStuff(int i); doMoreStuff(char j); … Example 1: Transferring ownership • Current Principal: Bob • Bob modifies ACL to let Alice invoke all methods CS711 - 8 Sept 2003

  9. o:C Owner: Alice MP: Acme-Corp. ACL: Bob:{doStuff(int), doMoreStuff(char)} Alice:{doStuff(int), doMoreStuff(char)} doStuff(int i); doMoreStuff(char j); … Example 1: Transferring ownership • Current Principal: Bob • Bob transfers ownership to Alice • Methods do not run with Alice’s authority; they run with Acme-Corp’s. • Methods to run with Alice’s authority requires Alice’s co-operation. CS711 - 8 Sept 2003

  10. o:C Owner: Alice MP: Alice ACL: Bob:{doStuff(int), doMoreStuff(char)} Alice:{doStuff(int), doMoreStuff(char)} doStuff(int i); doMoreStuff(char j); … Example 1: Transferring ownership • Sometime later… • Current Principal: Alice • Alice sets herself as the MP • Alice must be sure that class C is not a Trojan horse. • How does Alice know (at runtime) that the object really is written by Acme Corp? e.g. maybe Bob wrote class Evil extends C CS711 - 8 Sept 2003

  11. bobLaser:Printer cv:Document Owner: Bob Owner: Alice MP: Bob MP: Alice ACL: Alice:{print(Document)} ACL: Alice:{getText()} print(Document d); getText(); Example 2: Limited trust • Alice wants to print a document on Bob’s printer • Acme Corp implemented code for class Printer • Alice doesn’t trust Bob, but trusts Acme Corp. CS711 - 8 Sept 2003

  12. bobLaser:Printer cv:Document Owner: Bob Owner: Alice MP: Bob MP: Alice ACL: Alice:{print(Document)} ACL: Alice:{getText()} print(Document d); getText(); Example 2: Limited trust bobLaser.print(cv)  • Alice’s invocation of bobLaser.print is OK, but • Bob’s invocation of cv.getText (as part of bobLaser.print(cv)) is not allowed • But the code for Printer was written by Acme Corp. Bob can’t do anything evil with cv using the Printer class CS711 - 8 Sept 2003

  13. bobLaser:Printer cv:Document Owner: Bob Owner: Alice MP: Bob MP: Alice ACL: Alice:{print(Document)} ACL: Alice:{getText()} print(Document d); getText(); Example 2: Limited trust cv.addACL(Bob, getText) bobLaser.print(cv) cv.removeACL(Bob, getText)  • Alice need to know that Printer.print(cv) doesn’t make a call-back into some of Bob’s code… • Maybe a finer grain notion of principals would be more suitable, e.g. the principal BobAsPrinterOwnershould be given access… CS711 - 8 Sept 2003

  14. Implementation • Want to enforce guarantee: A method invocation o.m(…) succeeds if and only if the current principal is allowed to invoke the method m on object o. • But don’t want to check every method invocation • Key observation: • For a reference r to object o, the methods that can be invoked on o via r depend on: • The ACL of o • The context of r • (i.e. the CP of the frame that has r, or the MP of an object with r as a field.) • Therefore, only need to check method invocations if: • the ACL of o changes, or • if the context of r changes • (e.g. the object with r as a field has its MP changed, or pass a reference as a method parameter across a protection domain boundary) CS711 - 8 Sept 2003

  15. Implementation cont. • Use references as capabilities • References now also include a pointer to a dispatch vector for all methods of the object. • The DV for a reference r points directly to the method code for m only if we have confirmed that the invocation r.m() is allowed. • Otherwise, the DV points to a protection manager that will check if the invocation is permitted, and update the DV as appropriate. • Track DVs and references to allow modifying the DVs if the ACL of o or context of r changes. • Some runtime support required. CS711 - 8 Sept 2003

  16. Cf. Java Stack Inspection • Java stack inspection has • Finer granularity? • Arbitrary checkPrivilege() calls, instead of per-method invocation • More restricted notion of Principal? • A model that seems indifferent to OO? CS711 - 8 Sept 2003

  17. Discussion points/Questions • What is trust in this model? • Trust relationships seem to be very closely tied to the code, e.g. Alice trusting Bob only if he is running Acme’s Printer. • Is it possible to describe trust relationships externally/statically, and then check the code conforms to these relationships? • What other mechanisms are required? • Code certificates? (who implemented the code, who gives their authority to which code?) • Dynamic way of determining implementor? • Effective types • Effective type = static type  allowed type. • Need runtime type checking. • A useful way to think about it? • Does it allow more static analysis? • Usability • An intuitive model? • How to test that the trust relationships are correct? • Static checking? • Programmer effort required? • Comparison to Java Stack inspection CS711 - 8 Sept 2003

More Related