SLIDE 1
Ni Nickel A Framework for Design and Verification of Information - - PowerPoint PPT Presentation
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
SLIDE 2
SLIDE 3
SLIDE 4
Covert channels through error codes
SLIDE 5
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]
SLIDE 6
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]
SLIDE 7
- 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.
Our approach: Verification-driven interface design
Specify policy Design interface Verify interface against policy Counterexample
SLIDE 8
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
SLIDE 9
Covert channel in resource names
Process 1 Process 2
Policy: Process 1 and Process 2 should not communicate Design: Spawn with sequential PID allocation
SLIDE 10
Covert channel in resource names
Process 1 Process 2
5
Design: Spawn with sequential PID allocation Policy: Process 1 and Process 2 should not communicate
SLIDE 11
Covert channel in resource names
Process 1 Process 2
5 1 1
spawn → 3
Design: Spawn with sequential PID allocation Policy: Process 1 and Process 2 should not communicate
SLIDE 12
Covert channel in resource names
Process 1 Process 2
5 1 1
spawn → 3
1 2
spawn → 3+1 … spawn → 3+5
Design: Spawn with sequential PID allocation Policy: Process 1 and Process 2 should not communicate
SLIDE 13
Covert channel in resource names
Process 1 Process 2
5 1 1
spawn → 3
1 2
spawn → 3+1 … spawn → 3+5
1 3
spawn → 3+5+1
Design: Spawn with sequential PID allocation Policy: Process 1 and Process 2 should not communicate
SLIDE 14
Covert channel in resource names
Thread 1 Thread 2
Policy: Thread 1 and Thread 2 should not communicate
5 1 1
spawn → 3
1 2
spawn → 3+1 … spawn → 3+5
1 3
spawn → 3+5+1
Design: Spawn with sequential PID allocation
Examples of covert channels
- Resource names
- Resource exhaustion
- Statistical information
- Error handling
- Scheduling
- Devices and services
SLIDE 15
Noninterference intuition
Process 2:
spawn → 3
Process 1:
spawn 5 times
Process 2:
spawn → 9
SLIDE 16
Noninterference intuition
Process 2:
spawn → 3
Process 1:
spawn 5 times
Process 2:
spawn → 9
Process 2:
spawn → 3
Process 2:
spawn → 4
SLIDE 17
Noninterference intuition
Process 2:
spawn → 3
Process 1:
spawn 5 times
Process 2:
spawn → 9
Process 2:
spawn → 3
Process 2:
spawn → 4 Process 1 interferes with Process 2
SLIDE 18
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
SLIDE 19
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
Flexible definition enables broad set of policies
- Can-flow-to relation can be intransitive
- State dependent dom
SLIDE 20
Noninterference definition
sources 𝜗, 𝑣, 𝑡 ≔ 𝑣 sources 𝑏 ∘ 𝑢𝑠, 𝑣, 𝑡 ≔ ቐsources 𝑢𝑠, 𝑣, step 𝑡, 𝑏 ∪ dom 𝑏, 𝑡 if ∃𝑤 ∈ sources(𝑢𝑠, 𝑣, step 𝑡, 𝑏 . dom 𝑏, 𝑡 ⇝ 𝑣 sources 𝑢𝑠, 𝑣, step 𝑡, 𝑏
- therwise
purge 𝜗, 𝑣, 𝑡 ≔ 𝜗 purge 𝑏 ∘ 𝑢𝑠, 𝑣, 𝑡 ≔ ቐ 𝑏 ∘ tr′ 𝑢𝑠′ ∈ purge 𝑢𝑠, 𝑣, step 𝑡, 𝑏 } if dom 𝑏, 𝑡 ∈ sources 𝑏 ∘ 𝑢𝑠, 𝑣, 𝑡 𝑏 ∘ tr′ 𝑢𝑠′ ∈ purge 𝑢𝑠, 𝑣, step 𝑡, 𝑏 } ∪ purge(𝑢𝑠, 𝑣, 𝑡)
- therwise
∀ 𝑢𝑠′ ∈ purge 𝑢𝑠, dom 𝑏, run init,𝑢𝑠 ,init . output run init,𝑢𝑠 ,𝑏 = output run(init,𝑢𝑠′ ,𝑏)
SLIDE 21
Given a policy, purging actions “irrelevant” to a domain should not affect the output of the actions for that domain
SLIDE 22
Automated verification of noninterference
- ℐ init ∧ ℐ 𝑡 ⇒ ℐ step 𝑡, 𝑏
- ≈
𝑣 is reflexive, symmetric, and transitive
- ℐ 𝑡 ∧ ℐ 𝑢 ∧ 𝑡 ≈
𝑣 𝑢 ⇒ (dom 𝑏, 𝑡 ⇝ 𝑣 ⇔ dom 𝑏, 𝑢 ⇝ 𝑣)
- ℐ 𝑡 ∧ dom 𝑏, 𝑡 ⇝ 𝑣 ⇒ s ≈
𝑣 step(𝑡,𝑏)
SLIDE 23
Automated verification of noninterference
- ℐ init ∧ ℐ 𝑡 ⇒ ℐ step 𝑡, 𝑏
- ≈
𝑣 is reflexive, symmetric, and transitive
- ℐ 𝑡 ∧ ℐ 𝑢 ∧ 𝑡 ≈
𝑣 𝑢 ⇒ (dom 𝑏, 𝑡 ⇝ 𝑣 ⇔ dom 𝑏, 𝑢 ⇝ 𝑣)
- ℐ 𝑡 ∧ dom 𝑏, 𝑡 ⇝ 𝑣 ⇒ s ≈
𝑣 step(𝑡,𝑏)
Proof strategy: unwinding conditions
- Together imply noninterference
- Requires reasoning only about individual actions
- Amenable to automated reasoning using SMT
SLIDE 24
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
SLIDE 25
Verification-driven interface design in Nickel
Specify policy
1
Design interface
2
Verify interface against policy
3
Counterexample
SLIDE 26
Verification-driven interface design in Nickel
Specify policy
1
Design interface
2
Verify interface against policy
3
Counterexample
Implement interface
4
Verify implementation against interface
5
SLIDE 27
Interface specification Information flow policy Trusted Observation function
SLIDE 28
Interface specification Information flow policy Trusted
pid 1 pid 2 ... pid n
Policy: n processes that are not allowed to communicate with each other
Observation function
SLIDE 29
Interface specification Information flow policy Trusted Observation function
SLIDE 30
Interface specification Information flow policy Trusted Observation function
SLIDE 31
Interface specification Information flow policy Trusted Observation function
SLIDE 32
Interface specification Information flow policy Trusted Observation function
SLIDE 33
Interface specification Information flow policy Trusted Observation function
SLIDE 34
Interface specification Information flow policy Trusted Observation function
SLIDE 35
Interface specification Information flow policy Trusted Observation function
SLIDE 36
Interface specification Information flow policy Trusted Observation function
SLIDE 37
Interface specification Information flow policy Trusted Observation function
SLIDE 38
Interface specification Information flow policy Trusted Observation function
SLIDE 39
Information flow policy Observation function Trusted Interface specification
SLIDE 40
Information flow policy Observation function Trusted Interface specification
SLIDE 41
Information flow policy Observation function Trusted Interface specification
SLIDE 42
Information flow policy Observation function Trusted Interface specification
SLIDE 43
Nickel verifier
SMT Information flow policy Observation function Trusted Interface specification
SLIDE 44
Nickel verifier
SMT Information flow policy Trusted Interface specification
Counter- example
Channel
Observation function
SLIDE 45
Nickel verifier
SMT Information flow policy Trusted
Counter- example
Bug
Interface specification
- Partition names among domains
- Reduce flows to the scheduler
- Perform flow checks early
- Limit resource usage with quotas
- Encrypt names from a large space
- Expose or enclose nondeterminism
Design patterns
Observation function
SLIDE 46
Nickel verifier
SMT Information flow policy Trusted
Counter- example
Bug
Interface specification Observation function
SLIDE 47
Nickel verifier
SMT Information flow policy Trusted
Counter- example
Bug
Interface specification Observation function
SLIDE 48
Nickel verifier
SMT Information flow policy Trusted Interface specification
Counter- example
Channel
Observation function
SLIDE 49
Nickel verifier
SMT Information flow policy Trusted Interface specification
Counter- example
Channel Verified
Observation function
SLIDE 50
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
SLIDE 51
Decentralized information flow control (DIFC)
- Flexible mechanism to enforce security policies [SOSP ’97]
- Each object assigned labels for tracking and mediating data access
- Several operating system kernels enforce DIFC:
- Asbestos [SOSP ’05]
- HiStar [OSDI ’06]
- Flume [SOSP ’07]
- Our goal: Build a DIFC OS kernel without any covert channels
SLIDE 52
NiStar: First verified DIFC OS
- Resembles an exokernel with finite interface design
- 46 system calls and exception handlers
- Supports musl C stdlib using Linux emulation, file system, lwip network service
- Enforces information flow among small number of object types
- Labels, containers, threads, gates, page-table pages, user pages, quanta
- Each object is assigned three labels: Secrecy 𝑇, integrity 𝐽, ownership 𝑃
- Simple policy: Given two objects with domains ℒ1 and ℒ2:
- ℒ1 = ⟨𝑇1, 𝐽1, 𝑃1⟩, ℒ2 = ⟨𝑇2,𝐽2, 𝑃2⟩
- ℒ1 ⇝ ℒ2 ≔ (𝑇1 − 𝑃1 ⊆ 𝑇2 ∪ 𝑃2) ∧ (𝐽2 − 𝑃2 ⊆ 𝐽1 ∪ 𝑃1)
SLIDE 53
NiStar Scheduler
- New object types to close channel in scheduler
NiStar closes logical time channel in scheduler
SLIDE 54
Other systems
Subset of ARINC 653
- Industrial standard for avionics systems
- Reproduced three known bugs in the specification
NiKOS:
- Small Unix-like OS kernel mirroring mCertiKOS [PLDI ‘16]
- Process isolation policy
SLIDE 55
Implementation
Component NiStar NiKOS ARINC 653 Information flow policy 26 14 33 Interface specification 714 82 240 Observational equivalence 127 56 80 Interface implementation 3,155 343
- User-space implementation
9,348 389
- Common kernel infrastructure
4,829 (shared by NiStar / NiKOS)
SLIDE 56
Implementation
Component NiStar NiKOS ARINC 653 Information flow policy 26 14 33 Interface specification 714 82 240 Observational equivalence 127 56 80 Interface implementation 3,155 343
- User-space implementation
9,348 389
- Common kernel infrastructure
4,829 (shared by NiStar / NiKOS)
Concise policy
SLIDE 57
Low proof burden
- NiStar:
- Six months for the first prototype implementation
- Six weeks on verification
- NiKOS: two weeks
- ARINC 653: one week
SLIDE 58
Conclusion
- Verification-driven interface design
- Systematic way to design secure interfaces
- Interactive workflow with counterexample-based debugging
- First verified DIFC system
- Low proof burden