Static enforcement of security with types

Abstract

A number of security systems for programming languages have recently appeared, including systems for enforcing some form of access control . The Java JDK 1.2 security architecture is one such system that is widely studied and used. While the architecture has many appealing features, access control checks are all implemented via dynamic method calls. This is a highly non-declarative form of specification which is hard to read, and which leads to additional run-time overhead. In this paper, we present a novel security type system that enforces the same security guarantees as Java Stack Inspection, but via a static type system with no additional run-time checks. The system allows security properties of programs to be clearly expressed within the types themselves. We also define and prove correct an inference algorithm for security types, meaning that the system has the potential to be layered on top of the existing Java architecture, without requiring new syntax.

Flow-insensitive type qualifiers

“…A major topic of recent interest is secure information flow [Abadi et al 1999;Denning 1976;Smith and Volpano 1998;Volpano and Smith 1997], which associates high and low security levels with expressions and tries to prevent high-security data from "leaking" to low-security outputs. Other examples of security-related annotation systems are lambda calculus with trust annotations [Ørbaek and Palsberg 1997] and Java security checking [Skalka and Smith 2000]. These systems include checks for implicit flows from conditional guards to the body of the conditional.…”

A static type system for JVM access control

“…Based on this insight, Skalka and Smith [2000] have developed a static type system of code-level access control for a variant of the lambda calculus by refining the type system of the lambda calculus with access privilege information. They have proved the soundness of the type system, which ensures that a well-typed program will not cause security violation.…”

“…Pottier et al [2005] further refined this type system. Banerjee and Naumann [2001] have defined a denotational semantics for a language similar to the calculus considered in Skalka and Smith [2000] and Pottier et al [2005], which provides additional assurance of the safety of this type-based approach. As a static verification system, this approach does not incur any runtime overhead, and detects all access violations at compile time.…”

“…Since underlying type systems only check the type consistency of each instruction against the machine state and do not reflect static semantics of the code, it is not immediately obvious that the idea of static access effect, as exploited in Skalka and Smith [2000] and Pottier et al [2005], can be smoothly integrated.…”

“…In this formalism, the type system represents static semantics of a code language, just as the type system of the lambda calculus does. This property allows us to transfer the concepts and methods developed for the lambda calculus in Skalka and Smith [2000] to the Java bytecode language.…”