On Dynamic Flow-Sensitive Floating-Label Systems

Abstract

Flow-sensitive analysis for information-flow control (IFC) allows data structures to have mutable security labels, i.e., labels that can change over the course of the computation. This feature is often used to boost the permissiveness of the IFC monitor, by rejecting fewer runs of programs, and to reduce the burden of explicit label annotations. However, adding flow-sensitive constructs (e.g., references or files) to a dynamic IFC system is subtle and may also introduce high-bandwidth covert channels. In this work, we extend LIO-a language-based floatinglabel system-with flow-sensitive references. The key insight to safely manipulating the label of a reference is to not only consider the label on the data stored in the reference, i.e., the reference label, but also the label on the reference label itself. Taking this into consideration, we provide an upgrade primitive that can be used to change the label of a reference in a safe manner. We additionally provide a mechanism for automatic upgrades to eliminate the burden of determining when a reference should be upgraded. This approach naturally extends to a concurrent setting, which has not been previously considered by dynamic flow-sensitive systems. For both our sequential and concurrent calculi we prove non-interference by embedding the flow-sensitive system into the original, flow-insensitive LIO calculus-a surprising result on its own.

Testing noninterference, quickly

“…This allows us to allocate a low block in high context, knowing that at the end of the high context access to these blocks will only be possible through high pointers; this invariant is a cornerstone of our noninterference proof ( §8.4). This is more permissive than the reference allocation rule of Buiras et al (2014), which can only use "the current label" (roughly analogous to our pc label) as "the label on the reference label" (analogous to our block label). We return to the fresh m .…”

“…Similarly, this ensures that no program can vary a pointer based on secrets and then use that pointer to do a store to a block with a public block label, since that block can potentially also be accessible via public pointers that can observe the stored value or its label. This is analogous to one of the checks performed for the upgrade operation of Buiras et al (2014) (upgrade is further discussed below); perhaps surprisingly this it the only check we need for our Store instruction.…”

“…The precise connection to Buiras et al (2014) is discussed throughout this subsection. The main idea is simple: we associate a label with each memory block and this label protects not only the values inside, but also their individual labels (Buiras et al (2014) don't store values in blocks, but use a similar concept called "the label on the reference label"). This block label is chosen by the programmer at allocation time and is fixed throughout execution, while the label on the values in the block can vary more or less arbitrarily.…”

“…The label check is analogous to the one of Buiras et al (2014); it can be broken into two parts: The first part, ( pc ∨ p ) ( b ∨ v ), is more permissive than the ( pc ∨ p ) b check of Store. Because the write keeps the label v unchanged we do not need to additionally protect this label; we only need to protect the new value v and for this v can help.…”

“…This check was unnecessary for Store because the label of the stored value does not change. Buiras et al (2014) also have an upgrade operation that can raise the label of a value in memory before entering a high context. This upgrade operation can in fact be faithfully encoded using our Load and Store instructions (as well as judicious use of Call and Return).…”