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

2. COS 597B2 Security Talks this Week  My Dad's Computer, Microsoft, and the Future of Internet Security.  Bill Cheswick, Lumeta, co-inventor of the Internet firewall  Today at 4PM (We’ll stop class early)  Extensible Semantics for XrML  Vicky Weissman, Cornell  Friday at 2:30, CS 402  XrML (the eXtensible rights Markup Language) is a popular language in which to write software licenses. See what it is all about and how to give it a semantics.

3. COS 597B3 Types for Stack Inspection  Want to do static checking of sec code  Statically detect security failures.  Eliminate redundant checks.  Example of nonstandard type system for enforcing security properties.  Type system based on work by Pottier, Skalka, and Smith:  “A Systematic Approach to Static Access Control”  Explain the type system by taking a detour through “security-passing” style.  Wallach’s & Felten’s “Understanding Stack Inspection”

4. COS 597B4 Security-passing Style  Basic idea: Convert the “stack-crawling” form of stack inspection into a “permission-set passing style”  Compute the set of current permissions at any point in the code.  Make the set of permissions explicit as an extra parameter to functions (hence “security-passing style)  Target language is a lambda calculus with a primitive datatype of sets.

5. COS 597B5 Target Language: set  Language syntax: e,f ::= expressions xvariable x.efunction e fapplication fail failure let x = e in f local decl. if p  se then e else f member test seset expr.  se ::= S perm. set se  seunion se  se intersection x

6. COS 597B6 Translation: sec to set [[e]]R = “translation of e in domain R with s = current permissions” [[x]]R = x [[ x.e]]R = x. s.[[e]]R [[e f]]R = [[e]]R [[f]]R s [[let x = e in f]]R = let x = [[e]]R in [[f]R [[enable p in e]]R = let s = s  ({p}  R) in [[e]]R [[R’{e}]]R = let s = s  R’ in [[e]]R’ [[check p e]]R= if p  s then [[e]]R else fail [[test p then e1 else e2]]R= if p  s then [[e1]]R else [[e2]]R Top level translation: [[e]] = [[e]]P{P/s}

7. COS 597B7 Example Translation System = {“f1, “f2”, “f3”} Applet = {“f1”} h = System{enable “f1” in Applet{( x. System{check “f1” then write x}) “kwijibo”}}

8. COS 597B8 Example Translation [[h]] = (* System *) let s = P  {“f1”, “f2”, “f3”} in (* enable “f1” *) let s = s  ({“f1”}  {“f1”, “f2”, “f3”}) in (* Applet *) let s = s  {“f1”} in ( x. s. (* System *) let s = s  {“f1”, “f2”, “f3”} in if “f1”  s then write x else fail) “kwijibo” s

9. COS 597B9 Example Translation [[h]] = (* System *) let s = P  {“f1”, “f2”, “f3”} in (* enable “f1” *) let s = s  ({“f1”}  {“f1”, “f2”, “f3”}) in (* Applet *) let s = s  {“f1”} in ( x. s. (* System *) let s = s  {“f1”, “f2”, “f3”} in if “f3”  s then write x else fail) “kwijibo” s Change permission check

10. COS 597B10 Stepping Back  Have two formulations of stack inspection: “original” and “eager”  Have a translation to a language that manipulates sets of permissions explicitly.  Includes the “administrative” reductions that just compute sets of permissions.  Similar computations can be done statically!

11. COS 597B11 Typing Judgments R;S;  |-- e : t Current protection domain Subset of current runtime perms Variable context Term Type

12. COS 597B12 Form of types  Only interesting (non administrative) change during compilation was for functions: [[ x.e]]R = x. s.[[e]]R  Source type: t  u  Target type: t  s  u  The 2 nd argument, is always a set, so we “specialize” the type to: t –{S}  u

13. COS 597B13 Types  Types: t ::= types int, string, …base types t –{S}  tfunctions

14. COS 597B14 Simple Typing Rules R;S;  |-- x :  (x) R;S;  |-- x.e : t1 –{S’}  t2 R;S’; ,x:t1 |-- e : t2 Abstraction: Variables:

15. COS 597B15 More Simple Typing Rules R;S;  |-- e f : t’ R;S;  |-- e : t –{S}  t’ R;S;  |-- f : t Application: R;S;  |-- let x = e in f : t R;S;  |-- e : u R;S; ,x:u |-- f : t Let:

16. COS 597B16 Rule for Check R; S  {p};  |-- check p then e : t R; S  {p};  |-- e : t Note that this typing rule requires that the permission p is statically known to be available.

17. COS 597B17 Typing Rules for Enable Enable fail: R;S;  |-- enable p in e : t R;S;  |-- e : t p  R Enable succeed: R;S;  |-- enable p in e : t R;S  {p};  |-- e : t p  R -- latter should be flagged as useless code

18. COS 597B18 Rule for Test R;S;  |-- test p then e else f: t R;S;  |-- f : t R; S  {p};  |-- e : t Check the first branch under assumption that p is present, check the else branch under assumption that p is absent.

19. COS 597B19 Rule for Protection Domains R;S;  |-- S’{e}: t S’;S  S’;  |-- e : t Intersect the permissions in the static protection domain with the current permission set.

20. COS 597B20 Weakening (Subsumption) R;S;  |-- e : t R;S’;  |-- e : tS’  S It is always safe to “forget” permissions.

21. COS 597B21 Type Safety  Theorem: If P;P;  |-- e : t then either e  * v or e diverges.  In particular: e never fails. (i.e. check always succeeds)  Proof: Preservation & Progress.

22. COS 597B22 Example: Good Code h = System{enable “f1” in Applet{( x. System{check “f1” then write x}) “kwijibo”}} Then P;S;  |-- h : unit for any S

23. COS 597B23 Example: Bad Code g = System{enable “f1” in Applet{( x. System{check “f2” then write x}) “kwijibo”}} Then R;S;  |-- g : t is not derivable for any R,S, and t.

24. COS 597B24 Static vs. Dynamic Checks  ;  ;  |--  x.check p in x : int –{p}  int Calling this function requires the static permission p: Only way to call it (assuming initial perms. are empty) is to put it in the scope of a dynamic test: test p then …can call it here… else …may not call it here…

25. COS 597B25 Expressiveness  This type system is very simple  No subtyping  No polymorphism  Not algorithmic  Hard to do inference  Can add all of these features…  See François Pottier’s paper for a nice example.  Uses Didier Rémy’s row types to describe the sets of permission.  Uses HM(X) – Hindley Milner with constraints  Also shows how to derive a type system for the source language from the translation!

26. COS 597B26 Conclusions  Stack inspection is a complex security mechanism  In practice, useful for preventing some attacks  Formal reasoning useful for understanding what optimizations preserve semantics  Type systems or program analysis have the potential to catch “obvious” security violations at compile time where they can easily be fixed