1 / 26

A Type System for Expressive Security Policies

A Type System for Expressive Security Policies. David Walker Cornell University. Extensible Systems. System Interface. Code. Extensible systems are everywhere: web browsers, extensible operating systems, servers and databases Critical Problem: Security. Download, Link & Execute.

renee
Download Presentation

A Type System for Expressive Security Policies

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. A Type System forExpressive Security Policies David Walker Cornell University

  2. Extensible Systems System Interface Code • Extensible systems are everywhere: • web browsers, extensible operating systems, servers and databases • Critical Problem: Security Download, Link & Execute David Walker, Cornell University

  3. Certified Code Untrusted Code Secure Code System Interface • Attach annotations (types, proofs, ...) to untrusted code • Annotations make verification of security properties feasible Download & Verify Link & Execute Annotations David Walker, Cornell University

  4. Certifying Compilation • An Advantage • Increased Trustworthiness • verification occurs after compilation • compiler bugs will not result in security holes • A Disadvantage • Certificates may be difficult to produce David Walker, Cornell University

  5. Producing Certified Code High-level Program • Certificate production must be automated • Necessary components: 1) a source-level programming language 2) a compiler to compile, annotate, and optimize source programs 3) a transmission language that certifies security properties Compile user annotations Annotated Program Optimize Transmit David Walker, Cornell University

  6. So Far ... Type Safe High-level Program 1) a strongly typed source-level programming language 2) a type-preserving compiler to compile, annotate, and optimize source programs 3) a transmission language that certifies type-safety properties Compile types Typed Program Optimize Transmit David Walker, Cornell University

  7. Examples • Proof-Carrying Code[Necula & Lee] • compilers produce type safety proofs • Typed Assembly Language[Morrisett, Walker, et al] • guarantees type safety properties • Efficient Code Certification[Kozen] • uses typing information to guarantee control-flow and memory safety properties • Proof-Carrying Code [Appel & Felty] • construct types from low-level primitives David Walker, Cornell University

  8. Conventional Type Safety • Conventional types ensure basic safety: • basic operations performed correctly • abstraction/interfaces hide data representations and system code • Conventional types don't describe complex policies • eg: policies that depend upon history • Melissa virus reads Outlook contacts list and then sends 50 emails David Walker, Cornell University

  9. Security in Practice • Security via code instrumentation • insert security state and check dynamically • use static analysis to minimize run-time overhead • SFI [Wahbe et al], • SASI [Erlingsson & Schneider], • Naccio [Evans & Twyman], • [Colcombet & Fradet], … David Walker, Cornell University

  10. This Paper • Combines two ideas: • certifying compilation • security via code instrumentation • The Result: • a system for secure certified code • high-level security policy specifications • an automatic translation into low-level code • security enforced by static & dynamic checking David Walker, Cornell University

  11. Strategy • Security Automata specify security properties [Erlingsson & Schneider] • Compilation inserts typing annotations & dynamic checks where necessary • A dependently-typed target language provides a framework for verification • can express & enforce any security automaton policy • provably sound David Walker, Cornell University

  12. Security Architecture High-level Program Security Automaton System Interface Compile Annotate Secure Typed Program Secure Typed Interface Optimize Secure Executable Type Check Transmit David Walker, Cornell University

  13. Security Automata • A general mechanism for specifying security policies • Enforce any safety property • access control policies: • “cannot access file foo” • resource bound policies: • “allocate no more than 1M of memory” • the Melissa policy: • “no network send after file read” David Walker, Cornell University

  14. Example read(f) • Policy: No send operation after a read operation • States: start, has read, bad • Inputs (program operations): send, read • Transitions (state x input -> state): • start x read(f) -> has read start has read send read(f) bad send David Walker, Cornell University

  15. Example Cont’d read(f) • S.A. monitor program execution • Entering the bad state = security violation start has read send read(f) bad send % untrusted program % s.a.: start state send(); % ok -> start read(f); % ok -> has read send(); % bad, security violation David Walker, Cornell University

  16. Every security-relevant operation has an associated function: checkop Trusted, provided by policy writer checkop implements the s.a. transition function Enforcing S.A. Specs checksend (state) = if state = start then start else bad David Walker, Cornell University

  17. Enforcing S.A. Specs • Rewrite programs: send() let next_state = checksend(current_state) in if next_state = bad then halt else % next state is ok send() David Walker, Cornell University

  18. Questions • How do we verify instrumented code? • is this safe? let next_state = checksend(other_state) in if next_state = bad then halt else % next state is ok send() • Can we optimize certified code? David Walker, Cornell University

  19. Verification • Basic types ensure standard type safety • functions and data used as intended and cannot be confused • security checks can’t be circumvented • Introduce a logic into the type system to express complex invariants • Use the logic to encode the s.a. policy • Use the logic to prove checks unnecessary David Walker, Cornell University

  20. Target Language Types • Predicates: • describe security states • describe automaton transitions • describe dependencies between values • Function types include predicates so they can specify preconditions: • foo: [1,2,P1(1,2),P2(1)] . 1 -> 2 David Walker, Cornell University

  21. Each security-relevant function has a type specifying 3 additional preconditions eg: the send function: P1: in_state(current_state) P2: transitionsend(current_state,next_state) P3: next_state  bad Pre: P1 & P2& P3 Post: in_state(next_state) The precondition ensures calling send won’t result in a security violation Secure Functions David Walker, Cornell University

  22. Dynamic checks propagate information into the type system eg: checksend(state) Post: next_state. transitionsend(state,next_state) & result = next_state conditional tests: if state = bad then % assume state = bad ... else % assume state  bad ... Run-time Security Checks David Walker, Cornell University

  23. Example % P1: in_state(current_state) let next_state = check_send(current_state) in % P2: transitionsend(current_state,next_state) if next_state = bad then halt else % P3: next_state  bad send() % P1 & P2 & P3 imply send is ok David Walker, Cornell University

  24. read(f) start has read send read(f) bad send Optimization • Analysis of s.a. structure makes redundant check elimination possible • eg: • supply the type checker with the fact transitionsend(start,start) and verify: if current = start then send(); send (); send (); … David Walker, Cornell University

  25. Related Work • Program verification • abstract interpretation, data flow & control flow analysis, model checking, soft typing, verification condition generation & theorem proving, ... • Dependent types in compiler ILs • Xi & Pfenning, Crary & Weirich, ... • Security properties of typed languages • Leroy & Rouaix, ... David Walker, Cornell University

  26. Summary • A recipe for secure certified code: • types • ensure basic safety • prevent dynamic checks from being circumvented • provide a framework for reasoning about programs • security automata • specify expressive policies • dynamic checking when policies can’t be proven statically David Walker, Cornell University

More Related