CACL Efficient Fine Grained Protection for Objects Richardson

CACL: Efficient Fine Grained Protection for Objects Richardson, Schwarz, Cabrera IBM Almaden OOPSLA’ 92 CS 711 8 Sept 2003 1

The Problem n Protection for OO Databases n we want: • • • n 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 n n Pointer confinement and alias protection OS level protection • too coarse • Read/Write/Execute model inappropriate n n decentralized policies CS 711 Sept 2003 Guide: OO distributed 8 system 2

CACL Protection Model n Principals n n user, group, process, etc. How principals are used: n 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 n Each class declaration has: • an implementor • responsible for the correctness of the code. n The current principal is the MP of the currently executing method CS 711 8 Sept 2003 3

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

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. n Implications: • revocation/modifications to ACL take effect on the next method invocation. CS 711 8 Sept 2003 5

The Rules for Changing Stuff n The owner of an object can: n n modify access control lists give ownership to another principal set him/herself as the MP For a new object o: n n 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) = {} CS 711 8 Sept 2003 6

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

Example 1: Transferring ownership n n Current Principal: Bob o: C Bob modifies ACL to let Alice invoke all methods Owner: Bob MP: Acme Corp. ACL: Bob: {do. Stuff(int), do. More. Stuff(char)} Alice: {do. Stuff(int), do. More. Stuff(char)} do. Stuff(int i); do. More. Stuff(char j); … CS 711 8 Sept 2003 8

Example 1: Transferring ownership n n Current Principal: Bob o: C Bob transfers ownership to Alice Owner: Alice MP: Acme Corp. ACL: n n 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. Bob: {do. Stuff(int), do. More. Stuff(char)} Alice: {do. Stuff(int), do. More. Stuff(char)} do. Stuff(int i); do. More. Stuff(char j); … CS 711 8 Sept 2003 9

Example 1: Transferring ownership n n n Sometime later… Current Principal: Alice sets herself as the MP n n 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 o: C Owner: Alice MP: Alice ACL: Bob: {do. Stuff(int), do. More. Stuff(char)} Alice: {do. Stuff(int), do. More. Stuff(char)} do. Stuff(int i); do. More. Stuff(char j); … CS 711 8 Sept 2003 10

Example 2: Limited trust bob. Laser: Printer Owner: Bob MP: Bob cv: Document Owner: Alice MP: Alice ACL: print(Document d); get. Text(); Alice: {print(Document)} n n n Alice: {get. Text()} 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. CS 711 8 Sept 2003 11

Example 2: Limited trust bob. Laser: Printer Owner: Bob MP: Bob cv: Document Owner: Alice MP: Alice ACL: print(Document d); get. Text(); Alice: {print(Document)} n n n Alice: {get. Text()} bob. Laser. print(cv) Alice’s invocation of bob. Laser. print is OK, but Bob’s invocation of cv. get. Text (as part of bob. Laser. 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 CS 711 8 Sept 2003 12

Example 2: Limited trust bob. Laser: Printer Owner: Bob MP: Bob cv: Document Owner: Alice MP: Alice ACL: print(Document d); get. Text(); Alice: {print(Document)} n n Alice: {get. Text()} cv. add. ACL(Bob, get. Text) bob. Laser. print(cv) cv. remove. ACL(Bob, get. Text) 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 Bob. As. Printer. Owner should be given access… CS 711 8 Sept 2003 13

Implementation n 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. n n But don’t want to check every method invocation Key observation: n 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. ) n 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) CS 711 8 Sept 2003 14

Implementation cont. n Use references as capabilities n n 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. n n Track DVs and references to allow modifying the DVs if the ACL of o or context of r changes. Some runtime support required. CS 711 8 Sept 2003 15

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

Discussion points/Questions n What is trust in this model? n n n What other mechanisms are required? n n n Effective type = static type allowed type. Need runtime type checking. A useful way to think about it? Does it allow more static analysis? Usability n n n Code certificates? (who implemented the code, who gives their authority to which code? ) Dynamic way of determining implementor? Effective types n n 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? An intuitive model? How to test that the trust relationships are correct? Static checking? Programmer effort required? Comparison to Java Stack inspection CS 711 8 Sept 2003 17