Cocoon: Static Information Flow Control in Rust

TL;DR

Cocoon addresses the challenge of providing fine-grained information flow control for mainstream imperative code by delivering a static, type-based IFC system implemented as a Rust library that works with the unmodified Rust compiler. It introduces a Secret<Type,Label> value abstraction and a secret_block! macro alongside a rudimentary effect system to constrain data and control dependencies, while enabling declassification under audited conditions. The authors demonstrate practicality through real-world retrofits of Spotify TUI and Servo, showing negligible run-time overhead and modest compile-time impact, with a broader performance evaluation indicating similar trends across benchmarks. While effective and incrementally deployable, Cocoon is limited to static secrecy labels, imposes restrictions on certain language features, and relies on a trusted codebase for allowlisted library components and macros.

Abstract

Information flow control (IFC) provides confidentiality by enforcing noninterference, which ensures that high-secrecy values cannot affect low-secrecy values. Prior work introduces fine-grained IFC approaches that modify the programming language and use nonstandard compilation tools, impose run-time overhead, or report false secrecy leaks -- all of which hinder adoption. This paper presents Cocoon, a Rust library for static type-based IFC that uses the unmodified Rust language and compiler. The key insight of Cocoon lies in leveraging Rust's type system and procedural macros to establish an effect system that enforces noninterference. A performance evaluation shows that using Cocoon increases compile time but has no impact on application performance. To demonstrate Cocoon's utility, we retrofitted two popular Rust programs, the Spotify TUI client and Mozilla's Servo browser engine, to use Cocoon to enforce limited confidentiality policies.

Figures (10)

• Figure 1: Rust code that computes the overlapping number of days in two calendars.
• Figure 3: Cocoon's programming model.
• Figure 4: Outer transformations performed by Cocoon's procedural macros on secret blocks and side-effect-free functions. $\tau(\mathit{expr}, \mathit{isExec})\xspace$ generates transformed code for expression $\mathit{expr}$ at macro expansion time, where $\mathit{isExec}$ is a boolean indicating whether the transformation is for the executed or nonexecuted version of generated code. \ref{['fig:transf-all-exprs']} details how $\tau(\mathit{expr}, \mathit{isExec})\xspace$ is defined for various kinds of expressions.
• Figure 5: Expression-level transformations performed by Cocoon's procedural macros on secret blocks and side-effect-free functions. $\tau(\mathit{expr}, \mathit{F})$ and $\tau(\mathit{expr}, \mathit{T})$ represent syntactic expansions for the nonexecuted and executed code paths, respectively. stands for "check invisible side effect free."
• Figure 6: Traits used by Cocoon to enforce programming model restrictions to ensure side effect freedom.