A common mechanism for ensuring that software behaves securely is to monitor programs at run time and check that they dynamically adhere to constraints specified by a security policy. Whenever a program monitor detects that untrusted software is attempting to execute a dangerous action, it takes remedial steps to ensure that only safe code actually gets executed. This article improves our understanding of the space of policies enforceable by monitoring the run-time behaviors of programs. We begin by building a formal framework for analyzing policy enforcement: we precisely define policies, monitors, and enforcement. This framework allows us to prove that monitors enforce an interesting set of policies that we call the infinite renewal properties. We show how, when given any reasonable infinite renewal property, to construct a program monitor that provably enforces that policy. We also show that the set of infinite renewal properties includes some nonsafety policies, i.e., that monitors can enforce some nonsafety (including some purely liveness) policies. Finally, we demonstrate concrete examples of nonsafety policies enforceable by practical run-time monitors. Categories and Subject Descriptors: D.2.0 [Software Engineering]: General—protection mechanisms;

Secure cooperation is the problem of protecting mutually suspicious code units within the same execution environment from their potentially malicious peers. A statically enforceable capability type system is proposed for the JVM bytecode language to provide fine-grained access control of shared resources among peer code units. The design of the type system is inspired by recent advances in alias control type systems for object-oriented programming languages. The exercise of access rights and the propagation of capabilities are given a uniform interpretation as alias creation events. Each capability type assigns to a reference a dataflow trajectory, prescribing the set of aliases that is allowed to be created from the reference. An orthogonal and complementary type system for controlling object creation and downcasting is also designed to avoid a class of capability spoofing attacks. The combined type system successfully addresses a number of classical protection problems recast in a programming language context. This work therefore demonstrates the need and the feasibility of a languagebased approach to enforce application-level security among peer code units.

In recent years it has been shown that dynamic monitoring can be used to soundly enforce information flow policies. For programs distributed in source or bytecode form, the use of JIT compilation makes it difficult to implement monitoring by modifying the language runtime system. An inliner avoids this problem and also serves to provide monitoring for more than one runtime. We show how to inline an information flow monitor, specifically a flow sensitive one previously proved to enforce termination insensitive noninterference. We prove that the inlined version is observationally equivalent to the original. 1.

Language-based information-flow security considers programs that manipulate pieces of data at different sensitivity levels. Securing information flow in such programs remains an open challenge. Recently, considerable progress has been made on understanding dynamic monitoring for secure information flow. This paper presents a framework for inlining dynamic information-flow monitors. A novel feature of our framework is the ability to perform inlining on the fly. We consider a source language that includes dynamic code evaluation of strings whose content might not be known until runtime. To secure this construct, our inlining is done on the fly, at the string evaluation time, and, just like conventional offline inlining, requires no modification of the hosting runtime environment. We present a formalization for a simple language to show that the inlined code is secure: it satisfies a noninterference property. We also discuss practical considerations and preliminary experimental results.

Traditional approaches to protecting computer systems from malicious or other misbehaved code typically involve (1) monitoring code for unacceptable behavior as it runs, or (2) detecting potentially misbehaved code and preventing it from running at all. These approaches are effective when unacceptable behavior can be detected in time to take remedial action, but in many settings and for many im-portant security policies this is computationally expensive or provably impossible. A third approach, termed in this dissertation program-rewriting, involves auto-matically rewriting code prior to running it in such a way that acceptable behavior is preserved but unacceptable behavior is not. Rewritten code can be run without further analysis or monitoring because it is guaranteed to exhibit only acceptable behavior. Program-rewriting has received recent attention in the literature in the form of in-lined reference monitors, which implement approach 1 above by in-lining security checks directly into the code being monitored. Program-rewriting generalizes in-lined reference monitoring, encompassing many other strategies for automatically rewriting programs as well.

Abstract: Eliciting non-functional security requirements within a company was one of the major aspects of the SIKOSA 1 project [WKKG07]. Scenarios, such as the METRO one presented in this paper, show how besides the company's internal requirements, customers ' preferences play an important role as well. However, conflicts between specific customers ' privacy policies and the company's one need to be detected and dealt with. We present a policy language able to tackle the comparison problem and outline a monitor for the enforcement of such policies. 1

Type-based protection mechanisms in a JVM-like environment must be administrated by the code consumer at the bytecode level. Unfortunately, formulating a sound static type system for the full JVM bytecode language can be a daunting task. It is therefore counter-productive for the designer of a bytecode-level type system to address the full complexity of the VM environment in the early stage of design. In this work, a lightweight modeling tool, Featherweight JVM, is proposed to facilitate the early evaluation of bytecode-level, type-based protection mechanisms. In the style of Security Automata, Featherweight JVM is an event model that tracks interprocedural access events generated by a JVM-like environment. The effect of deploying a typebased protection mechanism can be modeled by a safety policy that restricts the event sequences produced by the VM model. To evaluate the effectiveness of the protection mechanism, security theorems in the form of state invariants can then be proven in the policy-guarded VM model. This paper provides first evidence on the utility of this approach in providing early feedback to the designer of type-based protection mechanisms for JVM-like environments. 1.

The need for secure computing first became apparent in the early 1970’s, when the high cost of hardware forced users to share standalone computers by time-multiplexing the processor. Concurrent processes had to be isolated from each other in order to prevent the bugs of one process from disrupting the execution of another. Different processes resided in separate regions of memory

Abstract — Policy-based approaches to the management of systems distinguish between the specification of requirements, in the form of policies, and their enforcement on the system. In this work we focus on the latter aspect and investigate the enforcement of stateful policies in a concurrent environment. As a representative of stateful policies we use the UCON model and show how dependencies between policy rules affect their enforcement. We propose a technique for enforcing policies concurrently based on the static analysis of dependencies between policies. The potential of our technique for improving the efficacy of enforcement mechanisms is illustrated using a small, but representative example. I.

Abstract. We propose an extension to the security model of Java. It allows for specifying, analysing and enforcing history-based policies. Policies are defined by finite state automata recognizing the permitted execution histories. Programmers can sandbox an untrusted piece of code with a policy, which is enforced at run-time through its local scope. A static analysis allows for optimizing the execution monitor, that will only check the program points where some security violation may actually occur. 1