Conference Paper

Enforcing Non-safety Security Policies with Program Monitors

DOI: 10.1007/11555827_21 Conference: Computer Security - ESORICS 2005, 10th European Symposium on Research in Computer Security, Milan, Italy, September 12-14, 2005, Proceedings
Source: DBLP


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.

  • Source
    • "In this regard, Falcone et al. [14] provided the insight that the class of renewal properties is equivalent to the union of four of the six classes of the safety-progress classification of properties [17], namely safety, guarantee, obligation, and response; the property classes of reactivity and persistence contain properties which are not effectively = enforceable Fig. 3 – The set of infinite renewal properties. Source: From [16]. by the edit automaton. "
    [Show abstract] [Hide abstract]
    ABSTRACT: Runtime monitoring is a widely used approach to ensure code safety. Several implementations of formal monitors have been proposed in the literature, and these differ with respect to the set of security policies that they are capable of enforcing. In this survey, we examine the evolution of knowledge regarding the issue of precisely which security policies monitors are capable of enforcing. We identify three stages in this evolution. In the first stage, we discuss initial limits on the set of enforceable properties and various ways in which this set can be extended. The second stage presents studies that identify constraints to the enforcement power of monitors. In the third stage, we present a final series of studies that suggest various alternative definitions of enforcement, which specify both the set of properties the monitors can enforce as well as the manner by which this enforcement is provided.
    Full-text · Article · Jan 2012 · Computer Science Review
  • Source
    • "Note that the requirements (4.1) and (4.2) are not only sufficient to ensure the respect of soundness and transparency requirements introduced at the beginning of Section 4 following Erlingsson (2004), Hamlen et al. (2006) and Ligatti et al. (2005) "
    [Show abstract] [Hide abstract]
    ABSTRACT: Runtime monitors are a widely used approach to enforcing security policies. Truncation monitors are based on the idea of truncating an execution before a violation occurs. Thus, the range of security policies they can enforce is limited to safety properties. The use of an a priori static analysis of the target program is a possible way of extending the range of monitorable properties. This paper presents an approach to producing an in-lined truncation monitor, which draws upon the above intuition. Based on an a priori knowledge of the program behavior, this approach allows, in some cases, to enforce more than safety properties and is more powerful than a classical truncation mechanism. We provide and prove a theorem stating that a truncation enforcement mechanism considering only the set of possible executions of a specific program is strictly more powerful than a mechanism considering all the executions over an alphabet of actions.
    Full-text · Article · Jun 2011 · Computers & Security
  • Source
    • "In this report, we model program executions to be either finite or infinite traces, where a finite trace can be a terminated or a partial execution (i.e. a prefix of a longer trace). Such a way of modeling is slightly different from the standard one in the literature [2] [3] [43] [35] [33] [32] [34] in the following way. The standard model involves only infinite traces (i.e. "
    [Show abstract] [Hide abstract]
    ABSTRACT: The core component of an extensible software system must protect its resources from being abused by untrusted software extensions. The access control policies of extensible software systems are traditionally enforced by some form of reference monitors. Recent study of access control policies advocates the use of obligation policies, which impose behavioural constraints to the future actions of the accessor even after the access is granted. It is argued that obligation policies provide continuous protection to the system. We envision the workflow of developing an obligation policy for program monitoring to involve three stages: specification, implementability check and implementation. In this work, we develop a toolchain to support each stage of the workflow. First, we propose a policy language for formulating obligation policies. Second, we devise a type system for syntactically identifying if an obligation policy is enforceable or not. The type checker guides the policy developer in refining an obligation policy into an enforceable one. Finally, we design a compilation algorithm, which compiles well-typed obligation policies to a representation of reference monitors, called Obligation Monitor (OM). The OM is designed to facilitate monitor inlining.
    Preview · Article · May 2011
Show more