1 / 26

Current Techniques in Language-based Security

Current Techniques in Language-based Security. David Walker COS 597B With slides stolen from: Steve Zdancewic University of Pennsylvania. Security Talks this Week. My Dad's Computer, Microsoft, and the Future of Internet Security.

evelia
Download Presentation

Current Techniques in Language-based Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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. COS 597B

  3. Types for Stack Inspection • Want to do static checking of lsec 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” COS 597B

  4. 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. COS 597B

  5. Target Language: lset • Language syntax:e,f ::= expressions x variablelx.e function e f application fail failure let x = e in f local decl.if pse then e else f member test se set expr. • se ::= S perm. set se  se union se  se intersection x COS 597B

  6. Translation: lsec to lset • [[e]]R = “translation of e in domain R • with s = current permissions” • [[x]]R = x • [[lx.e]]R = lx.ls.[[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} COS 597B

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

  8. 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 (lx.ls.(* System *) let s = s  {“f1”, “f2”, “f3”} in if “f1”  s then write x else fail) “kwijibo” s COS 597B

  9. 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 (lx.ls.(* System *) let s = s  {“f1”, “f2”, “f3”} in if “f3” s then write x else fail) “kwijibo” s Change permission check COS 597B

  10. 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! COS 597B

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

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

  13. Types • Types:t ::= types int, string, … base types t –{S} t functions COS 597B

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

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

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

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

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

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

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

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

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

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

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

  25. 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! COS 597B

  26. 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 COS 597B

More Related