1. Static Enforcement of Security with Types Christian Skalka and Scott Smith Johns Hopkins University

2. Background: PL Security Non-local execution of code (e.g. Applets) presents new security problems Some PLs provide user-level abstractions for security (Ambit, Spi-calculus, Java) Built-in mechanisms allow expression and enforcement of various models/policies

3. Varieties of Security Dataflow ensures security of data Certified Code (PCC) is an extremely general framework for extensible code security Access Control is a flexible system of code ownership and resource authorization

4. Varieties of Security Dataflow ensures security of data Certified Code (PCC) is an extremely general framework for extensible code security Access Control is a flexible system of code ownership and resource authorization

5. Overview Background: PL Security Java JDK 1.2 and stack inspection Using types instead of stack inspection Security Types: formal properties Possible improvements Work in Progress Conclusion

6. Java Security Java JDK 1.2 provides a system for access control and code security –possibly non-local program execution requires protection of resources All code has a specified owner, granted certain privileges locally Resources are protected by a dynamic check (stack inspection)

7. Stack Inspection Stack frames are annotated with names of owners and any enabled privileges During inspection, stack frames are searched from most to least recent: –fail if a frame belonging to someone not authorized for privilege is encountered –succeed if activated privilege is found in frame

8. Example: privileged printing privPrint(f) = (* owned by system *) { checkPrivilege(PrintPriv); print(f); } foreignProg() = (* owned by Joe *) { …; privPrint(file); …; }

9. Stack Inspection (* local policy *) AccessCreds = { Joe = {???},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

10. Stack Inspection (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

11. Stack Inspection system Main (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

12. Stack Inspection system PrintPriv system PrintPriv Main (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

13. Stack Inspection system PrintPriv system PrintPriv joe Main foreignProg (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

14. Stack Inspection system PrintPriv system PrintPriv joe system Main foreignProg privPrint (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

15. Stack Inspection system PrintPriv system PrintPriv joe system Main foreignProg privPrint (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

16. Stack Inspection system PrintPriv system PrintPriv joe system Main foreignProg privPrint success (* local policy *) AccessCreds = { Joe = {PrintPriv},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

17. Stack Inspection (* local policy *) AccessCreds = { Joe = {},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

18. Stack Inspection system PrintPriv system PrintPriv joe system Main foreignProg privPrint (* local policy *) AccessCreds = { Joe = {},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

19. Stack Inspection system PrintPriv system PrintPriv joe system Main foreignProg privPrint failure (* local policy *) AccessCreds = { Joe = {},… } (* owned by system *) enablePriv(PrintPriv); foreignProg();

20. Why Stack Inspection? How is it different from a capability system? Why not just use an access control matrix and a global set of allowable privileges? –Privileges not held by current code owner are removed from allowable set

21. Stack Inspection: Callbacks Stack inspection allows security contexts to be temporarily raised.

22. Stack Inspection: Callbacks (* owned by system *) getIPaddr(url) = { checkPriv(IPPriv); addr = IPlookup(url); return addr; } Stack inspection allows security contexts to be temporarily raised:

23. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this);

24. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe getMyIP

25. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe system getMyIP appletIP

26. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe system IPPriv system IPPriv getMyIP appletIP

27. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe system IPPriv system IPPriv joe getMyIP appletIP this.source

28. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe system IPPriv system IPPriv getMyIP appletIP

29. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe system IPPriv system IPPriv system getMyIP appletIP getIPaddr

30. Callbacks (* owned by system *) appletIP(applet) = { enablePriv(IPPriv); url = applet.source(); return getIPaddr(url); } (* owned by Joe, not authorized for IPPriv *) getMyIP() = appletIP(this); joe system IPPriv system IPPriv system getMyIP appletIP getIPaddr success

31. A Static Approach Our thesis: types can statically enforce the Java security model. Unsafe programs rejected at compile time Need for runtime checks eliminated Types are a declaritive form of security policy expression and enforcement

32. Security Type Examples (* privPrint needs PrintPriv *) privPrint : file -{PrintPriv}-> unit (* PrintPriv in AccessCreds(Joe) *) foreignProg : unit -{PrintPriv}-> t (* PrintPriv not in AccessCreds(Joe) *) foreignProg : *ERROR*, cannot be typed

33. Security Type Examples (* enables SomePriv for parameter f *) privWrap(f) = { enablePriv(SomePriv); f(); } privWrap : ( unit -{SomePriv}-> unit) -{}-> unit

34. Subtyping Security Types With monotypes, subtypes allow typing of more safe programs: –privWrap can safely use the identity function id, so privWrap(id) should be typable id : unit -{}-> unit privWrap : ( unit -{SomePriv}-> unit) -{}-> unit

35. Subtyping Security Types Security requirements may safely be overestimated C (fnlt) u  ’’  ’  ’ C   ’  ’  ’ unit -{}-> unit unit privWrap(id) : unit

36. Security Type Judgements

37.  p checkPriv  for e :   p e :  (checkpriv) u  Security Type Judgements

38.  p ee’ :   p e :  ’  p e’ :  ’ ’’  u ’’  (appl)  p checkPriv  for e :   p e :  (checkpriv) u  Security Type Judgements

39.  p ee’ :   p e :  ’  p e’ :  ’ ’’  u ’’  (appl)  p checkPriv  for e :   p e :  (checkpriv) u   p enablePriv  for e :   u  p e :  (enablepriv) u  A(p) Security Type Judgements

40. Formal Properties of the System S, Ae v S  (p,  ) :: S’ S, Ae secfail Stack Inspection is modeled in a language with well-defined operational semantics: (secstacks) Unsafe expressions reduce to secfail:

41. Formal Properties of the System We prove subject reduction and type safety results for the system –Well-typed programs are not unsafe. We prove soundness and completeness results for a type inference algorithm –type system can be transparently layered over existing system

42. Type Inference Algorithm is standard constraint inference, plus a new constraint satisfiability check: –Privilege sets may contain variables –Privilege set variable constraints may be recursive Satisfiability check is novel, efficient; correctness is proved

43. Incompleteness of the System Java privileges are first-class Java programs can conditionally branch on presence/absence of privileges Paramaterized privileges, e.g.: fileRead(filename) Dynamic access control lists

44. Work in Progress Extend type system to accurately type privilege tests Polymorphism More sophisticated language features (Java features, modules) Readability of types

45. Conclusion Java security model is sound, but dynamic checks impose penalties Types can be used to enforce the model, and eliminate these penalties Security Types may be inferred efficiently http://www.cs.jhu.edu/~ces/work.html

46. Conclusion Java security model is sound, but dynamic checks impose penalties Types can be used to enforce the model, and eliminate these penalties Security Types may be inferred efficiently http://www.cs.jhu.edu/~ces/work.html

47. Conclusion Java security model is sound, but dynamic checks impose penalties Types can be used to enforce the model, and eliminate these penalties Security Types may be inferred efficiently http://www.cs.jhu.edu/~ces/work.html

48. Conclusion Java security model is sound, but dynamic checks impose penalties Types can be used to enforce the model, and eliminate these penalties Security Types may be inferred efficiently http://www.cs.jhu.edu/~ces/work.html

49. Conclusion Java security model is sound, but dynamic checks impose penalties Types can be used to enforce the model, and eliminate these penalties Security Types may be inferred efficiently http://www.cs.jhu.edu/~ces/work.html