Permissive dynamic information flow analysis

Abstract

A key challenge in dynamic information flow analysis is handling implicit flows, where code conditional on a private variable updates a public variable x. The naive approach of upgrading x to private results in x being partially leaked, where its value contains private data but its label might remain public on an alternative execution (where the conditional update was not performed). Prior work proposed the no-sensitive-upgrade check, which handles implicit flows by prohibiting partially leaked data, but attempts to update a public variable from a private context causes execution to get stuck.To overcome this limitation, we develop a sound yet flexible permissive-upgrade strategy. To prevent information leaks, partially leaked data is permitted but carefully tracked to ensure that it is never totally leaked. This permissiveupgrade strategy is more flexible than the prior approaches such as the no-sensitive-upgrade check.Under the permissive-upgrade strategy, partially leaked data must be marked as private before being used in a conditional test, thereby ensuring that it is private for both the current execution as well as alternate execution paths. This paper also presents a dynamic analysis technique for inferring these privatization operations and inserting them into the program source code. The combination of these techniques allows more programs to run to completion, while still guaranteeing termination-insensitive non-interference in a purely dynamic manner.

Dynamic vs. Static Flow-Sensitive Security Analysis

“…Having both is impossible: a purely dynamic flow-sensitive monitor (as, e.g., [5], [6]) will inevitably reject programs that are typable by HuntSands-style type system. To the best of our knowledge, there are no prior impossibility results on permissive purely dynamic monitoring of information-flow policies.…”

“…For flow-sensitive monitoring [5], [6], we believe Properties 1-3 hold, but, as we discuss in Section VIII, Property 4 does not hold because it is not allowed to first relabel a public variable in high context and then branch on it. This is consistent with our result that having all of Properties 1-4 is impossible in a flow-sensitive setting.…”

“…Austin and Flanagan [5], [6] suggest a purely dynamic monitor for information flow with a limited form of flow sensitivity. They discuss two disciplines: no sensitive-upgrade, where the execution gets stuck on an attempt to assign to a public variable in secret context, and permissive-upgrade, where on an attempt to assign to a public variable in secret context, the public variable is marked as one that cannot be branched on later in the execution.…”

“…Recently, it has been shown (e.g., [43], [5], [4], [39], [6]) that purely dynamic monitors can enforce the same security policy as Denning-style static analysis: terminationinsensitive noninterference. In addition, Sabelfeld and Russo [43] prove that sound purely dynamic information-flow enforcement is more permissive than static analysis in the flow-insensitive case (where variables are assigned security levels at the beginning of the execution and this assignment is kept unchanged during the execution).…”

On-the-fly inlining of dynamic security monitors

“…Mozilla's ongoing project FlowSafe [9] aims at empowering Firefox with runtime information-flow tracking, where dynamic information-flow reference monitoring [2,3] lies at its core. The driving force for using the dynamic techniques is expressiveness: as more information is available at runtime, it is possible to use it and accept secure runs of programs that might be otherwise rejected by static analysis.…”