280 likes | 406 Vues
This document summarizes the key concepts from COS 597B, a course on language-based security conducted by David Walker, incorporating slides stolen from Steve Zdancewic at the University of Pennsylvania. It explores abstract stack inspection, permission systems, operational semantics, and examples illustrating protection domains and permissions in programming. The framework provides a foundation for evaluating security properties and reasoning about program contexts, enhancing understanding of language-based security mechanisms.
E N D
Current Techniques in Language-based Security David Walker COS 597B With slides stolen from: Steve Zdancewic University of Pennsylvania
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 597B
lsec Syntax • Language syntax:e,f ::= expressions x variablelx.e function e f application R{e} framed expr enable p in e enable test p then e else f check perm. fail failurev ::= x | lx.e valueso ::= v | fail outcome COS 597B
Framing a Term • Models the Classloader that marks the (unframed) code with its protection domain:R[x] = xR[lx.e] = lx.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 597B
Example readFile = lfileName.System{ test fileWrite(fileName) then … // primitive file IO (native code) else fail } Applet{readFile “f2”} failSystem{readFile “f2”} <f2 contents> COS 597B
lsec Operational Semantics • Evaluation contexts:E ::= [] Hole E e Eval. Function v E Eval. Arg. enable p in E Tagged frame R{E} Frame • E models the control stack COS 597B
lsec Operational Semantics E[(lx.e) v] E[e{v/x}]E[enable p in v] E[v]E[R{v}] E[v] E[fail] failE[test p then e else f] E[e] if Stack(E) |-- pE[test p then e else f] E[f] if (Stack(E) |-- p) eo iff e * o Stack Inspection COS 597B
Example Evaluation Context Applet{readFile “f2”} E = Applet{[]} r = readFile “f2” COS 597B
Example Evaluation Context Applet{readFile “f2”} E = Applet{[]} r = (lfileName.System{ test fileWrite(fileName) then … // primitive file IO (native code) else fail } ) “f2” COS 597B
Example Evaluation Context Applet{readFile “f2”} E = Applet{[]} r = System{ test fileWrite(“f2”) then … // primitive file IO (native code) else fail } COS 597B
Example Evaluation Context Applet{System{test fileWrite(“f2”) then … // primitive file IO (native code) else fail }} COS 597B
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 597B
Formal Stack Inspection E’ = Applet{System{[]}}r’ = test fileWrite(“f2”) then … // primitive file IO (native code) else fail When does stack E’ allow permissionfileWrite(“f2”)? Stack(E’) |-- fileWrite(“f2”) COS 597B
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 597B
x|-- p p R x.R|-- p x|-- p x.enable(q)|-- p x|= p x.enable(p)|-- p Abstract Stack Inspection . |-- p empty stack axiom protection domain check p q irrelevant enable check enable COS 597B
p R x.R|= p x|= p x.enable(q)|= p Abstract Stack Inspection . |= p empty stack enables all enable succeeds* irrelevant enable * Enables should occur only in trusted code COS 597B
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 597B
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 597B
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 597B
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 597B
Example Inequality ok = lx.x loop = (lx.x x)(lx.x x) (note: loop ) f = lx. let z = x ok in l_.z g = lx. let z = x ok in l_.(x ok) Claim: f ≠ g Proof: Let C[] = {[] l_.test p then loop else ok} ok COS 597B
Example Continued • C[f] ={f l_.test p then loop else ok} ok • {let z = (l_.test p then loop else ok) ok in l_.z} ok • {let z = test p then loop else ok in l_.z} ok • {let z = ok in l_.z} ok • {l_.ok} ok • (l_.ok)ok • ok COS 597B
Example Continued • C[g] ={g l_.test p then loop else ok} ok • {let z = (l_.test p then loop else ok) ok in l_.((l_.test p then loop else ok) ok)} ok • {let z = test p then loop else ok in l_. ((l_.test p then loop else ok) ok)} ok • {let z = ok in l_. ((l_.test p then loop else ok) ok)} ok • {l_. ((l_.test p then loop else ok) ok)} ok • (l_. ((l_.test p then loop else ok) ok))ok • (l_.test p then loop else ok) ok • test p then loop else ok • loop loop loop loop … COS 597B
Example Applications Eliminate redundant annotations: lx.R{ly.R{e}}= lx.ly.R{e} Decrease stack inspection costs: e = test p then (enable p in e) else e COS 597B
Axiomatic Equivalence Can give a sound set of equations that characterize =. Example axioms: • is a congruence (preserved by contexts) • (lx.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 597B
Example: Tail Calls Ordinary evaluation: R{(lx.S{e}) v} R{S{e{v/x}}} Tail-call eliminated evaluation: R{(lx.S{e}) v} S{e{v/x}} Not sound in general! But OK in special cases. COS 597B
Example: Tail Calls Suppose R S. Then: R{(lx.S{e}) v} R{S{e{v/x}}} S{e{v/x}} S{e}{v/x} (lx.S{e}) v In particular, code within a protection domain can safely make tail calls to other code in that domain. COS 597B
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? COS 597B