Static support for capabilities

1. Static support for capabilities Vijay Saraswat IBM TJ Watson Research Lab (work done at Penn State) Radha Jagadeesan School of CTI, De Paul http://www.cse.psu.edu/~saraswat/neighborhood.pdf

2. Outline • Capability languages • The problem of confinement • Examples • Object Reference Graph • Transformations • The basic idea: neighborhoods • Type rules for confined, contained. • Portals • Additional work: keys

3. Objects Encapsulated bundles of state and action May Be Created Stored/Retrieved Transmitted Be Acted on Capability =def= object ref Subject = object Subject =def= source of change/action in the system. Authority = possession of capability Authority =def= capacity to perform an action No static object designators No ambient authority: only connectivity begets connectivity; must select authority when performing an access. Types are interfaces No closed world assumption about known classes. (Interfaces augmented with assertions) Object-oriented Capability Languages Example Languages: E, (statically typed) M (Java-)

4. No designation without authority To designate something is to have the authority to perform some actions on it. Dynamic subject creation Subjects (security principals) are just other objects Open world assumption Subject-aggregated authority management No access control lists. Subject has a list of capabilities it can use. Authorities are composable The object pointed to by a capability may itself possess capabilities Access controlled delegation X must have access to Y to pass an authority to Y. Properties of Object-oriented Capability Languages Miller and Shapiro, ASIAN 2003

5. Capability copying + check on access = *-property violation Alice (low) (loReader),loWriter (hiWriter) Bob (high) hiReader,(hiWriter) loReader Required: Bob should not be able to write on lo (exercise loWriter) Confinement Problem interface Reader {Object read();} interface Writer {void write (Object a);} interface ReaderWriter extends Reader, Writer {} … // Alice loWriter.write(loWriter); … // Bob Object secret = hiReader.read(); Writer trapdoor =(Writer)loReader.read(); trapdoor.write(secret); Problem: Alice can pass data, Bob can treat it as a capability and exercise it.

6. You give 3d party Tax software your data Who has access? Alice enters room programmed by untrusted Charlie. Who can access rights to talk to her? (Harder) Can they do it after she has left the room? Solution: Use factories. Many drawbacks Confinement Problem: Other examples

7. Basic intuition • We can devise usable static type rules to enforce confinement • Identify notion of private state • Based purely on graph-theoretic (connectivity) notions • Allow method to specify that received parameters will circulate only to objects in private state • Thus: Type correctness => confinement • This can be done while supporting separate compilation for classes.

8. (Cumulative) Object Reference Graph • (Typed) Nodes =objects • Edges = references • Four basic operations • Create • Give • Get • Delete • The effect of all programs may be abstracted merely by a sequence of these transformations. • Cumulative ORG: no delete • We will work with CORGs. • Easier to deal with statically. TOMS model: Motwani, Venkatsubramaniam, Panigrahy, Saraswat (STOC 2000)

9. Def: n(o), neighborhood of an object o: p in n(o) if for any q st q->p, q=o or q in n(o) o -*-> p Finding neighborhoods: Remove from *(o) all elements that have an incoming edge from outside *(o). Def: N is a neighborhood if N=n(o), for some o. o is a root of N. Def: N is connected if it has an incoming edge from outside N Properties N may hold outgoing edges. n(o) may be empty N and N’ overlap implies one is contained in the other Thus neighborhoods may be nested. n(p) subset N if p in N (non-empty) N is connected iff it does not contain one of its roots. A connected neighborhood has a unique root. Neighborhoods Connected with dominators

10. We label each object in the (C)ORG with an object o(p) is read as: object p is the label for object o. Label is established when an object is created, and does not change during its lifetime. Think: label is stored in a final field on the object. An object o is free =def= o(o) An object that is not free is said to be confined. A reference to a free object p(p) is said to be contained in n(o) if it is accepted by a free object o(o) and can be propagated only through confined links. Edges will be labeled as well: f: free (the original kind) c: confined Free and confined objects

11. If Alice is not to be able to propagate loWriter freely, then loWriter must be communicated to Alice at a confined type. Now loWriter cannot be communicated to any free object: confined objects cannot be passed as args to method invocations on confined objects Example: Information leakage revisited interface Reader {Object read();} interface Writer {void write (Object a);} interface ReaderWriter extends Reader, Writer {} … // Alice contained Writer loWriter = … loWriter.write(loWriter); // FAILS … // Bob Object secret = hiReader.read(); Writer trapdoor =(Writer)loReader.read(); trapdoor.write(secret);

12. Confined edges • Transformation rules • Free • Create • Give • Get • Confined • Create • Give • Get • Not permitted: • Cannot give/get confined object into/from a free object Confined edges approximate neighborhoods.

13. Basic Theorem • Let G0 be a single node graph a0(a0). • Let G=G0,G1,G2 be a sequence of graphs obained by applying these rules. Then in any Gn: • a(o) –c c(q) implies o=q • a(o) –c c(q) implies all edges into c(q) are confined edges. • a(o) implies a in {o} u n(o)

14. Contained edges • Introduce contained edges (t) • Transformation rules: • Contained edges may be created through give or get (on any edge). • Contained edges may be propagated (via give/get) only through confined edges. • Free edges (not confined or contained edges) may be propagated through contained edges. Contained edges stay within the neighborhood.

15. Basic Theorem: Confinement • Associate each contained edge with the set s of nodes responsible for its creation. • Confinement Theorem: In any Gn (defined as before): • a(o) –t(s) b(q) implies label of each object in s is o. • a(o) –t(s) b(q) cannot cause the introduction of an edge into b(q) other than a contained edge.

16. Consider a vector implementation Cells representing elements should be considered to be in the private state of the vector However a VectorIterator should be allowed access to these cells. A portal for an object o is an object p (labeled with o) that may access objects in n(o), but may be propagated freely outside n(o). Need for portals: Vector iterators

17. Def: n(s), neighborhood of a set of objects s: p in n(s) if for any q st q->p, q in s u n(s) *(s) contains n(s) Note: n(o) = n({o}) n({})={} Intuition: Multi-neighborhoods are disjunctive neighborhoods. We should not permit two neighborhoods to be joined: this loses containment. Instead, we permit objects in a neighborhood to be “freed”. Def: A neighborhood n(s) is said to be generated by o if all objects in s are labeled by o. Multi-neighborhoods

18. Portals into multi-neighborhoods • Allow an object to possess a free reference to itself (this). • Confined nodes may “leak” free references (e.g. iterators) • But a free reference cannot be used to access contained state. • Confinement Theorem unchanged! Contained edges stay within the neighborhood, even with portals.

19. Compare with Information Flow – introduce confined(k), for k an object. SFKASI – different way of getting protection domains in Java. Alias control, ownership types, containment types Similar intuitions … but their development is complicated! Develop static analysis for other capability programming patterns. Exploit ORG! Understand connection with BI logic. Future work

20. Introducing Portals.