Security Enforceable Policies1
Fred B. Schneider Department of Computer Science Cornell University Ithaca, New York 14853
January 15, 1998 Revised July 24, 1999
Supported in part by ARPA/RADC grant F30602-96-1-0317, AFOSR grant F49620-94-1-0198, Defense Advanced Research Projects Agency (DARPA) and Air Force Research Laboratory, Air Force Material Command, USAF, under agreement number F30602-99-1-0533, National Science Foundation Grant 9703470, and a grant from Intel Corporation. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the ocial policies or endorsements, either expressed or implied, of these organizations or the U.S. Government. The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright annotation thereon.
1
Abstract A precise characterization is given for the class of security policies enforceable with mechanisms that work by monitoring system execution, and automata are introduced for specifying exactly that class of security policies. Techniques to enforce security policies specied by such automata are also discussed.
1
Introduction
A security policy denes execution that, for one reason or another, has been deemed unacceptable. For example, a security policy might concern access control, and restrict what operations principals can perform on objects, information ow, and restrict what principals can infer about objects from observing system behavior, or availability, and restrict principals from denying others the use of a resource. To date, general-purpose security policies, like those above, have attracted the most attention. But application-dependent and special-purpose security policies are increasingly important [5, 8, 13, 15, 25, 27, 34]. A system to support mobile code, like Java [11], might prevent information leakage by enforcing a security policy that bars messages from being sent after les have been read. To support electronic commerce, a security policy might prohibit executions in which a customer pays for a service but the seller does not provide that service. And nally, electronic storage and retrieval of intellectual property is governed by rights-management schemes that restrict not only the use of stored materials but also the use of any derivatives [31]. The value of application-dependent and special-purpose security policies is perhaps best explained in terms of the Principle of Least Privilege [29], which holds that each principal be accorded the minimum access needed to accomplish its task. Clearly, richer notions of minimum access allow the Principle of Least Privilege to discriminate better between those actions that should and those that should not be allowed. Application-dependent security policies can depend on an applications state along with the semantics of that applications abstractions, so richer prescriptions for minimum access now become possible. In contrast, operating system abstractions the traditional vocabulary for security policiesconstitute a coarse basis for prescribing minimum access, often forcing security policies to be approximations for what is desired. The practicality of any security policy depends on whether that policy is enforceable and at what cost. This paper addresses those questions for the class of enforcement mechanisms that work by monitoring execution steps of a target and terminating execution that is about to violate the security 1
policy being enforced. We call this class EM, for Execution Monitoring. EM includes security kernels, reference monitors, rewalls, and most other operating system and hardware-based enforcement mechanisms that have appeared in the literature. Our targets may be objects, modules, processes, subsystems, or entire systems; the execution steps monitored may range from ne-grained actions (such as memory accesses) to higher-level operations (such as method calls) to operations that change the security-conguration and thus restrict subsequent execution. Mechanisms that use more information than becomes available only from observing the steps of a targets execution are, by denition, excluded from EM. Information provided to an EM mechanism is thus insucient for predicting future steps the target might take, alternative possible executions, or all possible target executions. Therefore, compilers and theorem-provers, which analyze a static representation of a target to deduce information about all of its possible executions, are not EM mechanisms. The availability of information about future execution, about alternative possible executions, or about all possible target executions gives power to an enforcement mechanismjust how much power is an open question. Also outside EM are mechanisms that modify a target before executing it. The modied target would have to be equivalent to the original, except for aborting executions that would violate the security policy of interest. A denition for equivalent is thus required to analyze this class of mechanisms. A formal characterization of what can and cannot be accomplished using mechanisms in EM has both practical and theoretical utility. Clearly, such a characterization can inform system builders selections of enforcement mechanisms by circumscribing the intrinsic limits of reference monitors and derivative mechanisms. From a theoretical perspective, the characterization constitutes a rst step towards a taxonomy of security policies that is based on a mathematical semantics of programs. Two other classes in that taxonomy might come from relaxing EMs dening restrictions: (i) a class of enforcement mechanisms that have access to some (perhaps incomplete) representation of the target, and (ii) a class of enforcement mechanisms that modify the target before execution. We proceed as follows. In 2, a precise characterization is given for security policies that can be enforced using mechanisms in EM. An automatabased formalism for specifying those security policies is the subject of 3. Mechanisms in EM for enforcing security policies specied by automata are described in 4. Next, 5 discusses some pragmatic issues related to specifying and enforcing security policies as well as the application of our 2
enforcement mechanisms to safety-critical systems. The appendix contains a summary of the notation used in the paper.
2
Characterizing EM Enforcement Mechanisms
We represent target executions by nite and innite sequences, where denotes a universe of all possible nite and innite sequences. The manner in which executions are represented is irrelevant here. Finite and innite sequences of atomic actions, of higher-level system steps, of program states, or of state/action pairs are all plausible alternatives. A target S denes a subset S of corresponding to the executions of S. A characterization of EM-enforceable security policies is interesting only if the denition being used for security policy is broad enough so that it does not exclude things usually considered security policies.1 Also, the denition must be independent of how EM is dened, for otherwise the characterization of EM-enforceable security policies would be a tautology, hence uninteresting. We therefore dene a security policy to be a set of executions, specifying security policies by predicates on sets of executions. This denition is both broad2 (giving at least as much power for dening computations disallowed by security policies as for specifying the computations possible by targets) and corresponds to the intuition that security policies rule out target executions that are deemed unacceptable. A target S satises security policy P if and only if P(S ) equals true. Given a security policy P and sets and of executions, we do not require that if satises P and holds, then satises P. Imposing such a requirement on security policies would disqualify interesting candidates. For instance, the requirement would preclude information ow (as dened informally in 1) from being considered a security policyuniverse of all executions satises information ow, but a subset containing only those executions in which the value of a variable x in each execution is correlated with the value of y (say) clearly violates that information ow policy.
Safety Properties and EM Enforceability
By denition, enforcement mechanisms in EM work by monitoring execution of the target. Thus, any security policy P that can be enforced using a
However, there is no harm in being liberal about what is considered a security policy. The denition clearly subsumes the noninterference-based denition of security policy in [12].
2 1
3
mechanism from EM must be specied by a predicate of the form P() : ( : P()) (1)
where P is a predicate on (individual) executions. P formalizes the criteria used by the enforcement mechanism for deciding to terminate an execution that would otherwise violate the policy being enforced. In [1] and the literature on linear-time concurrent program verication, a set of executions is called a property if set membership is determined by each element alone and not by other members of the set. Using that terminology, we conclude from (1) that a security policy must be a property in order for that policy to have an enforcement mechanism in EM. Not every security policy is a property. Some security policies cannot be dened using criteria that individual executions must each satisfy in isolation. For example, the information ow policy discussed above characterizes sets that are not properties (as proved in [22]3 ). Whether information ows from variable x to y in a given execution depends, in part, on what values y takes in other possible executions (and whether those values are correlated with the value of x). A predicate to specify such sets of executions cannot be constructed only using predicates dened on single executions in isolation. Not every property is EM-enforceable. Enforcement mechanisms in EM cannot base decisions on possible future execution, since that information is, by denition, not available to such a mechanism, and this further restricts what security policies can be enforced by EM mechanisms. Consider security policy P of (1), and suppose is the prex of some nite or innite execution where P() = true and P( ) = false hold. Because execution of a target might terminate before is extended into , an enforcement mechanism for P must prohibit (even though supersequence satises P). We can formalize this requirement as follows. For a nite or innite execution having i or more steps, and a nite execution, let [..i] denote the prex of involving its rst i steps denote execution followed by execution and dene to be the set of all nite prexes of elements in set of nite and/or innite sequences. Then, the above requirement for Pthat P is prex closedis: ( : P( ) ( : P( )))
3
(2)
The author of [22] acknowledged James Gray III as pointing out this limitation for dealing with security in frameworks based on our property abstraction.
4
Finally, note that any execution rejected by an enforcement mechanism must be rejected after a nite period. This is formalized by: ( : P() (i : P([..i]))) (3)
Security policies satisfying (1), (2), and (3) are safety properties [17], properties stipulating that no bad thing happens during any execution. Formally, a property is dened in [18] to be a safety property if and only if, for any nite or innite execution , (i : ( : [..i] )) (4)
holds. This means that is a safety property if and only if can be characterized using a set of nite executions that are prexes of all executions excluded from . Clearly, a security policy P satisfying (1), (2), and (3) has such a set of nite prexesthe set of prexes such that P( ) holdsso P is satised by sets that are safety properties according to (4). The above analysis of enforcement mechanisms in EM has established: Non EM-Enforceable Security Policies: If the set of executions for a security policy P is not a safety property, then an enforcement mechanism from EM does not exist for P. Obviously, the contrapositive holds as well: EM enforcement mechanisms enforce security policies that are safety properties. But, as discussed later in 4, the conversethat all safety properties have EM enforcement mechanisms does not hold. One consequence of our Non EM-Enforceable Security Policies result is that ruling-out additional executions never causes an EM-enforceable policy to be violated, since ruling-out executions never invalidates a safety property. Thus, an EM enforcement mechanism for any security policy P satisfying P P also enforces security policy P. However, a stronger policy P might proscribe executions that do not violate P, so using P is not without potentially signicant adverse consequences. The limit case, where P species the empty set, illustrates this problem. Second, our Non EM-Enforceable Security Policies result implies that EM mechanisms compose in a natural way. When multiple EM mechanisms are used in tandem, the policy enforced by the aggregate is the conjunction of the policies that are enforced by each mechanism in isolation. This is attractive, because it enables complex policies to be decomposed into conjuncts, with a separate mechanism used to enforce each of the component policies. 5
Revisiting the three application-independent security policies described in 1, we nd: Access control denes safety properties. The set of proscribed partial executions contains those partial executions ending with an unacceptable operation being attempted. Information ow does not dene sets that are properties (as argued above), so it does not dene sets that are safety properties. Not being safety properties, there are no EM enforcement mechanisms for exactly this policy.4 Availability, if taken to mean that no principal is forever denied use of some given resource, is not a safety propertyany partial execution can be extended in a way that allows a principal to access the resource, so the dening set of proscribed partial executions that every safety property must have is absent. In [9], availability is dened to rule out all denials in excess of MWT seconds (for some predened Maximum Waiting Time parameter MWT ). This is a safety property; the dening set of partial executions contains prexes ending in intervals that exceed MWT seconds during which a principal is denied use of a resource.
3
Security Automata
Enforcement mechanisms in EM work by terminating target execution that is described by a nite prex such that P( ) holds, for a predicate P dened by the policy being enforced. In addition, we established in 2 that the set of executions satisfying P must be a safety property. Those being the only constraints on P, we conclude that recognizers for sets of executions that are safety properties can serve as the basis for enforcement mechanisms in EM. A class of Bchi automata [6] that accept safety properties was introu duced (although not named) in [2]. We shall here refer to these recognizers as security automata; they are similar to ordinary non-deterministic nitestate automata [14]. Formally, a security automaton is dened by:
Mechanisms from EM purporting to prevent information ow do so by enforcing a security policy that implies, but is not equivalent to, the absence of information ow. And, there do exist security policies that both imply restrictions on information ow and dene sets that are safety properties.
4
6
not FileRead
not Send
qnfr
FileRead
qfr
Figure 1: No Send after F ileRead
a countable set Q of automaton states, a countable set Q0 Q of initial automaton states, a countable set I of input symbols, and a transition function 5 , : (Q I) 2Q . Set I of input symbols is dictated by the security policy being enforced and the manner in which target executions are being represented; the symbols in I might correspond to system states, atomic actions, higher-level actions of the system, or state/action pairs. To process a sequence s1 s2 . . . of input symbols, the current state Q of the security automaton starts equal to Q0 and the sequence is read one input symbol at a time. As each input symbol si is read, the security automaton changes Q to: (q, si ).
qQ
If Q is ever the empty set, the input is rejected; otherwise the input is accepted. Notice that this acceptance criterion means that a security automaton can accept sequences that have innite length as well as those having nite length. Figure 1 depicts a security automaton for a security policy that prohibits execution of Send operations after a F ileRead has been executed. In this diagram, the automaton states are represented by the two nodes labeled qnfr (for no le read ) and qfr (for le read). Initial states of the automaton are represented in the diagram by nodes with unlabeled incoming edges, so automaton state qnfr is the only initial automaton state. Transition function is specied in terms of edges labeled by transition predicates, which are
5
Notation 2Q denotes the power set for set Q.
7
state vars :
state : {0, 1} initial 0 F ileRead state = 0 state := 1 not Send state = 1 skip
transitions : not F ileRead state = 0 skip
Figure 2: Alternative specication for policy: No Send after F ileRead
Boolean-valued eectively computable total functions with domain I. Let pij denote the predicate that labels the edge from node qi to node qj . Then, the security automaton, upon reading an input symbol s, Q is set to {qj | qi Q s |= pij }. In Figure 1, transition predicate not FileRead is assumed to be satised by input symbols (system execution steps) that are not le read operations, and transition predicate not Send is assumed to be satised by input symbols that are not message-send operations. Since no transition is dened from qfr for input symbols corresponding to message-send execution steps, the security automaton in Figure 1 rejects inputs in which a Send follows a F ileRead. Diagrams like Figure 1 are impractical to draw and hard to understand if set Q of automaton states is large or transition function is complex. We can avoid these diculties by encoding Q for an automaton in multiple variables and by using guarded commands [4] to describe the transition function for the security automaton. Guarded command B S (5)
species that the state transition dened by program fragment S occurs whenever predicate B is satised by the current input symbol and the current state of the automaton. In (5), B is called the guard, and it is a predicate that can refer only to the current input symbol and to the variables encoding the current state of the automaton; S is called the command, and it is a computation that updates (only) the variables encoding the current state of the automaton. To illustrate this alternative notation for security automata, Figure 2 gives a specication for the same security policy as given in Figure 1. The 8
state vars :
A : array[PRINS , OBJS ] of set of RIGHTS
transitions : Access(p, obj, oper) oper A[p, obj] skip AddRight(p, addP, addR, obj) cntrl A[p, obj] A[addP, obj] := A[addP, obj] {addR} RmvRight(p, rmvP, rmvR, obj) cntrl A[p, obj] A[rmvP, obj] := A[rmvP, obj] {rmvR} Figure 3: Access Control
state vars section of this specication introduces the variables that encode the current state of the security automaton. The transitions section gives a list of guarded commands that dene the transition function. In Figure 2, statea two-valued variable with initial value 0encodes the current state of the security automaton, and each of the three guarded commands corresponds to a single edge in the diagram of Figure 1. As a second example, Figure 3 species a security automaton for a simple form of access control [19]. Here, an access control matrix A encodes the current state of the security automatonA[p, o] is the set of rights that principal p has to object o. A is dened in terms of a universe of principals PRINS , a universe of objects OBJS , and a universe of access rights RIGHTS . For simplicity, no initialization is given for A. The transitions in the security automaton of Figure 3 are dened using predicates on input symbols that correspond to a next step of execution: Access(p, obj , oper ) : Principal p invoked an access operation oper naming object obj. AddRight(p, addP , addR, obj ) : Principal p invoked an operation to add right addR for principal addP to object obj. RmvRight(p, rmvP , rmvR, obj ) : Principal p invoked an operation to remove right rmvR for principal rmvP for object obj. The rst guarded command asserts that access operations are permitted provided a principal attempting the operation has the appropriate access right for the named object. The second and third guarded commands describe a simplied policy for granting and revoking rights to principals. In 9
state vars :
state : {0, 1} initial 0
transitions : not P ay(C) state = 0 skip P ay(C) state = 0 state := 1 Serve(C) state = 1 state := 0 Figure 4: Security automaton for fair transaction
particular, the second (third) guarded command asserts that only principals having the cntrl right for an object obj can grant (remove) rights to other principals for accessing obj. More-realistic policies for changing the access control matrix are easily accommodated. Two things are worth noting about this access-control example. First, leverage results from employing a suitable representation (an access control matrix) for the current state of the automaton. Imagine how awkward it would be to try and describe changes to principals access rights in terms of the at set of uninterpreted automaton states. Second, the security automaton does not distinguish security-conguration changes (i.e., changing A when access rights are added and deleted) from ordinary accesses. We would argue that there is no value in making a distinction between these dierent kinds of operations. This view is not universally held [10]. As a nal illustration, we turn to electronic commerce. We might, for example, desire that a service-provider be prevented from engaging in actions other than delivering service for which a customer has paid. This requirement is a security policy; it can be formalized in terms of the following predicates on input symbols, if input symbols represent operation executions: pay(C): customer C requests and pays for service serve(C): customer C is rendered service The security policy of interest proscribes executions in which the serviceprovider executes an operation that does not satisfy serve(C) after having engaged in an operation that satises pay(C). A security automaton for this policy is dened in Figure 4. Notice, the security automaton of Figure 4 does not stipulate that payment guarantees serviceit only limits what the service-provider can do 10
once a customer has made payment. In particular, the security policy that is specied allows a service-provider to stop executing (i.e., stop producing input symbols) rather than rendering a paid-for service. We cannot specify the stronger security policy (that service be guaranteed after payment) because that is not a safety propertythere is no dening set of proscribed partial executions.
4
Using Security Automata for Enforcement
Any security automaton can serve as the basis for an enforcement mechanism in EM. The target is executed in tandem with a simulation of the security automaton.6 In particular, initialization or creation of the target causes an instance of the security automaton simulation to be created, with the security automaton in its initial state. And, each step the target is about to take generates an input symbol, which is sent to that simulation: (i) If the automaton can make a transition on that input symbol, then the target is allowed to perform that step and the automaton state is changed according to its transition function. (ii) If the automaton cannot make a transition on that input symbol, then the target is terminated (for having attempted to violate the security policy). Implicit in this approach are some assumptions. Bounded Memory. The memory that can be devoted to simulating a security automaton will, of necessity, be nitereal computers have nite memories. Recall from 3 that our security automata can have an innite (countable) number of automaton states. Innite sets of automaton states are necessary for recognizing certain safety properties, because whether a given prex should be rejected might depend on all of the input symbols in that prex. The ever-larger prexes produced as execution proceeds thus require ever-larger sets of states to encode needed information about the past. For example, a safety property stipulating that, at each step of execution, the value of some target variable x equals the sum of its values in preceding states requires (to store the sum of the past values of x) a state variable that grows without bound.
A similar approachdeveloped independentlyfor integrating software components whose behaviors need to be reconciled is outlined in [21].
6
11
Security policies of concern in real systems do not seem to require large amounts of storage and, in fact, are today enforced using mechanisms that use only modest amounts of storage; a security automaton to specify such a policy would also require only a modest-sized set of automaton states. We see no reason to expect application-specic or special-purpose security policies to be dierent. So, restricting the state vars for a security automaton to a nite amount of storage is not, in practice, a limitation. Target Control. Implicit in (ii) is the assumption that the target can be terminated the by enforcement mechanism. Specically, we assume that the enforcement mechanism has sucient control over the target to stop further automaton input symbols from being produced. This control requirement is subtle and makes certain security policieseven though they characterize sets that are safety propertiesunenforceable using mechanisms from EM. For example, recall from 2 the denition of availability in [9]: Real-Time Availability: One principal cannot be denied use of a resource for more than MWT seconds. Sets satisfying Real-Time Availability are safety propertiesthe bad thing is an interval of execution spanning more than MWT seconds during which some principal is denied the resource. The input symbols of a security automaton for Real-Time Availability will therefore encode time, and a new input symbol is produced whenever time increases. While individual clocks might be stopped, the passage of time cannot be stopped. So the target cannot be stopped from producing input symbols. Real-Time Availability simply cannot be enforced by running an automaton simulation in tandem with a target, because targets cannot provide the necessary controls to the enforcement mechanism. And since the other mechanisms in EM are no more powerful, we conclude that Real-Time Availability cannot be enforced using any mechanism in EM. Change the specication from MWT seconds to MWT execution steps and the target can be prevented from violating the policy by stopping execution, resulting in an EM-enforceable security policy. Enforcement Mechanism Integrity. A target that corrupts a security automaton simulation can subvert any enforcement mechanism based on that simulation: Input to the enforcement mechanism must correspond to target execution; state transitions must follow the automatons transition function. Ensuring that input to the enforcement mechanism is both correct and complete is a question of target instrumentation and monitoring. 12
The complete mediation requirement associated with reference monitors is one way to discharge this assumption. Ensuring that the target does not interfere with automaton transitions is a matter of isolationthe enforcement mechanism must be isolated from the target. Isolation of our enforcement mechanism is accomplished if, for example, the state vars and transitions for the security automaton are not writable by the target.
Pragmatics
Two mechanisms are involved in the above security-automaton based implementation of an enforcement mechanism. Automaton Input Read: A mechanism to determine that an input symbol has been produced by the target and then to forward that symbol to the security automaton simulation. Automaton Transition: A mechanism to determine whether the security automaton can make a transition on a given input and then to perform that transition. How these are implemented determines the cost of the enforcement mechanism. For example, when the automatons input symbols are the set of target states and its transition predicates are arbitrary state predicates, a new input symbol is produced each time any component of the targets state changes. Since the program counter is a state component and it changes each time a machine-language instruction is executed or an interrupt occurs, the enforcement mechanism must be involved in executing each target instruction, and that could be quite costly. For security policies where the targets production of automaton input symbols coincides with occurrences of hardware traps, an automata-based enforcement mechanism can be supported quite cheaply by incorporating it into the trap-handler. One example is implementing an enforcement mechanism for access control policies on operating system objects, such as les. Here, the target is a le and the production of input symbols coincides with invocations of system operations (i.e., le access operations). The production of input symbols now coincides with occurrences of system-call traps. A second example where hardware traps can be exploited arises in implementing memory protection. Memory protection implements access control with read, write, and execute operations and an access control matrix that tells which processes can access each region of memory. The security automaton of Figure 3 species this security policy. Notice that this security automaton would expect an input symbol for each memory reference, 13
though. But most of these input symbols cause no change to the security automatons state. Input symbols that do not cause automaton state transitions need not be forwarded to the automaton, and that justies the following optimization of Automaton Input Read: Automaton Input Read Optimization: Input symbols are not forwarded to the security automaton if the state of the automaton just after the transition would be the same as it was before the transition. Given this optimization, the production of automaton input symbols for memory protection can be made to coincide with occurrences of traps. The targets memory-protection hardwarebase/bounds registers or page and segment tablesis initialized so that a trap occurs when an input symbol should be forwarded to the memory protection automaton. Memory references that do not cause traps never cause a state transition or undened transition by the automaton. Note, however, if this optimization is used, then a target can subvert the enforcement mechanism by corrupting the lter that selects whether to forward an input symbol to the security automaton. Finally, inexpensive implementation of our automata-based enforcement mechanisms is also possible when programs are executed by a softwareimplemented virtual machine. The virtual machine instruction-processing cycle is augmented so that it produces input symbols and makes automaton transitions, according to either an internal or an externally specied security automaton. For example, the Java virtual machine [20] could easily be augmented to implement the Automaton Input Read and Automaton Transition mechanisms for input symbols that correspond to method invocations.
Beyond EM Enforcement Mechanisms
Response to Violations. Termination of a target that is about to violate a security policy might seem draconian. Yet, by denition, this is how an EM mechanism responds to an attempted violation. Why not simply notify the target that an erroneous execution step has been attempted? The target could then substitute another step and its execution might then continue. In terms of our security automata framework, notifying a target is equivalent to having the security automaton extend that targets execution (rather than truncating that execution). And somebut not allsecurity policies do allow input prexes to be extended in this manner. A security policy that does not enjoy this attribute is the variant of Real-Time Availability given in 2 where MWT bounds the number of execution steps (not seconds) that elapse before an action is taken. Various other safety properties also do not 14
allow execution prexes to be extended, although their practical signicance as security policies is an open question. EM was dened to truncate execution for generality. Expanding EM to include enforcement mechanisms that handle violations by notifying the target or by truncating its execution would not change the set of security policies that are EM enforceable. Modifying EM to require enforcement mechanisms that handle violations by necessarily notifying the target would shrink the set of security policies that are EM enforceable, and with no apparent gain. Program Modication. The overhead of enforcement can be reduced by merging the enforcement mechanism into the target. One such scheme is software-based fault isolation (SFI), also known as sandboxing [33, 30]. SFI implements memory protection, as specied by an automaton like that of Figure 3, but does so without hardware assistance.7 Instead, a program is edited before it is executed, and only such edited programs are executed by the target. (Usually, it is the object code that is edited.) The edits insert instructions to check and/or modify the values of operands, so that illegal memory references are never attempted. SFI is not in EM because SFI involves modifying the target, and such modications are not permitted of enforcement mechanisms in EM. But viewed in our framework, the inserted instructions for SFI can be seen to implement Automaton Input Read by copying code for Automaton Transition in-line before each target instruction that produces an input symbol. Generalizing, nothing prevents the SFI approach from being used with arbitrary security automata, thereby enforcing any EM-enforceable security policy. Trust must be placed in the tools used to modify the target, however. Our SASI (Security Automata SFI Implementation) prototypes for Intels x86 object code and SUNs JVM (Java Virtual Machine) explored the use of an SFI-like approach for EM-enforceable policies [7]. Each of our prototypes merges the simulation of a security automaton into the object code for the program that is the target. New variablesaccessible only to the code added for SASIrepresent the current state of a security automaton, and new codethat cannot be circumventedsimulates automaton state transitions. The new code also causes the target system to halt whenever
7 Specically, the security policy enforced by SFI would involve only the rst guarded command of the three in Figure 3, and transition predicate Access(p, obj, oper) would check that the memory address being read, written, or branched to is a legal one for the program.
15
the automaton rejects its input (because the current automaton state does not allow a transition for the next target instruction). Analysis of a target allows simplication of code for simulating a security automaton. Each inserted copy of the automaton simulation is a candidate for simplication based on the context in which that code appears. By using partial evaluation [16] on the guards as well as by using the automaton structure, irrelevant tests and updates to the security automaton state can be removed. Program Analysis. There is no need for any run-time enforcement mechanism if the target can be analyzed and proved not to violate the security policy of interest. This approach has been employed for a security policy like what SFI was originally intended to address in proof carrying code (PCC) [24]. With PCC, a proof is supplied along with a program, and this proof comes in a form that can be checked mechanically before running that program. The security policy will not be violated if, before the program is executed, the accompanying proof is checked and found to be correct. The original formulation of PCC required that proofs be constructed by hand. This restriction can be relaxed. For certain security policies, a compiler can automatically produce PCC from programs written in high-level, type-safe programming languages[23, 26]. To extend PCC for security policies that are specied by arbitrary security automata, a method is needed to extract proof obligations for establishing that a program satises the property given by such an automaton. Such a method does existit is described in [3].
5
Discussion
The utility of a formalism partly depends on the ease with which objects of the formalism can be read and written. Users of the formalism must be able to translate informal requirements into objects of the formalism. With security automata, establishing the correspondence between transition predicates and informal requirements on system behavior is crucial and can require a detailed understanding of the target. The automaton of Figure 1, for example, only captures the informal requirement that messages are not sent after a le is read if it is impossible to send a message unless transition predicate Send is true and it is impossible to read a le unless transition predicate F ileRead is true. There might be many ways to send messages some obvious and others buried deep within the bowels of the target. All must be identied and included in the denition of Send; a similar obligation 16
accompanies transition predicate F ileRead. The general problem of establishing the correspondence between informal requirements and some purported formalization of those requirements is not new to software engineers. The usual solution is to analyze the formalization, being alert to inconsistencies between the results of the analysis and the informal requirements. We might use a formal logic to derive consequences from the formalization; we might use partial evaluation to analyze what the formalization implies about one or another scenario, a form of testing; or, we might (manually or automatically) transform the formalization into a prototype and observe its behavior in various scenarios. Success with proving, testing, or prototyping as a way to gain condence in a formalization depends upon two things. The rst is to decide what aspects of a formalization to check, and this is largely independent of the formalism. But the second, having the means to do those checks, not only depends on the formalism but largely determines the usability of that formalism. To do proving, we require a logic whose language includes the formalism; to do testing, we require a means of evaluating a formalization in one or another scenario; and to do prototyping, we must have some way to transform a formalization into a computational form. As it happens, a rich set of analytical tools does exist for security automata, because security automata are a class of Bchi automata [6] which u are widely used in computer-aided program verication tools. Existing formal methods based either on model checking or on theorem proving can be employed to analyze a security policy that has been specied as a security automaton. And, testing or prototyping a security policy that is specied by a security automaton is just a matter of running the automaton.
Guidelines for Structuring Security Automata
Real system security policies are best given as collections of simpler policies, a single large monolithic policy being dicult to comprehend. The systems security policy is then the result of composing the simpler policies in the collection by taking their conjunction. To employ such a separation of concerns when security policies are specied by security automata, we must be able to compose security automata in an analogous fashion. Given a collection of security automata, we must be able to construct a single conjunction security automaton for the conjunction of the security policies specied by the automata in the collection. That construction is not dicult: An execution is rejected by the conjunction security automaton if and only if it is rejected by any automaton in the collection. 17
Beyond comprehensibility, there are other advantages to specifying system security policies as collections of security automata. First, having a collection allows dierent enforcement mechanisms to be used for the dierent automata (hence the dierent security policies) in the collection. Second, security policies specied by distinct automata can be enforced by distinct system components, something that is attractive when all of a given security automatons input symbols correspond to events at a single system component. Benets that accrue from having the source of all of an automatons input symbols be a si...