Transcript CACL
CACL:
Efficient FineGrained
Protection for Objects
Richardson,
Schwarz, Cabrera
IBM Almaden
OOPSLA’92
CS711 - 8 Sept 2003
1
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
CS711 - 8system
Sept 2003
Guide: OO distributed
2
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
3
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, perobject, per-principal.
CS711 - 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.
Implications:
• revocation/modifications to ACL take effect on
the next method invocation.
CS711 - 8 Sept 2003
5
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
6
Example 1: Transferring ownership
Current Principal: Bob
o:C
Bob creates an object o,
of class C, written by
Acme Corp.
Owner: Bob
MP: Acme-Corp.
ACL:
Default Owner is the CP
Default MP is the
implementor
Default ACL lets Bob
invoke everything
Bob:{doStuff(int),
doMoreStuff(char)}
doStuff(int i);
doMoreStuff(char j);
…
CS711 - 8 Sept 2003
7
Example 1: Transferring ownership
Current Principal: Bob
o:C
Bob modifies ACL to let
Alice invoke all methods
Owner: Bob
MP: Acme-Corp.
ACL:
Bob:{doStuff(int),
doMoreStuff(char)}
Alice:{doStuff(int),
doMoreStuff(char)}
doStuff(int i);
doMoreStuff(char j);
…
CS711 - 8 Sept 2003
8
Example 1: Transferring ownership
Current Principal: Bob
o:C
Bob transfers ownership
to Alice
Owner: Alice
MP: Acme-Corp.
ACL:
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:{doStuff(int),
doMoreStuff(char)}
Alice:{doStuff(int),
doMoreStuff(char)}
doStuff(int i);
doMoreStuff(char j);
…
CS711 - 8 Sept 2003
9
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
o:C
Owner: Alice
MP: Alice
ACL:
Bob:{doStuff(int),
doMoreStuff(char)}
Alice:{doStuff(int),
doMoreStuff(char)}
doStuff(int i);
doMoreStuff(char j);
…
CS711 - 8 Sept 2003
10
Example 2: Limited trust
bobLaser:Printer
Owner: Bob
MP: Bob
cv:Document
Owner: Alice
MP: Alice
ACL:
ACL:
print(Document d);
getText();
Alice:{print(Document)}
Alice:{getText()}
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
11
Example 2: Limited trust
bobLaser:Printer
Owner: Bob
MP: Bob
cv:Document
Owner: Alice
MP: Alice
ACL:
ACL:
print(Document d);
getText();
Alice:{print(Document)}
Alice:{getText()}
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
12
Example 2: Limited trust
bobLaser:Printer
Owner: Bob
MP: Bob
cv:Document
Owner: Alice
MP: Alice
ACL:
ACL:
print(Document d);
getText();
Alice:{print(Document)}
Alice:{getText()}
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 BobAsPrinterOwner should be
given access…
CS711 - 8 Sept 2003
13
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
14
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
15
Cf. Java Stack Inspection
Java stack inspection has
Finer granularity?
• Arbitrary checkPrivilege() calls, instead of permethod invocation
More restricted notion of Principal?
A model that seems indifferent to OO?
CS711 - 8 Sept 2003
16
Discussion points/Questions
What is trust in this model?
What other mechanisms are required?
Effective type = static type allowed type.
Need runtime type checking.
A useful way to think about it?
Does it allow more static analysis?
Usability
Code certificates? (who implemented the code, who gives their authority to
which code?)
Dynamic way of determining implementor?
Effective types
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
CS711 - 8 Sept 2003
17