Verifying Information Flow Control Over Unbounded Processes

1. Verifying Information Flow Control Over Unbounded Processes William R. Harris, Nicholas A. Kidd, SagarChaki, SomeshJha, and Thomas Reps TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AA

2. Key: An unsecured server Worker0 Worker1 Request Handler buffer.txt … WorkerN

3. Decentralized Information Flow Control (DIFC) Privacy of information controlled by application Application uses labels, system enforces label semantics Notmulti-trace properties

4. Key: A secured server Worker0 {0} Worker1 Request Handler {0} {1} buffer.txt … {n} WorkerN :({0} µ {n})

5. Simplified Server Code void Handler() { while (*) { Request r = get_next_http_request(); Endpoint e0, e1; create_channel(&e0, &e1); spawn(“/usr/bin/Worker”, e1, r); send_ack(); } }

6. Server code with Flume void Handler() { Label lab, cap; cap = empty_label(); while (*) { Request r = get_next_http_request(); lab = add_Tag(empty_label(), create_tag()); Endpoint e0, e1; create_channel(&e0, &e1); spawn(“/usr/bin/Worker”, e1, r, lab, cap); send_ack(); } }

7. The Problem DIFC gives powerful low-level mechanisms Semantic gap between high-level policy, low-level mechanisms Automatically validate that application follows policy

8. A first cut at a solution DIFC policies are safety properties So apply a model checker for safety properties!

9. …not so fast Key system objects can be dynamically allocated Summarize?

10. Key: An abstracted server Summary Worker 0 {S} {S} buffer.txt Request Handler Summary Worker 1 {S} {S} µ {S}

11. Random isolation [Kidd ’09] to the rescue!

12. Key: A randomly isolated server Worker0 {C} {C} buffer.txt Request Handler Summary Worker {S} : ({C} µ {S})

13. Key takeaways Information flow control policies for DIFC systems are safety properties Summarization makes checking feasible Random isolation makes checking precise

14. Analysis architecture SAFE Instrumentation Abstraction Program: Concrete semantics Program: Rand. Iso. semantics Program: Abstract semantics Copper [Chaki ’04] Error Policy

15. Allocating a tag: concrete t u t u v lab := create_tag(); lab lab

16. Allocating a tag: summarization t u v t u lab lab lab := create_tag(); sum sum lab lab

17. Allocating a tag:random isolation t u t u v :iso : iso : iso :iso iso lab if (!has_alloc && nondet()) { lab := create_iso(); has_alloc= true; } else { lab := create_noniso(); } lab sum sum conc iso :iso :iso lab lab

18. Representation in Predicate Abstraction Instrument allocation functions Every relation is a function

19. Eg. Subset {C} µ® {S} = 0 {C} µ® {C} = 1 {C} µ® {C, S} = 1 {S} µ® {S} = * {C, S} µ® {C, S} = *

20. Experiments

21. FlumeWiki • A wiki software package designed for secure information flow. • Policies: • No Worker sends to another Worker • Handler to network never blocks

22. Apache Multi-Process Module Structure, correctness similar to FlumeWiki

23. Potential violations: • “No read” • “Export private” ClamAV Scanner Module Network Key: ClamAV bar.txt password.txt …

24. OpenVPN • Potential violations: • “No read” • “Inter-network leak” Network1 OpenVPN Key: Network2

25. Performance Evaluation Tool verified all correct programs, found all violations in buggy programs. For no random isolation, a few minutes For random isolation approx. 1 hour

26. Conclusion DIFC correctness is a safety problem Need summarization for feasibility, random isolation for precision DIFC properties can be checked for real-world programs

27. Questions?

28. Performance Measures