Ni Nickel A Framework for Design and Verification of Information - PowerPoint PPT Presentation

Ni Nickel A Framework for Design and Verification of Information Flow Control Systems Helgi Sigurbjarnarson , Luke Nelson, Bruno Castro-Karney, James Bornholt, Emina Torlak, and Xi Wang .org

Enforcing information flow control is critical

Covert channels through error codes

Eliminating unintended flows is difficult • Covert channels: A channel not intended for information flow [Lampson ‘73] • Covert channels are often inherent in interface design • Examples of covert channels in interfaces: • ARINC 653 avionics standard [TACAS ‘16] • Floating labels in Asbestos [Oakland ‘09, OSDI ‘06]

Eliminating unintended flows is difficult • Covert channels: A channel not intended for information flow [Lampson ‘73] • Covert channels are often inherent in interface design • Examples of covert channels in interfaces: • ARINC 653 avionics standard [TACAS ‘16] • Floating labels in Asbestos [Oakland ‘09, OSDI ‘06]

Our approach: Verification-driven interface design Verify interface Specify policy Design interface against policy Counterexample • Extends prior work of push-button verification: • Yggdrasil [ OSDI ‘ 16] & Hyperkernel [ SOSP ‘17 ] • Limitations • Finite interface, expressible using SMT. • Hardware-based side channels not in scope and no concurrency.

Contributions • New formulation and proof strategy for noninterference • Nickel : A framework for design and verification of information flow control (IFC) systems • Experience building three systems using Nickel • First formally verified decentralized IFC OS kernel • Low proof burden: order of weeks

Covert channel in resource names Policy: Process 1 and Process 2 should not communicate Design: Spawn with sequential PID allocation Process 1 Process 2

Covert channel in resource names Policy: Process 1 and Process 2 should not communicate Design: Spawn with sequential PID allocation 5 Process 1 Process 2

Covert channel in resource names Policy: Process 1 and Process 2 should not communicate Design: Spawn with sequential PID allocation 5 Process 1 Process 2 spawn → 3 1 1

Covert channel in resource names Policy: Process 1 and Process 2 should not communicate Design: Spawn with sequential PID allocation 5 Process 1 Process 2 spawn → 3 1 1 spawn → 3+1 … 2 1 spawn → 3+5

Covert channel in resource names Policy: Process 1 and Process 2 should not communicate Design: Spawn with sequential PID allocation 5 Process 1 Process 2 spawn → 3 1 1 spawn → 3+1 … 2 1 spawn → 3+5 spawn → 3+ 5 +1 3 1

Covert channel in resource names Examples of covert channels Policy: Thread 1 and Thread 2 should not communicate • Resource names Design: Spawn with sequential PID allocation • Resource exhaustion 5 Thread 1 Thread 2 • Statistical information spawn → 3 1 1 • Error handling spawn → 3+1 • Scheduling … 2 1 spawn → 3+5 • Devices and services spawn → 3+ 5 +1 3 1

Noninterference intuition Process 2: Process 1: Process 2: spawn → 3 spawn → 9 spawn 5 times

Noninterference intuition Process 2: Process 1: Process 2: spawn → 3 spawn → 9 spawn 5 times Process 2: Process 2: spawn → 3 spawn → 4

Noninterference intuition Process 2: Process 1: Process 2: spawn → 3 spawn → 9 spawn 5 times Process 2: Process 2: spawn → 3 spawn → 4 Process 1 interferes with Process 2

Information flow policies in Nickel • Set of domains 𝒠 : e.g., processes • Can-flow-to relation ⇝ ⊆ (𝒠 × 𝒠) : permitted flow between domains • Function dom: (𝐵 × 𝑇) → 𝒠 : maps an action and state to a domain

Information flow policies in Nickel • Set of domains 𝒠 : e.g., processes Flexible definition enables broad set of policies • Can-flow-to relation ⇝ ⊆ (𝒠 × 𝒠) : permitted flow between domains • Can-flow-to relation can be intransitive • State dependent dom • Function dom: (𝐵 × 𝑇) → 𝒠 : maps an action and state to a domain

Noninterference definition sources 𝜗, 𝑣, 𝑡 ≔ 𝑣 sources 𝑏 ∘ 𝑢𝑠, 𝑣, 𝑡 ≔ ቐsources 𝑢𝑠, 𝑣, step 𝑡, 𝑏 ∪ dom 𝑏, 𝑡 if ∃𝑤 ∈ sources(𝑢𝑠, 𝑣, step 𝑡, 𝑏 . dom 𝑏, 𝑡 ⇝ 𝑣 sources 𝑢𝑠, 𝑣, step 𝑡, 𝑏 otherwise purge 𝜗, 𝑣, 𝑡 ≔ 𝜗 𝑢𝑠 ′ ∈ purge 𝑢𝑠, 𝑣, step 𝑡, 𝑏 ≔ ቐ 𝑏 ∘ tr ′ } if dom 𝑏, 𝑡 ∈ sources 𝑏 ∘ 𝑢𝑠, 𝑣, 𝑡 purge 𝑏 ∘ 𝑢𝑠, 𝑣, 𝑡 𝑢𝑠 ′ ∈ purge 𝑢𝑠, 𝑣, step 𝑡, 𝑏 𝑏 ∘ tr ′ } ∪ purge(𝑢𝑠, 𝑣, 𝑡) otherwise ∀ 𝑢𝑠 ′ ∈ purge 𝑢𝑠, dom 𝑏, run init,𝑢𝑠 ,init . output run init,𝑢𝑠 ,𝑏 = output run(init,𝑢𝑠 ′ ,𝑏)

Given a policy, purging actions “irrelevant” to a domain should not affect the output of the actions for that domain

Automated verification of noninterference • ℐ init ∧ ℐ 𝑡 ⇒ ℐ step 𝑡, 𝑏 𝑣 is reflexive, symmetric, and transitive • ≈ 𝑣 𝑢 ⇒ (dom 𝑏, 𝑡 ⇝ 𝑣 ⇔ dom 𝑏, 𝑢 ⇝ 𝑣) • ℐ 𝑡 ∧ ℐ 𝑢 ∧ 𝑡 ≈ 𝑣 step(𝑡,𝑏) • ℐ 𝑡 ∧ dom 𝑏, 𝑡 ⇝ 𝑣 ⇒ s ≈

Automated verification of noninterference • ℐ init ∧ ℐ 𝑡 ⇒ ℐ step 𝑡, 𝑏 𝑣 is reflexive, symmetric, and transitive • ≈ Proof strategy: unwinding conditions • Together imply noninterference 𝑣 𝑢 ⇒ (dom 𝑏, 𝑡 ⇝ 𝑣 ⇔ dom 𝑏, 𝑢 ⇝ 𝑣) • Requires reasoning only about individual actions • ℐ 𝑡 ∧ ℐ 𝑢 ∧ 𝑡 ≈ • Amenable to automated reasoning using SMT 𝑣 step(𝑡,𝑏) • ℐ 𝑡 ∧ dom 𝑏, 𝑡 ⇝ 𝑣 ⇒ s ≈

Outline • New formulation and proof strategy for noninterference • Nickel: A framework for design and verification of information flow control (IFC) systems • Experience building three systems using Nickel • First formally verified decentralized IFC OS kernel • Low proof burden: order of weeks

Verification-driven interface design in Nickel 1 2 3 Verify interface Specify policy Design interface against policy Counterexample

Verification-driven interface design in Nickel 1 2 3 Verify interface Specify policy Design interface against policy Counterexample 5 4 Verify implementation Implement against interface interface

Trusted Information flow policy Interface specification Observation function

Trusted Information flow Policy: policy n processes that are not allowed to communicate with each other Interface specification ... pid 1 pid 2 pid n Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Interface specification Observation function

Trusted Information flow policy Nickel SMT Interface specification verifier Observation function

Counter- Trusted example Information flow policy Channel Nickel SMT Interface specification verifier Observation function

Counter- Trusted Design patterns example Information flow policy Bug • Partition names among domains • Reduce flows to the scheduler Nickel SMT Interface • Perform flow checks early specification verifier • Limit resource usage with quotas • Encrypt names from a large space Observation function • Expose or enclose nondeterminism

Counter- Trusted example Information flow policy Bug Nickel SMT Interface specification verifier Observation function

Counter- Trusted example Information flow policy Bug Nickel SMT Interface specification verifier Observation function

Counter- Trusted example Information flow policy Channel Nickel SMT Interface specification verifier Observation function

Counter- Trusted example Information flow policy Channel Nickel SMT Interface specification verifier Verified Observation function

Outline • New formulation and proof strategy for noninterference • Nickel: A framework for design and verification of information flow control (IFC) systems • Experience building three systems using Nickel • First formally verified decentralized IFC OS kernel • Low proof burden: order of weeks