HLIO: mixing static and dynamic typing for information-flow control in Haskell

We present the foundations for a new dynamic information flow control (IFC) parallel runtime system, LIOPAR. To our knowledge, LIOPAR is the first dynamic language-level IFC system to (1) support deterministic parallel thread execution and (2) eliminate both internaland external-timing covert channels that exploit the runtime system. Most existing IFC systems are vulnerable to external timing attacks because they are built atop vanilla runtime systems that do not account for security-these runtime systems allocate and reclaim shared resources (e.g., CPU-time and memory) fairly between threads at different security levels. While such attacks have largely been ignored-or, at best, mitigated-we demonstrate that extending IFC systems with parallelism leads to the internalization of these attacks. Our IFC runtime system design addresses these concerns by hierarchically managing resourcesboth CPU-time and memory-and making resource allocation and reclamation explicit at the language-level. We prove that LIOPAR is secure, i.e., it satisfies progress-and timing-sensitive non-interference, even when exposing clock and heap-statistics APIs.

Section: Core Schedulermentioning

confidence: 99%

“…In Sect. 5.1, we describe our proof technique based on term erasure, which has been used to verify security guarantees of functional programming languages [30], IFC libraries [8,17,54,56,61], and an IFC runtime system [59]. In Sect.…”

Section: Security Guaranteesmentioning

confidence: 99%

Foundations for Parallel Information Flow Control Runtime Systems

Vassena

Soeller

Amidon

et al. 2019

“…However, the function in Figure 5 can easily be generalized to a function working on an arbitrary data structure containing files with different labels from an arbitrary lattice. Similar to the approach taken by Buiras et al [11] that hide the label of a labeled value using a data type definition, we hide the label of a secure file with a dependent pair GenFile : Type -> Type GenFile label = (l : label ** SecFile l) that abstracts away the concrete sensitivity level of the file. Moreover, we introduce a specialized join function joinOfFiles : BoundedJoinSemilattice label => List (GenFile label) -> label that folds the join function over a list of file sensitivity labels.…”

Section: Policy-parameterized Functionsmentioning

confidence: 99%

“…Pure functional programming languages, like Haskell, have something to offer with respect to information security as they strictly separate side-effect free and side-effectful code. This makes it possible to enforce lightweight information-flow control through libraries [11,19,33,34,41] by constructing an embedded domain-specific security sub-language. Such libraries enforce a secure-by-construction programming model as any program written against the library interface is not capable of leaking secrets.…”

Section: Introductionmentioning

confidence: 99%

A Dependently Typed Library for Static Information-Flow Control in Idris

Gregersen

Thomsen

Askarov

2019

Safely integrating third-party code in applications while protecting the confidentiality of information is a long-standing problem. Pure functional programming languages, like Haskell, make it possible to enforce lightweight information-flow control through libraries like MAC by Russo. This work presents DepSec, a MAC inspired, dependently typed library for static information-flow control in Idris. We showcase how adding dependent types increases the expressiveness of state-of-the-art static information-flow control libraries and how DepSec matches a special-purpose dependent information-flow type system on a key example. Finally, we show novel and powerful means of specifying statically enforced declassification policies using dependent types.

“…We have included two larger examples in the extended version [12]. One builds from recent work on deferring constraints until runtime [2] and the other on translating a dependently typed program from Agda [16] into Haskell.…”

Section: Why Visible Type Application?mentioning

confidence: 99%

Visible Type Application

Eisenberg

Weirich

Ahmed

2016

Abstract. The Hindley-Milner (HM) type system automatically infers the types at which polymorphic functions are used. In HM, the inferred types are unambiguous, and every expression has a principal type. Type annotations make HM compatible with extensions where complete type inference is impossible, such as higher-rank polymorphism and type-level functions. However, programmers cannot use annotations to explicitly provide type arguments to polymorphic functions, as HM requires type instantiations to be inferred. We describe an extension to HM that allows visible type application. Our extension requires a novel type inference algorithm, yet its declarative presentation is a simple extension to HM. We prove that our extended system is a conservative extension of HM and admits principal types. We then extend our approach to a higher-rank type system with bidirectional type-checking. We have implemented this system in the Glasgow Haskell Compiler and show how our approach scales in the presence of complex type system features.