John McLean for his helpful comments. References. 1. M. Abadi, L. Lamport: Composing speci cations. In J. W. de Bakker, W. P. de. Roever, G. Rosenberg (eds.): ...
Application-Oriented Security Policies and their Composition Virgil D. Gligor1 and Serban I. Gavrila2 1
Dept. of Electrical Engineering, University of Maryland, College Park, MD 20782 2 VDG Inc., 6009 Brookside Drive, Chevy Chase, MD 20815
Abstract. We de ne the notion of the application-oriented security pol-
icy and suggest that it di ers from that of a system-level, global security policy. We view a policy as a conjunction of security properties and argue that these properties are not always independent and, hence, cannot be analyzed (e.g., composed) individually. We also argue that some necessary policy properties fall outside of the Alpern-Schneider safety/liveness domain and, hence, are not subject to the Abadi-Lamport composition principle. We suggest several areas of research in policy de nition, composition, and administration.
1 Application-Oriented Security Policies We distinguish an application-oriented (a-o) security policy from a system-level, global security policy by three characteristics, namely, (1) locality of enforcement, (2) mandated composability with other a-o policies, and (3) mandated compatibility with the application itself. Locality of Enforcement. Enforcement of a policy can be local or global. Enforcement of a policy in an application is local if the policy can be completely and correctly enforced within the application. Enforcement of a policy is global if the policy must be uniformly enforced for all applications under its control. Although in systems supporting multiple applications, an a-o policy must also be composable with an underlying (more) global policy in the sense that the latter must enable the local enforcement of the former, the a-o policy need not also be enforced within the global policy. For instance, a database security policy must use its underlying operating system's policy to protect its objects from unauthorized access by other applications, but the operating system policy does not have the obligation to also enforce the database policy. In contrast to the local enforcement of an a-o policy, a global policy must be enforced uniformly for all applications under its control or, else, it may be ine ective for any applications. Mandated Composability. Mandated Composability means that an a-o policy must be composable with any and all other a-o policies with which it coexists within a system. This is both a separate concern and obligation. It is a separate concern because global policy support of individual a-o policy enforcement (i.e., \hierarchical" [8, 10] a-o policy composability with the underlying global policy) cannot always guarantee composability among a-o policies, since the global
policy is oblivious to interactions among applications. It is a separate obligation because interactions among a-o policies may produce distinct, emerging a-o policies. As a consequence, (\lateral" or \external" [6, 7]) composability must be part of a-o policy de nition and administration. Mandated Compatibility. Mandated compatibility of an a-o policy with the application itself means that the a-o policy may not unjusti ably deny the execution of an application for which the policy was developed. For example, the access-management policy may grant users too few, or inconsistent, permissions for an application. Speci cally, access management may grant a user the permission to invoke an application operation and insucient permissions for operation execution, or vice-versa, thereby unjusti ably denying application execution. Should this happen, either the application or the policy de nition, or both, must be changed to achieve compatibility (viz., Figure 1). Otherwise, it would be both senseless and ironic to create a specially tailored policy for an application only to discover that the application could never work under the constraints of its policy.
Fig. 1. Mandated Compatibility
2 Structure of Application-Oriented Policies We view security policies as conjunctions of security properties. However, these properties are not independent [3, 4, 11]. To illustrate the notion of dependency among policy properties, consider the following three types of properties: accessattribute (AT), access-authorization (AA), and access-management (AM) properties. Access attributes include subject and object attributes (e.g., user, group, role, location identi ers, secrecy and integrity levels, time-of-access intervals), and AT properties typically establish invariant relationships among these attributes (e.g., lattices of secrecy and integrity levels, user-group membership invariants, inheritance of role permissions). AA properties determine whether a subject's current access attributes satisfy the conditions for accessing an object
given the current object attributes. In contrast, AM properties include conditions under which subjects are granted or revoked attributes for accessing objects, subjects and objects are created or destroyed, objects are encapsulated within protected subsystems. In general, AM properties bring the system to desired states, whereas AA properties ensure that the system remains in desired states. A typical dependency arises between AA and AM properties because the values of the attributes used by the former for access decisions are determined by the latter (i.e., AA properties have a \uses" dependency [4, 11] on AM properties). Hence, whether an AA property holds in a state depends not only on the property (predicate) itself, but also on the de ned AM properties. Both AA and AM properties have \uses" dependencies on AT properties. Furthermore, AM properties also have \uses" dependencies on AA properties whenever object attributes themselves are treated as objects and, hence, become the target of access authorization. Techniques to rede ne policy properties to avoid this cyclic dependency, and other undesirable ones, are presented elsewhere [4]. Groups of policy properties may also depend upon individual properties used in the same conjunction. For example, the property P = AT AA AM depends on an AM property, denoted by Admin(P ), which requires that administrative commands have the ability to bring the system from an arbitrary state (or, alternatively, from any state) to a state that satis es P . Unless Admin(P ) is satis ed, the policy de ned by property P is empty because the system operating under P can neither start from, or recover to, a secure state [9], nor reach a secure state from another secure state under administrative control. For application-oriented policies, the composition of independent security properties does not necessarily de ne a usable policy. To be useful, property P = AT AA AM must be compatible with the application for which it was designed. ^
^
^
^
3 Composition of Application-Oriented Policies We de ne a system by a state machine model. We denote the set of states by
STATES , the set of subjects by SUBJECTS , the set of users by USERS , the set of operations by OPERATIONS , and the set of objects by OBJECTS . Each state transition is de ned by a command of the form op(s1 ; S; obj; s2 ), where the subject S performs the operation op on one or more objects obj , thereby changing the current state s1 to s2 . A command sequence is op1 (s0 ; S1 ; obj; s1 ) op2 (s1 ; S2 ; obj2 ; s2 ) : : :, where \ " is the concatenation operator, and s0 is the start state. We denote the set of start states by STATES0. A nite command sequence may be extended to
an in nite one by adding \no-op" commands, that do nothing and preserve the current state. The extended command sequence is denoted by ^ . We denote the set of all command sequences with the start state in STATES0 by 0 . A tranquil command is a command that does not alter the security attributes of the subjects and objects (e.g., creation, deletion, or update of permis-
sions, users, roles). A tranquil command sequence is a command sequence consisting only of tranquil commands. We denote the set of tranquil command sequences with the start states in STATES0 by 0 . Whenever STATES0 = STATES , we drop the subscript 0 . A system is a set of command sequences with start states in STATES0. A secure state is a state that satis es some \state properties". A secure command is a command that satis es some \transition properties". A reachable state is a state appearing in a command sequence of 0 . An application is a tuple App = [ObjSet; OpSet; Plan], where ObjSet OBJECTS and OpSet OPERATIONS . Plan is the execution plan of the application and consists of a nite set of pairs (obj ; op ) i 1; ; n , where n is a natural number, obj is one or more objects of ObjSet, and op is in OpSet. Other types of execution plans may include order or exclude redundant operations and privileges to objects to help satisfy the \least privilege" principle. For simplicity, we omit these types of plans. Given two applications App = [ObjSet ; OpSet ; Plan ], i = 1; 2, we denote the new application [ObjSet1 ObjSet2 ; OpSet1 OpSet2 ; Plan1 Plan2] by App1 App2 . A command sequence 0 executes the application App (or App is executed by , or is an execution of App), if for any pair (obj; op) in App's execution plan there is a command op(s ; S; obj; s +1 ) in . We also use App to denote the set of all executions of App. For an a-o security policy
f
i
i j
2 f
gg
i
i
i
i
[
i
i
[
[
t
2
k
P
k
= P Admin(P ) Compat(P; App); ^
^
where P = AT AA AM , we de ne Admin(P ) and Compat(P; App) as follows. ^
^
De nition 1. Admin(P ) is satis ed if and only if s STATES; s0 STATES0; ! : ! starts in s ! reaches s0 s^0 P ; i.e., starting in an 8
9
2
^
^
2
9
2
2
arbitrary state, the administrative commands have the ability to bring the system to a state that satis es property P . (Alternatively, we can de ne Admin(P ) as follows: 8s 2 STATES; 8s0 2 STATES0 : s0 2 P; 9! 2 : ! starts in s ^ ! reaches s0 ).
Note that the predicate \! reaches s0 " of Admin(P ) is not trivially satis ed; e.g., the system may not provide all the administrative commands to ensure that certain states of STATES0 can be reached.
De nition 2. Compatibility of P with App is any one of the following six al-
ternatives: 1. P is compatible with App if there is a s0 2 STATES0 and a 2 P starting in s0 that executes App. We denote this property by Compat(P; App). 2. P is strongly compatible with App if for each s0 2 STATES0 with s^0 2 P there is a 2 P starting in s0 that executes App. We denote this property by CompatS (P; App). 3. P is totally compatible with App if for each s0 2 STATES0 there is a 2 P
starting in s0 that executes App. We denote this property by CompatT (P; App). 4. P is multi-path compatible with App if there is a s0 2 STATES0 such that for every nite command sequence 2 P starting in s0 there is a 2 Sigma such that 2 P ^ executes App. We denote this property by CompatM (P; App). 5. P is machine-closed compatible with App if for every nite command sequence 2 P there is a 2 such that 2 P and executes App. We denote this property by CompatMC (P; App). 6. P is totally multi-path compatible with App if for each s0 2 STATES0 there is a 2 P starting in s0 , and for every nite command sequence 2 P there is a 2 such that 2 P and executes App. We denote this property by CompatTM (P; App).
By de nition,
CompatTM (P; App) = CompatMC (P; App) = CompatM (P; App); CompatT (P; App) = CompatS (P; App) = Compat(P; App); CompatTM (P; App) = CompatT (P; App); CompatMC (P; App) = CompatS(P; App); CompatM (P; App) = Compat(P; App): )
)
)
)
)
)
)
Compatibility is a non-trivial property. The following example shows that even the weakest form of compatibility, Compat(P; App), may not always hold. Example 1. Let App = [fobj g; fop1; op2 g; plan] with plan = f(obj; op1 ); (obj; op2 )g. Let P be the following property: \u is the only user who may execute App, and a user may not perform all operations of App on the same object" (viz., operational separation of duty policies in [5]). Clearly, P is incompatible with App because App is not executable in P .
Note that CompatTM (P; App) and CompatMC (P; App) imply that the pair of properties (P; App) is machine-closed in the sense of Abadi and Lamport [1] and, hence, are properties in the sense of Alpern and Schneider [2]. However, properties CompatTM (P; App), CompatMC (P; App), and CompatM (P; App) are unrealistic. The following example shows that policy properties exist that are compatible but not multi-path compatible (and therefore neither machine-closed, nor totally multi-path compatible) with the application for which they are de ned. Example 2. Let App = [fobj g; fop1; op2 g; plan] with plan = f(obj; op1 ); (obj; op2 )g, and P be the following safety property: \u1 and u2 are the only users who may execute App, and a user may not execute two distinct operations of App on the same object of App" (viz., objectand history-based separation of duty policies [5]). (1) P is compatible with App.
Let s0 be a start state such that user u1 has permission op1 on obj and user u2 has permissions op1 ; op2 on obj . App is executed by the command sequence op1 (s0 ; S1 ; obj; s1 ) op2 (s1 ; S2 ; obj; s2 ) P , where S1 and S2 are subjects executing on behalf of u1 and u2 , respectively. However, (2) P is not totally multi-path compatible with App. If s = op1 (s0 ; S2 ; obj; s1 ), where S2 is a subject executing on behalf of u2 , clearly, is in P and cannot be extended to a command sequence in P that executes App (u1 does not have the permission op2 , and u2 cannot execute op1 on obj without violating P ).
0
2
0
0
Properties CompatTM (P; App) and CompatT (P; App) are also unrealistic because they require that for every starting state s0 STATES0 there is a ( nite) command sequence in both P and App, for all P and App. Also, we consider CompatS (P; App) impractical because it may require that administrative commands be executed to allow application execution under a policy P . Hence, Compat(P; App) appears to be the only practical choice of compatibility property. We note that Compat(P; App) (and also CompatM (P; App), CompatT (P; App), CompatS (P; App)) and both forms of Admin(P ) fall outside of the Alpern-Schneider framework. Since = P Admin(P ) Compat(P; App), all security policies { not just information- ow properties [7, 12] { fall outside of the Alpern-Schneider framework, and thus are not subject to the Abadi-Lamport composition principle [1]. Let ( ) be the set of command sequences that satisfy P , if AdminP Compat(P; App) is true; and , otherwise. 2
P
^
^
P
CS P
^
;
De nition 3. Let App1 and App2 be two applications of a secure system,
and let P1 = P1 ^ Admin(P1 ) ^ Compat(P1 ; App1 ), P2 = P2 ^ Admin(P2 ) ^ Compat(P2 ; App2 ), where P1 ; P2 0 are policy properties for applications App1 ; App2 . Let P1 P2 be the policy (P1 ^ P2 ) ^ Admin(P1 ^ P2 ) ^ Compat(P1 ^ P 2; App1 t App2 ). We say that P1 is composable with P2 if and only if C S (P1 P2 ) 6= ; whenever C S (P1 ) 6= ; ^ C S (P2 ) 6= ;. If P1 is composable with P2 , then P1 P2 is called the composition of P1 with P2 or the emerging policy, and the set of command sequences C S (P1 P2 ) is C S (P1 ) \ C S (P2 ).
Even under this very simple composition criterion, realistic policies exist that are non-composable [5].
4 Future Research In this paper we suggest that application-oriented security policies di er from system-level, global security policies in terms of enforcement, composability, and compatibility obligations. We argue that policy properties such as Admin(P ) and Compat(P; App) must be included in any a-o policy de nition.
Three areas of future research become apparent. First, new composition criteria need to be investigated that are useful in a variety of application architectures (e.g., some of the criteria addressed by McLean [7]). For example, criteria are needed to de ne the composition of policies for applications that are privileged (in some limited ways) with respect to an underlying global policy; e.g., application servers that are allowed to violate an operating system or network policy to some limited extent to implement an overall application policy. Furthermore, it is also possible that di erent composition criteria may be used for di erent a-o policies within the same system. The properties of policy composition under multiple, coexisting criteria deserve further study. Second, analysis of policy properties that fall outside the safety-liveness domain becomes necessary beyond that of information- ow properties. For example, it is possible that some properties that fall outside the safety-liveness domain can be \approximated" with properties of this domain, thereby allowing available analysis techniques [1] to be used. Should this be the case, however, the problem of approximation suitability arises naturally. (Preliminary evidence indicates that approximations of information- ow properties with \safety" properties of mandatory access control and covert-channel handling do not compose even under simple property conjunction [11]; i.e., the composition of the approximations does not approximate the information- ow property.) Third, a-o policies pose added challenges of separate policy de nition, selection, and administration; e.g., exible a-o policy selection and administration impose recurrent costs that must be kept under control. These challenges can be mitigated by the development of practical methods and tools for policy de nition, administration, and composition.
Acknowledgements This work was funded in part by the US Department of Commerce, National Oceanographic and Atmospheric Administration, under the SBIR Contract No. 50-DKNB-7-90120. The views expressed herein are those of the authors and do not necessarily re ect the views of the US Department of Commerce or any of its sub-agencies. The rst author would like to thank C. Sekar Chandersekaran of IBM Corporation for his interest in, and support of, this work. We also thank John McLean for his helpful comments.
References 1. M. Abadi, L. Lamport: Composing speci cations. In J. W. de Bakker, W. P. de Roever, G. Rosenberg (eds.): Stepwise Re nement of Distributed Systems. Lecture Notes in Computer Science, Vol. 430, Springer-Verlag, Berlin Heidelberg New York, 1990. 2. B. Alpern, F. Schneider: De ning Liveness. Information Processing Letters, vol. 21, no. 4, October 1985, pp. 181{185. 3. Common Criteria for Information Technology Security Evaluation, Version 2.0 Draft, GISA, NNCSA, CESG, NIST, NSA, December 1997.
4. Federal Criteria for Information Technology Security, Vol. 1, Chapter 3 and Appendix C. Version 1.0, NIST, NSA, December 1992. 5. V. D. Gligor, S. I. Gavrila, and D. Ferraiolo: On the Formal De nition of Separation-of-Duty Policies and their Composition. Proc. of the 1998 IEEE Symp. on Security and Privacy, Oakland, California, May 1998 (to appear). 6. H. M. Hinton and E. S. Lee: The Composability of Policies. Proc. of 2nd ACM Conference on Computer and Communications Security, Fairfax, Virginia, November 1994, pp. 258{281. 7. J. McLean: A general theory of composition for a class of \possibilistic" properties. IEEE Transactions on Software Engineering, vol. 22, no. 1, January 1996, pp. 53{ 66. 8. Trusted Database Interpretation of the TCSEC, NCSC-TG-21, Version 1, National Computer Security Center, April 1991. 9. Trusted Recovery Guideline, NCSC-TG-022, Version 1, National Computer Security Center, December 1989. 10. W. R. Shockley and R. R. Schell: TCB Subsets for Incremental Evaluation. Proc. of the Third Aerospace Computer Security Conference Orlando, Florida, December 1987, pp. 131{139. 11. Uni ed INFOSEC Criteria, INFOSEC Concepts, Section 3, Dependencies among TCSEC Requirements (unclassi ed), National Security Agency, 1993. 12. A. Zakinthinos and E. S. Lee: A General Theory of Security Properties. Proc. of 1997 IEEE Symposium on Security and Privacy, Oakland, California, May 1997, pp. 94{102.
