Verifying Information Flow Control Over Unbounded Processes

Verifying Information Flow Control Over Unbounded ProcessesWilliam R. Harris, Nicholas A. Kidd,Sagar Chaki, Somesh Jha, and Thomas RepsTexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AA-check Sagars affiliation1An unsecured serverTrustedCompromisedInvalidRequestHandlerWorker0Worker1WorkerNKey:buffer.txt-explain colors-explicitly state policy (use source, sink instead of non-interference)2Decentralized Information Flow Control (DIFC)Privacy of information controlled by application

Application uses labels, system enforces label semantics

Not multi-trace properties3-say that all systems are similar, but we adopt conventions for Flume for the paperA secured serverTrustedCompromisedInvalidRequestHandlerWorker0Worker1WorkerN{0}{1}{n}{0}Key:buffer.txt:({0} {n})4void Handler() {while (*) {Request r = get_next_http_request();Endpoint e0, e1;create_channel(&e0, &e1);spawn(/usr/bin/Worker, e1, r);send_ack();}}Simplified Server Code5-explicitly say that this is (very nearly) FlumeWiki-mention functionality policiesvoid 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();}}Server code with Flume6-explicitly say that this is (very nearly) FlumeWikiThe ProblemDIFC gives powerful low-level mechanismsSemantic gap between high-level policy, low-level mechanismsAutomatically validate that application follows policyA first cut at a solutionDIFC policies are safety properties

So apply a model checker for safety properties!not so fastKey system objects can be dynamically allocated

Summarize?An abstracted serverTrustedCompromisedInvalidRequestHandlerSummaryWorker 0{S}{S}{S}Key:buffer.txt{S} {S}Summary Worker 110-animate multiple arrows pointing to summary worker-why is there one concrete worker? Tradeoff: messier to explain that its now not OK for a worker to send data to itself.Random isolation [Kidd 09] to the rescue!Finding Concurrency-Related Bugs Using Random Isolation11A randomly isolated serverTrustedCompromisedInvalidRequestHandlerWorker0{C}{C}Key:buffer.txt: ({C} {S}){S}Summary Worker12-we only need to consider executions where the isolated, concrete Worker gets an isolated concrete tagKey takeawaysInformation flow control policies for DIFC systems are safety properties

Summarization makes checking feasible

Random isolation makes checking preciseAnalysis architectureProgram:ConcretesemanticsProgram:Rand. Iso.semanticsProgram:AbstractsemanticsCopper[Chaki 04] SAFEErrorPolicyInstrumentationAbstraction14-WE DID INSTRUMENTATION AND ABSTRACTION-work backwards, say what each phase needs/assumes-Efficient Verification of Sequential and Concurrent C ProgramsAllocating a tag: concretetutuvlab := create_tag();lablab15-explain representation of a state-explain transformations over a state-policy: a formula that should hold over all reachable states in the programtutuvlab := create_tag();lablablablabAllocating a tag: summarizationsumsum16lab: isolabtutuvlablab: iso: iso: isoisoisoif (!has_alloc && nondet()) { lab := create_iso(); has_alloc = true;}else { lab := create_noniso();}Allocating a tag:random isolationsumsum: isoconc: iso17-how to bridge gap from quantifying over processes to isolating tags?-practice this slide to deathRepresentation in Predicate AbstractionInstrument allocation functions

Every relation is a function

Eg. Subset{C} {S} = 0{C} {C} = 1{C} {C, S} = 1{S} {S} = *{C, S} {C, S} = *Experiments20Designed to demonstrate that:-Can check practical policies.-Can use random isolation to reason with precision.-Can reason efficiently about real-world programs.FlumeWikiA wiki software package designed for secure information flow.

Policies:No Worker sends to another WorkerHandler to network never blocksApache Multi-Process ModuleStructure, correctness similar to FlumeWikiClamAV Scanner ModuleCompromisedMust-be-validInvalidClamAVpassword.txtbar.txtNetworkPotential violations: No read Export privateKey:23-explain violations-explain injected faultsOpenVPNOpenVPNNetwork2Network1Potential violations: No read Inter-network leakTrustedInvalidKey:Performance EvaluationTool verified all correct programs, found all violations in buggy programs.

For no random isolation, a few minutes

For random isolation approx. 1 hourConclusionDIFC correctness is a safety problem

Need summarization for feasibility, random isolation for precision

DIFC properties can be checked for real-world programs26Q: Do we really need to do summarization? Couldnt we just seed Copper with the right predicate to track that tags for different processes are distinguished?A: Have to summarize the set of processes, need a summary tag when you merge distinct concrete tags.Questions?-spotlight abstractions: similar principles. Apparent differences: +They only consider local properties. +They do the spotlighting iteratively with predicate abstraction, we do transformations entirely before. +Our transformation should be sound, helpful in the presence of existential properties.-we can check multiple properties at once27Performance MeasuresProgramSize (LOC)# Procs (runtime)VersionResultTimeFlumeWiki110unboundedCorrectSafe1h 9m 16sInterferenceBug37m 53sApache596unboundedCorrectSafe1h 13m 27sInterferenceBug18m 30sClamAV34272CorrectSafe7m 55sNo ReadBug3m 25sExportBug3m 25sOpenVPN29,4943CorrectSafe2m 17sNo ReadBug2m 52sLeakBug2m 53s