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

Slides:



Advertisements
Similar presentations
Towards Remote Policy Enforcement for Runtime Protection of Mobile Code Using Trusted Computing Xinwen Zhang Francesco Parisi-Presicce Ravi Sandhu
Advertisements

Substitution & Evaluation Order cos 441 David Walker.
November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #12-1 Chapter 12: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Primitive Recursive Functions (Chapter 3)
Foundational Certified Code in a Metalogical Framework Karl Crary and Susmit Sarkar Carnegie Mellon University.
Current Techniques in Language-based Security David Walker COS 597B With slides stolen from: Steve Zdancewic University of Pennsylvania.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
© M. Winter COSC 4P41 – Functional Programming Testing vs Proving Testing –uses a set of “typical” examples, –symbolic testing, –may find errors,
The Big Picture Chapter 3. We want to examine a given computational problem and see how difficult it is. Then we need to compare problems Problems appear.
Presented by Vaibhav Rastogi.  Advent of Web 2.0 and Mashups  Inclusion of untrusted third party content a necessity  Need to restrict the functionality.
David Evans CS655: Programming Languages University of Virginia Computer Science Lecture 19: Minding Ps & Qs: Axiomatic.
Ashish Kundu CS590F Purdue 02/12/07 Language-Based Information Flow Security Andrei Sabelfield, Andrew C. Myers Presentation: Ashish Kundu
Code-Carrying Proofs Aytekin Vargun Rensselaer Polytechnic Institute.
1 Design Principles CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute April 13, 2004.
Comp 205: Comparative Programming Languages Semantics of Imperative Programming Languages denotational semantics operational semantics logical semantics.
1 Introduction to Computability Theory Lecture15: Reductions Prof. Amos Israeli.
1 Introduction to Computability Theory Lecture12: Reductions Prof. Amos Israeli.
Current Techniques in Language- based Security Steve Zdancewic University of Pennsylvania.
Current Techniques in Language-based Security David Walker COS 441 With slides stolen from: Steve Zdancewic University of Pennsylvania.
1 Extensible Security Architectures for Java Authors: Dan S.Wallch, Dirk Balfanz Presented by Moonjoo Kim.
Applications of Programming Language Theory: Java Security David Walker COS 441 With slides stolen from: Steve Zdancewic University of Pennsylvania.
Information Flow, Security and Programming Languages Steve Steve Zdancewic.
1 Enforcing Confidentiality in Low-level Programs Andrew Myers Cornell University.
Catriel Beeri Pls/Winter 2004/5 type reconstruction 1 Type Reconstruction & Parametric Polymorphism  Introduction  Unification and type reconstruction.
Misc. Announcements Assignment available end of the day today –Due back in 11/03 (after break) Will also update slides on website –Today Midterm next week.
(Breather)‏ Principles of Secure Design by Matt Bishop (augmented by Michael Rothstein)‏
Static Enforcement of Security with Types Christian Skalka and Scott Smith Johns Hopkins University.
Winter 2004/5Pls – inductive – Catriel Beeri1 Inductive Definitions (our meta-language for specifications)  Examples  Syntax  Semantics  Proof Trees.
Programming Language Semantics Mooly SagivEran Yahav Schrirber 317Open space html://
A Type System for Expressive Security Policies David Walker Cornell University.
Dec Formal Semantics1 Programming Language Theory Formal Semantics Leif Grönqvist The national Graduate School of Language Technology (GSLT) MSI.
April 1, 2004ECS 235Slide #1 Chapter 1: Introduction Components of computer security Threats Policies and mechanisms The role of trust Assurance Operational.
Semantics with Applications Mooly Sagiv Schrirber html:// Textbooks:Winskel The.
Tim Sheard Oregon Graduate Institute Lecture 11: A Reduction Semantics for MetaML CS510 Section FSC Winter 2005 Winter 2005.
Mechanized Metatheory for User- Defined Type Extensions Dan Marino, Brian Chin, Todd Millstein UCLA Gang Tan Boston College Robert J. Simmons, David Walker.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
A Formal Model of Modularity in Aspect-Oriented Programming Jonathan Aldrich : Objects and Aspects Carnegie Mellon University.
The Impact of Programming Language Theory on Computer Security Drew Dean Computer Science Laboratory SRI International.
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
Announcements Assignment 3 due. Invite friends, co-workers to your presentations. Course evaluations on Friday.
CS 330 Programming Languages 11 / 21 / 2006 Instructor: Michael Eckmann.
CSE S. Tanimoto Lambda Calculus 1 Lambda Calculus What is the simplest functional language that is still Turing complete? Where do functional languages.
WXGE6103 Software Engineering Process and Practice Formal Specification.
Checking Reachability using Matching Logic Grigore Rosu and Andrei Stefanescu University of Illinois, USA.
Course Overview and Road Map Computability and Logic.
Copyright © Cengage Learning. All rights reserved. CHAPTER 8 RELATIONS.
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson.
© Kenneth C. Louden, Chapter 11 - Functional Programming, Part III: Theory Programming Languages: Principles and Practice, 2nd Ed. Kenneth C. Louden.
CSE Winter 2008 Introduction to Program Verification January 31 proofs through simplification.
A Microkernel Virtual Machine: Building Security with Clear Interfaces Xiaoqi LuScott Smith The Johns Hopkins University.
Naïve Set Theory. Basic Definitions Naïve set theory is the non-axiomatic treatment of set theory. In the axiomatic treatment, which we will only allude.
12/13/20151 Computer Security Security Policies...
LDK R Logics for Data and Knowledge Representation ClassL (part 2): Reasoning with a TBox 1.
(Breather)‏ Principles of Secure Design by Matt Bishop (augmented by Michael Rothstein)‏
Fall 2008CS 334: Computer SecuritySlide #1 Design Principles Thanks to Matt Bishop.
June 1, 2004Computer Security: Art and Science © Matt Bishop Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Copyright © Cengage Learning. All rights reserved. CHAPTER 8 RELATIONS.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
LINUX Presented By Parvathy Subramanian. April 23, 2008LINUX, By Parvathy Subramanian2 Agenda ► Introduction ► Standard design for security systems ►
Language-Based Information- Flow Security (Sabelfeld and Myers) “Practical methods for controlling information flow have eluded researchers for some time.”
Slide #13-1 Design Principles CS461/ECE422 Computer Security I Fall 2008 Based on slides provided by Matt Bishop for use with Computer Security: Art and.
COMP 412, FALL Type Systems C OMP 412 Rice University Houston, Texas Fall 2000 Copyright 2000, Robert Cartwright, all rights reserved. Students.
1 Jay Ligatti (Princeton University); joint work with: Lujo Bauer (Carnegie Mellon University), David Walker (Princeton University) Enforcing Non-safety.
Chapter 27 Security Engineering
Solving Equations and Inequalities with Absolute Value
Continuation Marks A john clements talk.
Bottom Up: Soundness and Completeness
CSE S. Tanimoto Lambda Calculus
Design Principles Thanks to Matt Bishop 2006 CS 395: Computer Security.
Presentation transcript:

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

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

COS 597B3 sec Syntax  Language syntax: e,f ::= expressions xvariable x.efunction e fapplication R{e}framed expr enable p in eenable test p then e else fcheck perm. fail failure v ::= x | x.evalues o ::= v | failoutcome

COS 597B4 Framing a Term  Models the Classloader that marks the (unframed) code with its protection domain: R[x] = x R[ x.e] = x.R{R[e]} R[e f] = R[e] R[f] R[enable p in e] = enable p in R[e] R[test p then e else f] = test p then R[e] else R[f] R[fail] = fail

COS 597B5 Example readFile = fileName.System{ test fileWrite(fileName) then … // primitive file IO (native code) else fail } Applet{readFile “f2”}  fail System{readFile “f2”} 

COS 597B6 sec Operational Semantics  Evaluation contexts: E ::= []Hole E eEval. Function v EEval. Arg. enable p in ETagged frame R{E} Frame  E models the control stack

COS 597B7 sec Operational Semantics E[( x.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) e  o iff e  * o Stack Inspection

COS 597B8 Example Evaluation Context Applet{readFile “f2”} E = Applet{[]} r = readFile “f2”

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

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

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

COS 597B12 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

COS 597B13 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”)

COS 597B14 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.

COS 597B15 Abstract Stack Inspection. |-- p empty stack axiom x |-- p p  R x.R |-- p x |-- p x.enable(q) |-- p protection domain check p  q irrelevant enable x |= p x.enable(p) |-- p check enable

COS 597B16 Abstract Stack Inspection. |= p empty stack enables all p  R x.R |= p enable succeeds* x |= p x.enable(q) |= p irrelevant enable * Enables should occur only in trusted code

COS 597B17 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’] .

COS 597B18 Equational Reasoning Question: Why not: e = e’ iff for all C[], if C[e] and C[e’] are closed then C[e]  o iff C[e’]  o’ and o = o’.

COS 597B19 Equational Reasoning Question: Why not: e = e’ iff for all C[], if C[e] and C[e’] are closed then C[e]  o iff C[e’]  o’ and o = o’. Reasoning is cyclic if o and o’ are functions x.e’’ and x.e’’’: we suddenly need to ask if e’’ = e’’’

COS 597B20 Equational Reasoning Question: Why not: e = e’ iff for all C[], if C[e] and C[e’] are closed then C[e]  o iff C[e’]  o’ and o = o’. If we want to test whether e  v and e’  v’ and v = v’ we can always do it using the appropriate context: C = if [ ] then loop () else ()

COS 597B21 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

COS 597B22 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

COS 597B23 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  loop  …

COS 597B24 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

COS 597B25 Axiomatic Equivalence Can give a sound set of equations  that characterize =. Example axioms:  is a congruence (preserved by contexts) ( x.e) v  e{v/x} (beta equivalence) 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}} …

COS 597B26 Example: Tail Calls Ordinary evaluation: R{( x.S{e}) v}  R{S{e{v/x}}} Tail-call eliminated evaluation: R{( x.S{e}) v}  S{e{v/x}} Not sound in general! But OK in special cases.

COS 597B27 Example: Tail Calls Suppose R  S. Then: R{( x.S{e}) v}  R{S{e{v/x}}}  S{e{v/x}}  S{e}{v/x} ( x.S{e}) v In particular, code within a protection domain can safely make tail calls to other code in that domain.

COS 597B28 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})

COS 597B29 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

COS 597B30 Discussion  Problem: Applets returning closures that 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.

COS 597B31 Conclusions  What security principles does the Java model obey? To what extent?  Open design?  Economy of mechanism?  Minimal trusted computing base?  Security as process?  Least privilege?  Fail-safe defaults?  Psychological acceptability?