First-order Gradual Information Flow Types with Gradual Guarantees Abhishek Bichhawat, McKenna McCall and Limin Jia Carnegie Mellon University, Pittsburgh, USA {abichhaw, mckennak, liminjia}@andrew.cmu.edu Abstract Information flow type systems enforce the security property of noninterference by detecting unauthorized data flows at compile- time. However, they require precise type annotations, making them difficult to use in practice as much of the legacy infrastructure is written in untyped or dynamically-typed languages. Gradual typing seamlessly integrates static and dynamic typing, providing the best of both approaches, and has been applied to information flow control, where information flow monitors are derived from gradual security types. Prior work on gradual information flow typing uncovered tensions between noninterference and the dynamic gradual guarantee—the property that less precise security type annotations in a program should not cause more runtime errors. This paper re-examines the connection between gradual information flow types and information flow monitors to identify the root cause of the tension between the gradual guarantees and noninterference. We develop runtime semantics for a simple imperative language with gradual information flow types that provides both noninterference and gradual guarantees. We leverage a proof technique developed for FlowML and reduce noninterference proofs to preservation proofs. I. INTRODUCTION Information flow type systems combine types and security labels to ensure that well-typed programs do not leak secrets to attackers at compile-time [1]. However, purely statically-typed languages face significant adoption challenges. Most program- mers are unfamiliar with and may be unwilling to use complex information flow type systems. Moreover, much of the legacy infrastructure is written in untyped and dynamically-typed languages without precise security type annotations. Gradual typing is one promising technique to address these challenges [2]; it aims to seamlessly integrate statically-typed programs with dynamically-typed programs. At a high-level, gradual type systems introduce a dynamic type, often written as ?, to accommodate untyped portions of the program. The type system allows any program to be typed under ?. The type system enforces type safety on statically typed parts and the runtime semantics of gradual type systems monitor the interactions between parts typed as ? and statically typed parts to ensure type preservation. Gradual typing has been applied to information flow types [3]–[7], where certain expressions have a dynamic security label ? (and are typed as, e.g., int?), which is determined at runtime. Information flow monitors are then derived from the runtime semantics of gradual information flow types. Earlier adoptions of gradual typing to information flow types have developed ad hoc approaches to treat “gradual types”. For instance, Disney and Flanagan did not include a dynamic security label [3]. Instead, the programmer would insert type casts, which are checked at runtime, and are used to “gradually” make the programs more secure. Later, ML-GS [4] and LJGS [5] included the dynamic security label ? and a runtime monitor that performed checks on the dynamically typed parts of the program. Programmers still need to write annotations and casts in ML-GS and arXiv:2003.12819v3 [cs.PL] 9 Feb 2021 label constraints in LJGS. The dynamic label is instantiated as a single security label at run time in both ML-GS and LJGS. At the same time, interests in the formal foundations of gradual types grew significantly. Formal properties related to gradual typing such as the gradual guarantee [8] were introduced, which says that loosening policies should not cause more type errors or runtime failures. Roughly, the gradual guarantee ensures that programs which type-check and run to completion with precise type annotations will also type-check and run to completion with less precise types, i.e., ?. This property ensures that programmers are not punished for not specifying type annotations if the program is safe. Such a guarantee is important for information flow type systems, as security annotations have been a road block for adoption. Without the gradual guarantee, the programmers’ burden of providing (unnecessary) security annotations is increased. Garcia et al. developed the abstracting gradual typing (AGT) framework which provides a formal interpretation of gradual type systems [9]. In AGT, a principled interpretation of the dynamic type is that it represents the set of all possible types that are refined by the monitor to preserve type safety at runtime. By that interpretation, the semantics of the dynamic information flow label ? is the set of all possible labels. Early work on gradual information flow typing all instantiate the dynamic label as a single label at runtime [4], [5]. Recent work by Toro et al., GSLRef , aims to apply the AGT framework to information flow types [6]; however, it has to give up the dynamic gradual guarantee in favor of noninterference, the key information flow security property [10], when dealing with mutable references. In this paper, we re-examine the connection between gradual information flow types and information flow monitors (c.f. [11]– [13]). We aim to identify the root cause of the tension between the dynamic gradual guarantee and security in systems that refine the set of possible labels for dynamically labeled programs at runtime. To this end, we focus on a simple imperative 1 language with first-order stores, which has been widely used to design information flow control systems [1], [13]–[17]. While simple, this language includes all the features to illustrate the problem of refining dynamic labels at runtime. We develop runtime semantics for this language with gradual information flow types that enjoy both noninterference and the dynamic gradual guarantee. We draw ideas from abstracting gradual typing, which advocates deriving runtime semantics for gradual types via the preservation proof [9]. We observe that as dynamic labels are updated, the semantics that only gradually refine the possible security labels during program execution resemble a naive flow-sensitive monitor and therefore inherit the problems with implicit leaks of flow- sensitive monitors [11]. To enforce noninterference and remove the implicit leaks caused by insecure writes in branches, the runtime semantics needs to take into consideration the variable and channel writes in the untaken branch [13]. Pure guessing which ignores information about the untaken branch like GSLRef ’s runtime yields rigid semantics that break the gradual guarantee (more in Section III-D). The no-sensitive-upgrade (NSU) check [11] also doesn’t solve the problem. Instead, a “hybrid” approach [13], [17] that leverages static analysis to obtain the write effects of the untaken branch and upgrade relevant references for both branches can be used to remove the implicit leaks and provide the gradual guarantees. We leverage a proof technique developed for FlowML, which reduces noninterference proofs to preservation proofs [18]. The main idea is to extend the language with pairs of expressions and commands, representing two executions with different secrets in one program. Noninterference follows from preservation. This proof technique clearly illustrates the problem with purely dynamic flow-sensitive monitors and naturally suggests the hybrid approach [13], [17]. To summarize, we study the connection between gradual security types and information flow monitors and identify the conservative handling of implicit flows in GSLRef as the reason that it gives up dynamic gradual guarantee in favor of noninterference. Additionally, we show that the dynamic gradual guarantee can be recovered by using a hybrid approach that leverages the static phase to generate a list of variables that are written to in both the branches. Due to space constraints, we omit detailed definitions and proofs, which can be found in the full version of the paper [19]. II. OVERVIEW OF INFORMATION FLOW CONTROL In information flow control systems, variables are annotated with a label from a security lattice, which have a partial-ordering (4) and a well-defined join and meet operation. ℓ1 4 ℓ2 means information can flow from ℓ1 to ℓ2. Consider a two-point security lattice with labels {L,H} with L 4 H where L represents public and H represents secret. A variable x having type intH contains a sensitive integer value. Information flows can be broadly classified as explicit or implicit [10], [20]. Explicit flows arise from variable assignments. For instance, the statement x = y + z causes an explicit flow of values from y and z to x. Implicit flows arise from control structures in the program. For example, in the program l = false; if(h){l = true; }, there is an implicit flow of information from h to the final value of l (it is true iff h is true). Implicit flows are handled by maintaining a pc (program-context) label, which is an upper bound on the labels of all the predicates that have influenced the control flow thus far. In the example, the pc inside the branch is the label of h. Information flow control systems aim to prevent leaks through these flows by either enforcing information flow typing rules and ruling out insecure programs at compile-time or dynamically monitoring programs and aborting the execution of insecure programs. In both systems, assignment to a variable is disallowed if either the pc label or the join of the label of the operands is not less than or equal to the label of the variable being assigned [1], [11]. Thus, in the above examples, if either the label of y or z is greater than the label of x or the label of h is greater than the label of l, the assignment does not type-check or the execution aborts at runtime. This guarantees a variant of noninterference, known as termination-insensitive noninterference [1], which we prove for our gradual type system. We assume that an adversary cannot observe or gain any information if a program’s execution diverges or aborts and can only observe “public” outputs by the program.