Containment and Integrity for Mobile Code Security policies as types

1. Containment and Integrityfor Mobile CodeSecurity policies as types Andrew Myers Fred Schneider Department of Computer Science Cornell University

2. Projects • Security policies as types • support for low-level languages • reacting to intrusion: untrusted hosts • Composing fault-tolerance and security • Asynchronous, proactive secret sharing • COCA online certification authority • Inlined reference monitors Security policies as types — Andrew Myers

3. Protecting data against programs • Goal: confidentiality, integrity of information • How to enforce as system-wide property? • There are almost no trusted programs • Information flow policies: end-to-end principle applied to security “the system cannot allow information to flow from source A to destination B” Security policies as types — Andrew Myers

4. Security-typed languages • Idea: encode security policies in type system • Programs not allowed to run unless type-correct • Advantages: • Decidable enforcement • Low run-time overhead • Small TCB (?) • Compositional security • Issues: • What security policies can be encoded as types? • Application to low-level code? • Distributed computation – who decides what to run? Security policies as types — Andrew Myers

5. Non-interference H1 L1 H3 L1 L H2 L2 H4 L2 • Information flow policies based on some form of non-interference • “High” inputs cannot affect “low” observables • Can be enforced by security type system Security policies as types — Andrew Myers

6. Issues • Low-level code • Want to verify security in executable code • Useful for mobile code • Security type systems too restrictive • TCB: host • Untrusted hosts • Intrusion • Dynamic coalitions • Downgrading • Non-interference is too restrictive • What can be enforced if it is violated? Security policies as types — Andrew Myers

7. Security types • A simple security type system: • Security type s = tH or tL where t an ordinary type • intH : a secret integer • intL: a public integer • More expressive labeling schemes exist • Examples of use: intLx = e; // OK if e has type intL intHx = e; // OK if e has type intH or intL intHb; intLx = 0;if (b) { x = 1; }// not OK Security policies as types — Andrew Myers

8. Implicit flow in high-level lang. intHb; intLx = 0; if (b) { x = 1; /* not OK */ } • Implicit flow: information carried through control structure • Solution: introduce static approximation to implicit flow (pc) • Type of expression always acquires pc intHb; intLx = 0L; if (b) { x = 1H; } • pc updated by rules for type-checking control structures Security policies as types — Andrew Myers

9. Implicit flow in low-level lang. • High-level control structures (if, while, switch, function calls, returns)  indirect, direct jumps • Less ability to reason about implicit flow • Simple rule: pc at target of jump always more secret than at jump instruction • captures possible implicit flow • too restrictive • doesn’t handle indirect jumps Security policies as types — Andrew Myers

10. Loss of precision intHb; /* pc = L */ intLx = 0L; /* pc = L */ if (b) { x = 1H; /* pc = H */} /* pc = L */ MOV x, 0 ; pc = L CMP b, 0 ; pc = L JZ skip ; pc = H MOV x, 1 ; pc = H skip: ; pc = H High-level: safe Low-level: apparently unsafe Security policies as types — Andrew Myers

11. A security-typed calculus • First low-level typed language with support for dynamic control transfers, static information flow control [ESOP’01] • Continuations in A-normal form: close to assembly code • Linear continuations preserve precision ofhigh-level source analysis • First proof of language-basedenforcement of non-interference(for any higher-order imperative language) e ::= let x = prim in e | let x = refls v in e| letlin y = lv in e | set v1:= v2 in e | if v then e1 else e2| goto v1(v2, lv) | lgoto lv1(v, lv2) | haltsv Security policies as types — Andrew Myers

12. TCB: host • Model so far: host/execution platform type-checks incoming code to enforce security properties • On a system of many hosts? – no perimeter! Response to intrusion? Dynamic trust relationships? Security policies as types — Andrew Myers

13. Secure program partitioning • Programs contain no explicit code locations or communication • Automatically transformed (“split”)to run securely on current hosts • Intrusion: re-split! • Change in trust relationships: re-split! • Implemented in Jif compiler [TR] source compiler intermediate code authenticated trust declarations splitter code partition code partition code partition Host 1 Host 2 Host 3 Security policies as types — Andrew Myers

14. Downgrading/Declassification • Information-flow security properties are too strong—real systems need to leak information • Example: password-checking procedure leaks information about passwords even on failure • Non-interference is all-or-nothing • Robust vs. non-robust declassification: • Robust: declassification releases only the intended information • Non-robust: attackers can exploit declassification to release additional information • A non-robust system: password checker if attacker can change passwords Security policies as types — Andrew Myers

15. Robust declassification ? ? = = • Assumption 1: attacker can observe some aspects of system state S • Assumption 2: attacker can cause changes to some aspects of system state S • Observation: projection function p : S  O • System is robust with respect to attacker if attacker learns no more from attacked system than from simple observation A S S1 S2 S3 S1 S4 S5 Non-interfering Robust Security policies as types — Andrew Myers

16. Results • Theorem: non-interfering systems are robust • Theorem: all systems are robust against attackers whose power to modify (ASS) is appropriately bounded • Integrity property derived automatically from confidentiality property • First formal characterization of confidentiality+downgrading+active attacker; applicable to language-based enforcement Security policies as types — Andrew Myers

17. Policies • Strong, information flow policies • Simple access control policies • Mutually distrusting but collaborating principals • Dynamically changing trust relationships Security policies as types — Andrew Myers

18. Attacks • Considered: • buggy or malicious downloaded code • storage channels, implicit flows • intrusion/integrity violation in multiple-host system • exploitation of downgrading channels • Not considered: • denial of service • traffic analysis • timing, termination channels Security policies as types — Andrew Myers

19. Conclusions • Information flow policies enforce system-wide security • Progress: • Provably correct type-based enforcement for low-level code • Support for untrusted hosts, dynamically changing trust relationships—secure program partitioning • New theory of robust declassification Security policies as types — Andrew Myers