1. Current Techniques in Language-based Security David Walker COS 441 With slides stolen from: Steve Zdancewic University of Pennsylvania

2. COS 4412 Mobile Code  Modern languages like Java and C# have been designed for Internet applications and extensible systems  PDAs, Cell Phones, Smart Cards, … operating system web browser applet

3. COS 4413 Applet Security Problems  Protect OS & other valuable resources.  Applets should not:  crash browser or OS  execute “rm –rf /”  be able to exhaust resources  Applets should:  be able to access some system resources (e.g. to display a picture)  be isolated from each other  Principles of least privileges and complete mediation apply

4. COS 4414 Java and C# Security  Static Type Systems  Memory safety and jump safety  Run-time checks for  Array index bounds  Downcasts  Access controls  Virtual Machine / JIT compilation  Bytecode verification  Enforces encapsulation boundaries (e.g. private field)  Garbage Collected  Eliminates memory management errors  Library support  Cryptography, authentication, … These lectures

5. COS 4415 Access Control for Applets  What level of granularity?  Applets can touch some parts of the file system but not others  Applets can make network connections to some locations but not others  Different code has different levels of trustworthiness  www.l33t-hax0rs.com vs. www.java.sun.com  Trusted code can call untrusted code  e.g. to ask an applet to repaint its window  Untrusted code can call trusted code  e.g. the paint routine may load a font  How is the access control policy specified?

6. COS 4416 Outline  Java Security Model (C# similar)  Stack inspection  Concrete examples  To discuss: what security principles does the Java security model obey or not obey?  Semantics from a PL perspective  Formalizing stack inspection  how exactly does it work?  Reasoning about programs that use stack inspection

7. COS 4417 Java Security Model a.class b.class c.class d.class e.class Domain A Domain B Permissions Security PolicyVM Runtime http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-specTOC.fm.html Classloader SecurityManager

8. COS 4418 Kinds of Permissions  java.security.Permission Class perm = new java.io.FilePermission("/tmp/abc","read"); java.security.AllPermission java.security.SecurityPermission java.security.UnresolvedPermission java.awt.AWTPermission java.io.FilePermission java.io.SerializablePermission java.lang.reflect.ReflectPermission java.lang.RuntimePermission java.net.NetPermission java.net.SocketPermission …

9. COS 4419 Code Trustworthiness  How does one decide what protection domain the code is in?  Source (e.g. local or applet)  Digital signatures  C# calls this “evidence based”  How does one decide what permissions a protection domain has?  Configurable – administrator file or command line  Enforced by the classloader

10. COS 44110 Classloaders  In order to pull new code into the virtual machine, we use an object from the ClassLoader class  A class loader will look in the file system, or across the network for a class file, or possibly dynamically generate the class  When loading the first class of an application, a new instance of the URLClassLoader is used.  When loading the first class of an applet, a new instance of the AppletClassLoader is used.  Class loaders are responsible for placing classes into their security domains  AppletClassLoader places classes in domains depending on where they are from  Other ClassLoaders places classes in domains based on digital signatures, or origin (such as local file system)

11. COS 44111 Classloader Hierarchy ClassLoader SecureClassLoaderURLClassLoader AppletClassLoader Primordial ClassLoader

12. COS 44112 Associating Privileges with Domains grant codeBase “http://www.l33t-hax0rz.com/*” { permission java.io.FilePermission(“/tmp/*”, “read,write”); } grant codeBase “file://$JAVA_HOME/lib/ext/*” { permission java.security.AllPermission; } grant signedBy “trusted-company.com” { permission java.net.SocketPermission(…); permission java.io.FilePermission(“/tmp/*”, “read,write”); … } Policy information stored in: $JAVA_HOME/lib/security/java.policy $USER_HOME/.java.policy (or passed on command line)

13. COS 44113 Example Trusted Code void fileWrite(String filename, String s) { SecurityManager sm = System.getSecurityManager(); if (sm != null) { FilePermission fp = new FilePermission(filename,“write”); sm.checkPermission(fp); /* … write s to file filename (native code) … */ } else { throw new SecurityException(); } public static void main(…) { SecurityManager sm = System.getSecurityManager(); FilePermission fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } Code in the System protection domain

14. COS 44114 Example Client class UntrustedApplet { void run() {... s.FileWrite(“/tmp/foo.txt”, “Hello!”);... s.FileWrite(“/home/dpw/grades.txt”, “Ginsburg: A+”);... } Applet code obtained from http://www.l33t-hax0rz.com/

15. COS 44115 Stack Inspection  Stack frames are annotated with their protection domains 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

16. COS 44116 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } Policy Database

17. COS 44117 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } fp Policy Database

18. COS 44118 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } void run() { … s.FileWrite(“/tmp/foo.txt”, “Hello!”); … } fp Policy Database

19. COS 44119 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } void run() { … s.FileWrite(“/tmp/foo.txt”, “Hello!”); … } void fileWrite(“/tmp/foo.txt”, “Hello!”) { fp = new FilePermission(“/tmp/foo.txt”,“write”) sm.checkPermission(fp); /* … write s to file filename … */ fp Policy Database

20. COS 44120 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } void run() { … s.FileWrite(“/tmp/foo.txt”, “Hello!”); … } void fileWrite(“/tmp/foo.txt”, “Hello!”) { fp = new FilePermission(“/tmp/foo.txt”,“write”) sm.checkPermission(fp); /* … write s to file filename … */ fp Policy Database Succeed!

21. COS 44121 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } void run() { … s.FileWrite(“/home/dpw/grades.txt”, “Ginsburg: A+”); } fp Policy Database

22. COS 44122 Stack Inspection Example main(…){ fp = new FilePermission(“/tmp/*”,“write,…”); sm.enablePrivilege(fp); UntrustedApplet.run(); } void fileWrite(“…/important.txt”, “kwijibo”) { fp = new FilePermission(“important.txt”, “write”); sm.checkPermission(fp); fp Policy Database void run() { … s.FileWrite(“/home/dpw/grades.txt”, “Ginsburg: A+”); } Fail

23. COS 44123 Other Possibilities  The fileWrite method could enable the write permission itself  Potentially dangerous, should not base the file to write on data from the applet  … but no enforcement in Java  A trusted piece of code could disable a previously granted permission  Terminate the stack inspection early

24. COS 44124 Stack Inspection Algorithm checkPermission(T) { // loop newest to oldest stack frame foreach stackFrame { if (local policy forbids access to T by class executing in stack frame) throw ForbiddenException; if (stackFrame has enabled privilege for T) return; // allow access if (stackFrame has disabled privilege for T) throw ForbiddenException; } // end of stack if (Netscape || …) throw ForbiddenException; if (MS IE4.0 || JDK 1.2 || …) return; }

25. COS 44125 Two Implementations  On demand –  On a checkPermission invocation, actually crawl down the stack, checking on the way  Used in practice  Eagerly –  Keep track of the current set of available permissions during execution (security-passing style Wallach & Felten) + more apparent (could print current perms.) -more expensive (checkPermission occurs infrequently)

26. COS 44126 Stack Inspection  Stack inspection seems appealing:  Fine grained, flexible, configurable policies  Distinguishes between code of varying degrees of trust  But…  How do we understand what the policy is?  Semantics tied to the operational behavior of the program (defined in terms of stacks!)  How do we compare implementations  Changing the program (e.g. optimizing it) may change the security policy  Policy is distributed throughout the software, and is not apparent from the program interfaces.  Is it any good?

27. COS 44127 Stack Inspection Literature  Stack Inspection: Theory and Variants Cédric Fournet and Andrew D. Gordon  Use operational semantics like in class  Understanding Java Stack Inspection Dan S. Wallach and Edward W. Felten  Formalize Java Stack Inspection using a special logic of authentication

28. Formalizing Stack Inspection

29. COS 44129 Abstract Stack Inspection  Abstract permissions  p,q Permissions (left abstract in the theory)  R,S Principals (sets of permissions)  Hide the details of classloading, etc.  Examples: System = {fileWrite(“f1”), fileWrite(“f2”),…} Applet = {fileWrite(“f1”)}

30. COS 44130 sec Syntax  Language syntax: e ::= expressions xvariable x.efunction e1 e2application R{e}framed expr enable p in eenable test p then e1 else e2check perm. fail failure v ::= x | x.evalues o ::= v | failoutcome

31. COS 44131 Framing a Term  Models the Classloader that marks the (unframed) code with its protection domain: Load(R,x) = x Load(R, x.e)= x. R{ Load(R,e) } Load(R,e1 e2)= Load(R,e1) Load(R,e2) Load(R,enable p in e) = enable p in Load(R,e) Load(R,test p then e2 else e2) = test p then Load(R,e1) else Load(R,e2) Load(R,fail) = fail

32. COS 44132 Example readFile = fileName.System{ test fileWrite(fileName) then … // primitive file IO (native code) else fail } Applet{readFile “f2”} -->* fail System{readFile “f2”} -->*

33. COS 44133 sec Operational Semantics  Evaluation contexts: E ::= [] Hole E e Eval function v E Eval arg enable p in E Tag on stack frame R{E} Stack frame  E models the control stack

34. COS 44134 sec Operational Semantics E[(lx.e) v]--> E[e{v/x}] E[enable p in v]--> E[v] E[R{v}] --> E[v] E[fail] --> fail E[test p then e else f] --> E[e] if Stack(E) |-- p E[test p then e else f] --> E[f] if  (Stack(E) |-- p)

35. COS 44135 Example Evaluation Context Applet{readFile “f2”} E = Applet{[]} r = readfile “f2”

36. COS 44136 Example Evaluation Context E = Applet{[]} r = ( fileName.System{ test fileWrite(fileName) then … // primitive file IO (native code) else fail } ) “f2” Applet{readFile “f2”}

37. COS 44137 Example Evaluation Context Applet{readFile “f2”} E = Applet{[]} r = System{ test fileWrite(“f2”) then … // primitive file IO (native code) else fail }

38. COS 44138 Example Evaluation Context Applet{System{ test fileWrite(“f2”) then … // primitive file IO (native code) else fail }}

39. COS 44139 Example Evaluation Context Applet{System{ test fileWrite(“f2”) then … // primitive file IO (native code) else fail }} E’ = Applet{System{[]}} r’ = test fileWrite(“f2”) then … // primitive file IO (native code) else fail

40. COS 44140 Formal Stack Inspection E’ = Applet{System{[]}} r’ = test fileWrite(“f2”) then … // primitive file IO (native code) else fail When does stack E’ allow permission fileWrite(“f2”)? Stack(E’) |-- fileWrite(“f2”)

41. COS 44141 Formal Stack Inspection Structure of Stacks: s ::=. (Empty Stack) | s.R (Stack for code of principal R) | s.enable(p)(Privelege p enabled)

42. COS 44142 Stack of an Eval. Context Stack([]) =. Stack(E e) = Stack(E) Stack(v E) = Stack(E) Stack(enable p in E) = enable(p).Stack(E) Stack(R{E}) = R.Stack(E) Stack(E’) = Stack(Applet{System{[]}}) = Applet.Stack(System{[]}) = Applet.System.Stack([]) = Applet.System.

43. COS 44143 Abstract Stack Inspection. |-- p empty stack axiom s |-- p p  R s.R |-- p s |-- p s.enable(q) |-- p protection domain check p  q irrelevant enable s |= p s.enable(p) |-- p check enable

44. COS 44144 Abstract Stack Inspection. |= p empty stack enables all p  R x.R |= p enable succeeds x |= p x.enable(q) |= p irrelevant enable

45. COS 44145 Equational Reasoning e  iff there exists o such that e -->* o Let C[] be an arbitrary program context. Say that e = e’ iff for all C[], if C[e] and C[e’] are closed then C[e]  iff C[e’] .

46. COS 44146 Example Inequality ok = x.x loop = ( x.x x)( x.x x) (note: loop  ) f = x. let z = x ok in _.z g = x. let z = x ok in _.(x ok) Claim: f ≠ g Proof: Let C[] =  {[ ] _.test p then loop else ok} ok

47. COS 44147 Example Continued C[f]=  {f _.test p then loop else ok} ok   {let z = ( _.test p then loop else ok) ok in _.z} ok   {let z = test p then loop else ok in _.z} ok   {let z = ok in _.z} ok   { _.ok} ok  ( _.ok) ok  ok stack(  { [ ] }) =.. ..  |-- p is not valid

48. COS 44148 Example Continued C[g]=  {g _.test p then loop else ok} ok   {let z = ( _.test p then loop else ok) ok in _.(( _.test p then loop else ok) ok)} ok   {let z = test p then loop else ok in _. (( _.test p then loop else ok) ok)} ok   {let z = ok in _. (( _.test p then loop else ok) ok)} ok   { _. (( _.test p then loop else ok) ok)} ok  ( _. (( _.test p then loop else ok) ok)) ok  ( _.test p then loop else ok) ok  test p then loop else ok  loop  loop  loop  … stack([ ] ) =.. |-- p is valid! return from function ==> pop frame

49. COS 44149 Example Applications Eliminate redundant annotations: x.R{ y.R{e}} = x. y.R{e} Decrease stack inspection costs: e = test p then (enable p in e) else e Formal reasoning about the semantics of stack inspection makes it possible to perform safe optimizations:

50. COS 44150 Axiomatic Equivalence Can give a sound set of equations  that characterize =. Example axioms: ( x.e) v  e{v/x} (beta equivalence) x  fv(v)  x.v  v enable p in o  o enable p in (enable q in e)  enable q in (enable p in e) R  S  R{S{e}}  S{e} R{S{enable p in e}}  R  {p}{S{enable p in e}} … many, many more  Implies =

51. COS 44151 Example: Higher-order Code main = System [ h.(h ok ok)] fileHandler = System[ s. c. _.c (readFile s)] leak = Applet[ s.output s] main( _.Applet{fileHandler “f2” leak})

52. COS 44152 Example: Higher-order Code main( _.Applet{fileHandler “f2” leak})  *System{Applet{fileHandler “f2” leak} okS}  *System{Applet{System{System{ _.System{leak (readFile “f2”)}}}} okS}  *System{ _.System{leak (readFile “f2”)} okS}  * System{System{leak }}  * System{System{Applet{output }}}  * System{System{Applet{ok}}}  * ok

53. COS 44153 Other Problems  Applets returning closures can circumvent stack inspection.  Possible solution:  Values of the form: R{v} (i.e. keep track of the protection domain of the source)  Similarly, one could have closures capture their current security context  Integrity analysis (i.e. where data comes from)  Fournet & Gordon prove some properties of strengthened versions of stack inspection.

54. COS 44154 Conclusions  What security properties does the Java security model guarantee?  What optimizations are legal?  Formal semantics helps us find the answers & suggests improvements