Enforcing Non-safety Security Policies with Program Monitors.
ABSTRACT We consider the enforcement powers of program monitors, which intercept security-sensitive actions of a target application at run time and take remedial steps whenever the target attempts to execute a potentially dangerous action. A common belief in the security commu- nity is that program monitors, regardless of the remedial steps available to them when detecting violations, can only enforce safety properties. We formally analyze the properties enforceable by various program monitors and nd that although this belief is correct when considering monitors with simple remedial options, it is incorrect for more powerful monitors that can be modeled by edit automata. We dene an interesting set of properties called innite renewal properties and demonstrate how, when given any reasonable innite renewal property, to construct an edit au- tomaton that provably enforces that property. We analyze the set of innite renewal properties and show that it includes every safety prop- erty, some liveness properties, and some properties that are neither safety nor liveness.
- SourceAvailable from: Douglas R. Smith[Show abstract] [Hide abstract]
ABSTRACT: The aim of this project is to develop a feasible design for a Model Development Environment that supports the development of net-centric systems with guarantees of user-specified safety and information assurance policies. This paper focuses on (1) a policy language for expressing system safety and information assurance constraints, (2) analysis mechanisms for detecting policy applicability in a model, and (3) enforcement mechanisms and associated assurance arguments and evidence. An overarching objective is to lower the cost of producing certified software that is ready for service in a SOA. This entails lowering the cost of initial certification and the cost of recertification after modifications.
- [Show abstract] [Hide abstract]
ABSTRACT: Edit automata have been introduced by J.Ligatti et al. as a model for security enforcement mechanisms which work at run time. In a distributed interacting system, they play a role of a monitor that runs in parallel with a target program and transforms its execution sequence into a sequence that obeys the security property. In this paper, we characterize security properties which are enforceable by finite edit automata (i.e. edit automata with a finite set of states) and deterministic context-free edit automata (i.e. finite edit automata extended with a stack). We prove that the properties enforceable by finite edit automata are a sub-class of regular sets. Moreover, given a regular set $P$ , one can decide in time $O(n^2)$ , whether $P$ is enforceable by a finite edit automaton (where $n$ is the number of states of the finite automaton recognizing $P$ ) and we give an algorithm to synthesize the controller. Moreover, we prove that safety policies are always enforced by a deterministic context-free edit automaton. We also prove that it is possible to check if a policy is a safety policy in $O(n^4)$ . Finally, we give a topological condition on the deterministic automaton expressing a regular policy enforceable by a deterministic context-free edit automaton.International Journal of Information Security 08/2013; 12(4). · 0.48 Impact Factor
- [Show abstract] [Hide abstract]
ABSTRACT: Runtime enforcement is a common mechanism for ensuring that program executions adhere to constraints specified by a security policy. It is based on two simple ideas: the enforcement mechanism should leave good executions without changes transparency and make sure that the bad ones got amended soundness. From the theory side, a number of papers Hamlen et al., Ligatti et al., Talhi et al. provide the precise characterization of good executions that can be captured by a security policy and thus enforced by mechanisms like security automata or edit automata.Unfortunately, transparency and soundness do not distinguish what happens when an execution is actually bad the practical case. They only tell that the outcome of enforcement mechanism should be “good” but not how far the bad execution should be changed. So we cannot formally distinguish between an enforcement mechanism that makes a small change and one that drops the whole execution.In this paper we explore a set of policies called iterative properties that revises the notion of good executions in terms of repeated iterations. We propose an enforcement mechanism that can deal with bad executions and not only the good ones in a more predictable way by eliminating bad iterations.Journal of Computer Security. 01/2012; 20(1):51-79.
Enforcing Non-safety Security Policies with
Jay Ligatti1, Lujo Bauer2, and David Walker1
2Carnegie Mellon University
Department of Computer Science
Technical Report TR-720-05
January 31, 2005
Abstract. We consider the enforcement powers of program monitors,
which intercept security-sensitive actions of a target application at run
time and take remedial steps whenever the target attempts to execute a
potentially dangerous action. A common belief in the security commu-
nity is that program monitors, regardless of the remedial steps available
to them when detecting violations, can only enforce safety properties. We
formally analyze the properties enforceable by various program monitors
and find that although this belief is correct when considering monitors
with simple remedial options, it is incorrect for more powerful monitors
that can be modeled by edit automata. We define an interesting set of
properties called infinite renewal properties and demonstrate how, when
given any reasonable infinite renewal property, to construct an edit au-
tomaton that provably enforces that property. We analyze the set of
infinite renewal properties and show that it includes every safety prop-
erty, some liveness properties, and some properties that are neither safety
A ubiquitous technique for enforcing software security involves dynamically mon-
itoring the behavior of programs and taking remedial actions when the programs
behave in a way that violates a security policy. Firewalls, virtual machines, and
operating systems all act as program monitors to enforce security policies in this
way. We can even think of any application containing security code that dy-
namically checks input values, queries network configurations, raises exceptions,
warns the user of potential consequences of opening a file, etc. as containing a
program monitor inlined into the application.
Because program monitors, which react to the potential security violations
of target programs, enjoy such ubiquity, it is important to understand their capa-
bilities as policy enforcers. Having well-defined boundaries on the enforcement
powers of security mechanisms allows security architects to determine exactly
when certain mechanisms are needed and saves the architects from attempting
to enforce policies with insufficiently strong mechanisms.
Schneider discovered one particularly useful boundary on the power of certain
program monitors [Sch00]. He defined a class of monitors that respond to po-
tential security violations by halting the target application, and he showed that
these monitors can only enforce safety properties—security policies that specify
that “nothing bad ever happens” in a valid run of the target [Lam77]. When
a monitor in this class detects a potential security violation (i.e., “something
bad”), it must halt the target.
Although Schneider’s result applies only to a particular class of program
monitors, it is generally believed that all program monitors, even ones that
have greater abilities than just to halt the target, are able to enforce only safety
properties. The main result of the present paper is to prove that certain program
monitors can enforce non-safety properties. These monitors are modeled by edit
automata, which have the power to insert actions on behalf of and suppress
actions attempted by the target application. We prove an interesting lower bound
on the properties enforceable by such monitors: a lower bound that encompasses
strictly more than safety properties.
A rich variety of security monitoring systems has been implemented [JZTB98]
[EAC98,ES99,ET99,KVBA+99,BLW03,Erl04,BLW05]. In general, these systems
allow arbitrary code to be executed in response to potential security violations,
so they cannot be modeled as monitors that simply halt upon detecting a vio-
lation. In most cases, the languages provided by these systems for specifying
policies can be considered domain-specific aspect-oriented programming lan-
Theoretical efforts to describe security monitoring have lagged behind the
implementation work, making it difficult to know exactly which sorts of security
policies to expect the implemented systems to be able to enforce. After Schneider
made substantial progress by showing that safety properties are an upper bound
on the set of policies enforceable by simple monitors [Sch00], Viswanathan, Kim,
and others tightened this bound by placing explicit computability constraints on
the safety properties being enforced [Vis00,KKL+02]. Viswanathan also demon-
strated that these computable safety properties are equivalent to CoRE proper-
ties [Vis00]. Fong then formally showed that placing limits on a monitor’s state
space induces limits on the properties enforceable by the monitor [Fon04]. Re-
cently, Hamlen, Schneider, and Morrisett compared the enforcement power of
static analysis, monitoring, and program rewriting [HMS03]. They showed that
the set of statically enforceable properties equals the set of recursively decidable
properties of programs, that monitors with access to source program text can
enforce strictly more properties than can be enforced through static analysis,
and that program rewriters do not correspond to any complexity class in the
In earlier theoretical work, we took a first step toward understanding the en-
forcement power of monitors that have greater abilities than simply to halt the
target when detecting a potential security violation [LBW05]. We introduced edit
automata, a new model that captured the ability of program monitors to insert
actions on behalf of the target and to suppress potentially dangerous actions.
Edit automata are semantically similar to deterministic I/O automata [LT87]
but have very different correctness requirements. The primary contribution of
our earlier work was to set up a framework for reasoning about program monitors
by providing a formal definition of what it even means for a monitor to enforce a
property. Although we also proved the enforcement boundaries of several types of
monitors, we did so in a model that assumed that all target programs eventually
terminate. Hence, from a practical perspective, our model did not accurately
capture the capabilities of real systems. From a theoretical perspective, only
modeling terminating targets made it impossible to compare the properties en-
forceable by edit automata to well-established sets of properties such as safety
and liveness properties.
This paper presents the nontrivial generalization of earlier work on edit au-
tomata [LBW05] to potentially nonterminating targets. This generalization al-
lows us to reason about the true enforcement powers of an interesting and real-
istic class of program monitors, and makes it possible to formally and precisely
compare this class to previously studied classes.
More specifically, we extend previous work in the following ways.
– We refine and introduce formal definitions needed to understand exactly
what it means for program monitors to enforce policies on potentially non-
terminating target applications (Section 2). A new notion of enforcement
(called effective=enforcement) enables the derivation of elegant lower bounds
on the sets of policies monitors can enforce.
– We show why it is commonly believed that run-time monitors enforce only
computable safety properties (Section 3). We show this by revisiting and
extending earlier theorems that describe the enforcement powers of simple
monitors. The earlier theorems are extended by considering nonterminating
targets and by proving that exactly one computable safety property—that
which considers everything a security violation—cannot be enforced by pro-
– We define an interesting set of properties called infinite renewal properties
and demonstrate how, when given any reasonable infinite renewal property,
to construct an edit automaton that provably enforces that property (Sec-
– We prove that program monitors modeled by edit automata can enforce
strictly more than safety properties. We demonstrate this by analyzing the
set of infinite renewal properties and showing that it includes every safety
property, some liveness properties, and some properties that are neither
safety nor liveness (Section 5).
This section provides the formal framework necessary to reason precisely about
the scope of policies program monitors can enforce.
We specify a system at a high level of abstraction as a nonempty, possibly
countably infinite set of program actions A (also referred to as program events).
An execution is simply a finite or infinite sequence of actions. The set of all finite
executions on a system with action set A is notated as A?. Similarly, the set of
infinite executions is Aω, and the set of all executions (finite and infinite) is A∞.
We let the metavariable a range over actions, σ and τ over executions, and Σ
over sets of executions (i.e., subsets of A∞).
The symbol · denotes the empty sequence, that is, an execution with no
actions. We use the notation τ;σ to denote the concatenation of two finite se-
quences. When τ is a (finite) prefix of (possibly infinite) σ, we write τ?σ or,
equivalently, σ?τ. If σ has been previously quantified, we often use ∀τ?σ as an
abbreviation for ∀τ ∈ A?: τ?σ; similarly, if τ has already been quantified, we
abbreviate ∀σ ∈ A∞: σ?τ simply as ∀σ?τ.
2.2Policies and Properties
A security policy is a computable predicate P on sets of executions; a set of
executions Σ ⊆ A∞satisfies a policy P if and only if P(Σ). For example, a
set of executions satisfies a nontermination policy if and only if every execution
in the set is an infinite sequence of actions. A key uniformity policy might be
satisfied only by sets of executions where the cryptographic keys used in all the
executions forms a uniform distribution over the universe of key values.
Following Schneider [Sch00], we distinguish between properties and more gen-
eral policies as follows. A security policy P is a property if and only if there exists
a decidable characteristic predicateˆP over A∞such that for all Σ ⊆ A∞, the
following is true.
P(Σ) ⇐⇒ ∀σ ∈ Σ :ˆP(σ)(Property)
Hence, a property is defined exclusively in terms of individual executions
and may not specify a relationship between different executions of the program.
The nontermination policy mentioned above is therefore a property, while the
key uniformity policy is not. The distinction between properties and policies is
an important one to make when reasoning about program monitors because a
monitor sees individual executions and thus can only enforce security properties
rather than more general policies.
There is a one-to-one correspondence between a property P and its charac-
teristic predicateˆP, so we use the notationˆP unambiguously to refer both to a
characteristic predicate and the property it induces. WhenˆP(σ), we say that σ
satisfies or obeys the property, or that σ is valid or legal. Likewise, when ¬ˆP(τ),
we say that τ violates or disobeys the property, or that τ is invalid or illegal.
Properties that specify that “nothing bad ever happens” are called safety
properties [Lam77]. No finite prefix of a valid execution can violate a safety
property; stated equivalently: once some finite execution violates the property,
all extensions of that execution violate the property. Formally,ˆP is a safety
property on a system with action set A if and only if the following is true.
∀σ ∈ A∞: (¬ˆP(σ) ⇒ ∃σ??σ : ∀τ?σ?: ¬ˆP(τ)) (Safety)
Many interesting security policies, such as access-controlpolicies, are safety prop-
erties where security violations cannot be “undone” by extending a violating
Dually to safety properties, liveness properties [AS85] state that nothing ex-
ceptionally bad can happen in any finite amount of time. Any finite sequence of
actions can always be extended so that it satisfies the property. Formally,ˆP is
a liveness property on a system with action set A if and only if the following is
∀σ ∈ A?: ∃τ?σ :ˆP(τ)(Liveness)
The nontermination policy is a liveness property because any finite execution
can be made to satisfy the policy simply by extending it to an infinite execution.
General properties may allow executions to alternate freely between satisfying
and violating the property. Such properties are neither safety nor liveness but
instead a combination of a single safety and a single liveness property [AS87].
We show in Section 4 that edit automata effectively enforce an interesting new
sort of property that is neither safety nor liveness.
2.3 Security Automata
Program monitors operate by transforming execution sequences of an untrusted
target application at run time to ensure that all observable executions satisfy
some property [LBW05]. We model a program monitor formally by a security
automaton S, which is a deterministic finite or countably infinite state machine
(Q,q0,δ) that is defined with respect to some system with action set A. The set
Q specifies the possible automaton states, and q0 is the initial state. Different
automata have slightly different sorts of transition functions (δ), which accounts
for the variations in their expressive power. The exact specification of a transition
function δ is part of the definition of each kind of security automaton; we only
require that δ be complete, deterministic, and Turing Machine computable. We
limit our analysis in this work to automata whose transition functions take the
current state and input action (the next action the target wants to execute) and
return a new state and at most one action to output (make observable). The
current input action may or may not be consumed while making a transition.