A Propositional Policy Algebra for Access Control - CiteSeerX

A Propositional Policy Algebra for Access Control DUMINDA WIJESEKERA and SUSHIL JAJODIA George Mason University

Security-sensitive environments protect their information resources against unauthorized use by enforcing access control mechanisms driven by access control policies. Due to the need to compare, contrast, and compose such protected information resources, access control policies regulating their manipulation need to be compared, contrasted, and composed. An algebra for manipulating such access control policies at a higher (propositional) level, where the operations of the algebra are abstracted from their specification details, is the subject of this paper. This algebra is applicable to policies that have controlled nondeterminism and all or nothing assignments of access privileges in their specification. These requirements reflect current practices in discretionary and role-based access control models. Therefore, the proposed algebra can be used to reason about role-based access control policies combined with other forms of discretionary policies. We show how to use algebraic identities to reason about consistency, completeness, and determinacy of composed policies using similar properties of their constituents. Categories and Subject Descriptors: H.2.7 [Database Management]: Database Administration— Security, integrity, and protection; K.6.5 [Management of Computing and Information Systems]: Security and Protection General Terms: Security Additional Key Words and Phrases: Access control, security policy, policy composition, policy algebra

1. INTRODUCTION Many information systems are both service providers and service users of other information systems, resulting in a high degree of interoperability and information sharing. Designers of such systems have to be concerned about two things: the need to protect the privacy of one’s own resources from unauthorized disclosures and the means to respect the privacy of others’ information. There are both military and commercial systems in this situation, where the desire to enjoy the benefits of shared success is high. Examples from the military arena include coalitions that are formed and disbanded to carry out joint missions, This work was partially supported by the National Science Foundation under grant CCR-0113515. A preliminary version of this paper appeared under the title “Policy algebras for Access control—The Propositional Case” in the Proceedings of the 9th ACM Conference on Computer and Communications Security, November 2002, pp. 38–47. Authors’ addresses: D. Wijesekera and S. Jajodia, Center for Secure Information System, George Mason University, Fairfax, VA 22030–4444; email: {dwijesek,jajodia}@gmu.edu Permission to make digital/hard copy of all or part of this material without fee for personal or classroom use provided that the copies are not made or distributed for profit or commercial advantage, the ACM copyright/server notice, the title of the publication, and its date of appearance, and notice is given that copying is by permission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requires prior specific permission and/or a fee. ° C 2003 ACM 1094-9224/03/0500-0286 $5.00 ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003, Pages 286–325.

A Propositional Policy Algebra for Access Control

•

287

such as combined US operations in Afghanistan and coordinated exercises. Examples from the commercial arena are joint management and finances of newly merged or cooperating multinational corporations or organizations that work across traditional corporate boundaries of the past. Because information resources of security conscious organizations are governed by policies, when information is shared, it becomes necessary to compare, contrast, and compose the underlying security policies to safeguard the information from external enemies while protecting individual organizational resources from unauthorized access by others. Problems that arise in doing so involve the diversity and incompatibility of requirements, security models and policies, and their enforcement mechanisms. To maintain conceptual coherence of security policies among collaborating organizations and to have a common basis for comparison, we propose an algebra to reflect composition of security policies at a higher level. Towards achieving this goal, this paper presents a policy composition framework at the propositional level for access control policies. Propositional level refers to the fact that we view policies as abstract symbols and their semantics as nondeterministic transformers of permission sets assigned to subjects. We now explain what we mean by nondeterministic transformers of permission sets. A permission is an ordered pair (object, ±action), and a permission set is a set of such permissions. For example, (file1,+read) and (file1,-write) are permissions, and {(file1,+read),(file1,-write)} is a permission set. We say (Alice,PermSet) is an assignment of the permission set PermSet to subject Alice. For example, (Alice, {{(file1,+read),(file1,-write)}}) is an assignment of the permission set {(file1,+read),(file1,-write)} to subject Alice. Similarly, (Alice, {{(file1,+read), (file1, -write)},{(file1,-read),(file1,+write)}}) means that Alice is granted either the permission set {(file1,+read),(file1,-write)} or the permission set {(file1,-read),(file1,+write)} (but not both). We also use the notation (s,PermSet) 7→ (s,PermSet’) for a transformation (function) that transforms a permission set assignment (s,PermSet) to (s,PermSet’). For example, now consider the transformation, say T, given by (Alice,∅) 7→ (Alice, {{(file1,+read),(file1,-write)}, {(file1,-read),(file1,+write)}}). We read T to mean that Alice’s empty permission set (notation: (Alice,∅)) is nondeterministically transformed into Alice being granted either {(file1,+read),(file1,-write)} or {(file1,-read), (file1,+write)}. Note that T is nondeterministic because it allows Alice one of two choices: namely, {(file1,+read),(file1,-write)} or {(file1,-read),(file1,+write)}. All of this notation is formally explained in Sections 2 and 3. Since policies are interpreted as nondeterministic transformers on permission set assignments to subjects, operations on policies are interpreted as relational or set theoretical operators on such nondeterministic transformers. Some example operators on policies that we consider are granting permissions allowed under one of the two policies, adding provisions to an existing policy, and applying one policy after another. In the above-stated example, access control policy p can be considered as the (soon to be explained external) union of the policies p1 and p2 that map (Alice,∅) to (Alice,{{(file1,+read),(file1,-write)}}) and (Alice,{{(file1,-read), (file1,+write)}}), respectively. Access control policy ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

288

•

D. Wijesekera and S. Jajodia

operators (as the one stated above) are abstracted as symbols in our algebra and are interpreted as (set theoretical) union, intersection, and relational composition over nondeterministic transformers of permission set assignments to subjects. The advantages of having a framework to compose access control policies are many. First, a compositional framework provides descriptions of policies that are independent of their models and implementation mechanisms. Considering the semantics of an access control policy as a transformer of permission sets assigned to a subject provides a view that is based only on the pre-post relationship of access permissions given to subjects. Hence, our semantics only care about the input-output behavior of transformers (and therefore policies) and not their internals. In concert, semantically, policy operators are set theoretical transformers on such input-output behaviors. Therefore, policies composed of input-output transformers can be examined for completeness, consistency, and unambiguity of specification. Therein lies one advantage of the proposed abstraction. As a simple example, consider two policies p, q that allow Alice to read file 1 given by (Alice, ∅) 7→ (Alice,{{(file1, +read)}}) and (Alice, ∅) 7→ (Alice,{{(file1,-read)}}), respectively. Now if we compose p and q to have the interpretation of (Alice,∅) 7→ (Alice, {{(file1,+read)}, {(file1,-read)}}), then this policy (explained as p ∪ q in Section 3) is inconsistent. An abstracted view is able to highlight such inconsistencies without getting involved in the details that produce them. Second, a compositional framework allows specifiers of policies to determine if two policies in fact result in the same accesses, that is, to verify if they specify the same input-output behavior. Third, a compositional framework allows the process of policy specification to be decentralized. That is, it facilitates specifying smaller access control policies and then constructing their verified composition. Finally, a compositional framework facilitates reuse of policies that are well specified and known to be error-free. This work is an extension of a propositional algebra for policies reported in Wijesekera and Jajodia [2001], which in turn is an extension of the composition framework for access control policies proposed by Bonatti et al. [2000]. In Bonatti et al. [2000], an access control policy is interpreted as a set of ground (variable-free) terms over an alphabet for subject, object, and action terms, closed under set theoretical operators of union, intersection, differences, scoping restrictions, etc. and recursive closure under Horn Clauses. In addition, Bonatti et al. [2000] have policy variables for yet-to-be specified policies in expressions that are replaced by a collection of subjects, objects, and action constants supplied by an environment (which we do not support). A detailed comparison with this work appears in Section 7. In a related development, ¨ Schneider et al. represent security policies as Buchi automata and develop a monitoring system to monitor their enforcement [Kozen 1999; Schneider 1998]. Although the propositional version of our framework is close to an automata theoretic model, our interests are not in the fairness or safety characteristics of their implementations. Again, details appear in Section 7. The main enhancements in this paper over those reported in Wijesekera and Jajodia [2001] are the addition of external operators (namely, those that model issues related to nondeterminism) and the use of individual and set ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

289

propositions to model conditional authorizations. We now explain the difference between internal and external operators by an example. Consider our policies for Alice to access file 1. As stated, this policy can be written in two components p1 and p2 , where p1 gives read but not write permissions and p2 gives write but not read permissions to Alice. Accordingly, we interpret p1 and p2 as mapping from (Alice,∅) to (Alice,{{(file1,+read),(file1,-write)}}) and (Alice,{{(file1,-read),(file1,+write)}}), respectively. Now consider two ways of constructing a policy that allows permissions granted by either p1 or p2 . The first maps (Alice,∅) to (Alice,{{(file1,+read), (file1,-write), (file1,-read),(file1,+write)}}), and the second maps (Alice,∅) to (Alice,{{(file1,+ read),(file1,-write)}, {(file1,-read),(file1,+write)}}). The difference is that in the first option all permission sets are merged, resulting in creating larger permission sets by taking unions over all combinations. The second case (i.e., external union) merely collects all permission sets that are in either policy. We call the first the internal union and the second the external union. For an example where internal union is useful, consider p1 as the internal union of p1,1 and p1,2 , where p1,1 maps (Alice,∅) to (Alice,{{(file1,+read)}}) and p1,2 maps (Alice,∅) to (Alice,{{(file1,-write)}}). Thus, p1,1 gives Alice the permission to read file1 and p1,2 prohibits Alice from writing file1. Note also that some unions have contradictory permissions and prohibitions (e.g., the internal union of p1 and p2 ) and others (e.g., the internal union of p1,1 and p1,2 ) do not. Conversely, some policies are incomplete (e.g., p1,1 does not specify anything about write permissions) and others are complete (e.g., p1 specifies read and write permissions for file1). We address issues of consistency and completeness in Section 5. Next, we discuss the distinction between (first order) properties of subjects, objects, and actions and those of sets of such entities (second order). Before making this distinction, note that such properties are needed to specify conditions in conditional permission assignments. The basic point is that some permissions can be given based on properties of individuals and others based on properties of sets. An example of a conditional permission based on a permission of an individual is that Alice could be given permission to create a new executable if she is a developer. An example of a conditional permission based on a property of a set is that Alice can be allowed to create a new file provided that the total space taken by all of her files does not exceed 2GB. More examples appear in Sections 2 and 6. Summary of results reported here is as follows. We present a propositional version of a policy composition algebra with a syntax consisting of abstract symbols for atomic policy expressions and composition operators. The operators have been classified as external and internal. This distinction is necessary to better model nondeterminism. Accordingly, most policy operators we use, such as conjunction and disjunction, have an external version and an internal version. For example, internal union of two policies p1 and p2 constructs its permission sets by taking the union over permission sets accepted by p1 and p2 , whereas the external union selects a permission set accepted by p1 or p2 . The operators we use are conjunction, disjunction, sequencing, recursive closure under rules, provisioning, and scoping. The semantics of policies are interpreted as relational transformers of (subject, permission sets) with controlled ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

290

•


nondeterminism, as explained earlier. We provide algebraic identities and show how they can be used to determine equivalent policies (i.e., policies that permit the same set of accesses for the same subject). We then discuss different kinds of determinism, consistency, and completeness that apply to our policy algebra. We also show how our algebraic identities can be used to derive sufficient conditions for consistency, completeness, and determinism. Finally, we compare our work with those of others and provide a summary of extensions that are under way. The rest of the paper is organized as follows. Sections 2 and 3 introduce the syntax and semantics of our algebra, respectively. Section 4 provides properties of our algebra, and Section 5 provides properties of deterministic policies and sufficient conditions for policy expressions to yield consistent, complete, and deterministic policies. Section 6 shows how some example policies can be modeled using our algebra, and Section 7 compares our work with that of others. Section 8 concludes the paper. The Appendix contains proofs of theorems in the paper. 2. SYNTAX This section formally describes the syntax of our policy composition algebra. In our algebra, policies are recursively constructed by applying composition operators to atomic or already-constructed policies. As stated in Section 1, semantically, policies nondeterministically transform assignments of permission sets to subjects. Having a permission set instead of one permission facilitates modeling all or nothing permission assignments. For an example of such a policy, consider a bank clerk who has the authority either to read and write a check or read and approve a check, but not read, write, and approve a check. Hence, the clerk can be assigned the permission sets {(check,read),(check,write)} or {(check,read),(check,approve)}, but not {(check,read),(check,write),(check,approve)}. Suppose we choose the first option. Then our semantics represent this policy (say p1 ) as the transformation T1 : (Clerk1,∅) 7→ (Clerk1,{{(check,+read),(check,+write),(check,-approve)}}). Alternatively, p2 is represented as T2 : (Clerk1,∅) 7→ (Clerk1,{{(check,+read),(check, -write),(check,+approve)}}) in the second option. The reason for having a set in the range of T1 and T2 will be explained shortly. Continuing with the previous example consider the situation with a bank that wants to assign the check-writing task to one clerk, say to clerk-1, and the check approval task to another, say to clerk-2, but the bank does not care who gets which task as long as no one gets both. That leaves the bank with two options: either assign the permission sets {(check,+read),(check,+write),(check, -approve)} to clerk-1 and {(check,+read),(check,-write),(check,+approve)} to clerk-2 or vice versa. This example shows that permission sets can be assigned nondeterministically, but choices must be explicitly stated. This kind of nondeterminism is usually referred to as don’t care nondeterminism in programming languages [Apt 1997]. Representation of such policies as nondeterministic transformers of permission assignments is formally described after we explain some of our policy operators. But as argued, there is a need to have ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

291

a syntactic expression to represent the fact that permission sets given by p1 or those given by p2 (and no other mixture of them) are the only acceptable choices. Our definition of policies allows conditional authorizations. An example of such a policy would be if a clerk is already authorized to read any check with a value greater than $10,000, then he/she can destroy (remove) any check. To add conditions to existing policies, we allow two types of propositions: individual and set propositions. For example, the condition can read any check with a face value greater than $10,000 applies to an object—a check. Therefore, we call them individual propositions. Conversely, consider a new bank policy that states if the total value of all checks to be read by a clerk is more than $10,000, then she can destroy (remove) any of them. In this policy, the condition does not apply to any single check, but to the set of all checks authorized to be read by the clerk. We need set propositions to model such conditions, as they are properties of sets and not of individuals. In either case, we represent both types of propositions (i.e., individual and set) abstractly in our models as sets of entities that satisfy the given proposition. That means individuals who satisfy a proposition are represented in semantics as a set of individuals (no relation to permission sets) and sets that satisfy a set proposition as a set of sets. Formal semantics details are provided in Section 3. We use two types of policy composition operators. The first type, which we refer to as external operator, does not alter sets of authorization pairs that are satisfied by their constituents. For example, the external union of policies p1 and p2 in the banking example given above, denoted by p1 t p2 , accept all choices given by either p1 or p2 (but not their combinations). Semantically, p1 t p2 is represented by the function p1 t p2 : (Clerk1, ∅) 7→ (Clerk1,{{(check, read), (check, write)}, {(check,read),(check,approve)}}). The intuitive reading of this statement is that policy p1 t p2 maps the empty permission set to either {(check,read),(check,write)} or {(check,read),(check,approve)}. The second type, the internal union, denoted by p1 ∪ p2 , is interpreted as the transformation (Clerk1,∅) 7→ (Clerk1, {{(check,read),(check,write), (check,approve)}}). As seen in this example, the internal union combines pemission sets from those in its constituent policies. In either external or internal form, policy composition operators in our algebra are conjunction, disjunction, difference, negation, invalidating all granted accesses, sequential composition, iterative closure under a set of rules, adding provisions, restricting the scope of policies, granting minimum and maximum possible permissions, and completing policies under the open- and closed-world assumptions. Disjunction, conjunction, sequential composition, and difference are binary operators, while the others are unary operators. Internal versions of several of these operators, but not all, were introduced in Bonatti et al. [2000]. Definition 1 (Syntax). In this definition, patomic is a terminal symbol taken from a set of atomic policies POL∗. Similarly, φatomic and 8atomic are terminal symbols taken from a set of atomic propositions PROP∗ and a set of atomic set (second order) propositions SET P∗, respectively. The BNF definition for ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

292

•


policies, propositions, and set propositions are as follows: p := patomic |p t p|p u p|p ¯ p|Á p|(φ :: p)|(pkφ)| p ∪ p|p ∩ p|p − p|¬p|(φ : p)|(p|φ)| ¯p|p; p|p? |min( p)|max( p)|oCom( p)|cCom( p) φ := φatomic |φ ∧ φ|φ ∨ φ|¬φ 8 := 8atomic |8 ∧ 8|8 ∨ 8|¬8 We use POL, PROP, and SET P as notations for the set of policy terms, propositions, and set propositions, respectively. As stated earlier, a policy transforms a permission set to another. In the example about the bank, one permission set in the domain of that transformation may map to more than one permission set in its range and, in that sense, it is nondeterministic. Our policy operators take such transformations and produce new ones as a result of applying the operator, which will be described shortly. Some but not all of these operators also appeared in Bonatti et al. [2000]. The difference between their definitions and ours is that their policies transformed permissions to permissions, but our policies transform permission sets to permission sets. The external disjunction, denoted by t, enlarges the range of that transformation by including permission sets allowed under either of its components. Similarly, the external conjunction, denoted by u, limits the range of the same mapping by including only those permission sets that are allowed under both components. The external difference operator, denoted by ¯ , admits those permission sets allowed under the first component but not the second. The external negation operator, denoted by Á , takes the relational complement of the mapping to denote the original policy that it is negating. The external scoping operator, denoted by ::, restricts the domain of the original mapping to those permission sets satisfying the given set-proposition representing the scope. The external provisioning operator k restricts the original mapping to those permission sets in the range satisfying the set-proposition representing the provision. The sequential composition operator, denoted by ;, permits accesses that are allowed as a consequence of applying its second component after the first. The closure operator * allows accesses permitted under repeated applications of its constituent policy and is an extension of the composition operator.1 In contrast to internal operators, external operators do not alter permission sets used by their constituents. It will be shown that external operators form a Boolean algebra that can be extended to a Heyting algebra under a suitable infinitary generalization of t and u. The internal disjunction operator, denoted by ∪, permits any union of permission sets that are allowed under either of its components, while the internal conjunction operator, denoted by ∩, permits any intersection of permission sets that are allowed under both of its components. The internal difference operator, denoted by -, permits set differences of permission sets between its first 1 The

reason for having recursion is to allow accesses that are permitted by recursively closing under some policies.

ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

293

and second components. The internal negation operator, denoted by ¬, changes all positive authorizations to negative ones and vice versa. Applying the invalidate operator, denoted by ¯, to a policy removes all authorizations granted under that policy. The internal scoping operator allows only those accesses that meet the scoping restrictions. The internal provisioning operator, denoted by |, only allows those permissions that satisfy the provisos denoted by propositions [Jajodia et al. 2001; Kudo and Hada 2000]. Note that both the internal scoping operator and the internal provisioning operator may remove accesses from a permission set and hence result in changing the permission set. In case both positive and negative permissions are granted, conflict resolution operators denoted by max and min resolve the conflict by selecting the positive and negative permissions, respectively. They model policies commonly referred to as permissions-take-precedence and denials-take-precedence. Two completion operators, denoted by oCom and cCom, close a given policy under the openand closed-world assumptions, where the former permits all accesses that are not explicitly denied, and the latter denies all accesses that are not explicitly granted. Therefore, max and min operators resolve conflicts and should be applied to over-specified policies, but oCom and cCom operators complete incomplete policies and should be applied to underspecified policies. In contrast to external operators, internal policy operators change permission sets that are allowed under their components.

3. SEMANTICS Semantically, access control policies allow specified subjects to execute desired actions over given objects. Accordingly, policies are interpreted as abstract, nondeterministic transformers of (subject, permission set) pairs, where a permission set consists of either named or explicitly listed (object, action) pairs. We use the following basic definition to formalize the semantics of policy algebra operators. Definition 2 (Subjects, Objects, and Permissions). We define subjects, objects, signed actions, and roles as basic building blocks of our semantics. We define permission sets and authorization triples using our basic building blocks as follows: (1) Subjects: Let S = {si : i ∈ N} be a set of subjects. (2) Objects: Let O = {oi : i ∈ N} be a set of objects. (3) Signed Actions: Let A = {ai : i ∈ N} be a set of action terms. Then A± = A+ ∪ A− , where A+ = {+a : a ∈ A} and A− = {−a : a ∈ A} is said to be the set of signed action terms. (4) Roles: Let R = {Ri : i ∈ N} be a set of roles. (5) Authorizations: (s, PermSet) is an authorization if one of the following conditions holds: (a) s is either a subject or a role and PermSet ⊆ O × A± . (b) s is a subject and PermSet is a role. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

294

•


We use the notation AU (S, R, O, A) for the set of all authorizations over S, R, O, and A. When there is no ambiguity about S, R, O, and A, we use AU instead of AU(S, R, O, A). (6) Permission-Prohibition Triples: We say that any (s, o, ±a), where s is either a role in R or a subject in S, o an object in O, and a a signed action term in A± , is a permission-prohibition triple. We denote the set of all permission-prohibition triples as T (S, R, O, A), shortened to T when S, R, O, and A are clear from the context. In Definition 2, actions are signed positively (+) or negatively (−) to indicate permissions and prohibitions. An authorization assigns a permission set to a subject or a role. They are are used to interpret policies. In our semantics, a policy is interpreted as a transformation of authorizations, not as a set of positive or permissions. As we have mentioned before, one authorization in the domain is mapped to a set of authorizations in the range. Formal details appear in Definition 4. In order to do so, we need to first define states. Definition 3 (State). For a given set of subjects S, objects O, roles R, actions A, propositions PROP, and set propositions SET P, a state is a pair of mappings (M prop , M setProp ), where M prop : PROP 7→ ℘(T ) and M setProp : SETP7→ ℘(℘(T )). M prop and M setProp can be extended to include Boolean connectives in the usual manner. Intutively, a state maps a proposition to a set of (subject, object, signed action) terms that satisfy the proposition. Similarly, a state maps a set proposition to a set of authorizations that satisfy the set proposition. Therefore, states are determined by the set of propositions satisfied in them. The reason for having states is to evaluate propositions and set propositions to assign meanings to provisioning and scoping operators. We use STATES for the set of all states. Now using states, we interpret atomic policies. Definition 4 (Interpreting Atomic Policies). An interpretation of atomic policies M AtPolicy is a mapping from STATES×POL∗ × (S ∪ R) × P(O × A± ) 7→ STATES×(S ∪ R) × P(P(O × A± )) satisfying the condition that s0 = s for any (s0 , PermSet 0 ) ∈ M AtPolicy (St)(p)(s, PermSet). In Definition 4, ℘() denotes the power set operator. According to Definition 4, an atomic policy maps an assignment of an authorization to a subject in a state to a set of authorizations assigned to the same subject or role in (possibly) another state. Now we extend Definition 4 to interpret all policies and propositions in Definition 6. In order to do so, we need a technical definition of negating permission sets. Definition 5 (Negating Permissions Sets). If PS ⊆ O×A± is a permission set, then let −PS denote {(o, −a) : (o, +a) ∈ S} ∪ {(o, +a) : (o, −a) ∈ PS}. If r ∈ R is a role, then (o, −a) ∈ −r iff (o, +a) ∈ r and (o, +a) ∈ −r iff (o, −a) ∈ r. Definition 5 introduces the formal notation for inverting permissions to their prohibitions and vice versa. For example, if the permission set PS is ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

295

{(file1,+read),(file2,-write)}, then −PS is {(file1,-read),(file2,+write)}. Furthermore, if role r has permissions {(file1,+read), (file2,-write)}, then role −r has {(file1,-read),(file2,+write)}. Definition 6 (Interpreting Policy Operators). An interpretation M AtPolicy of atomic policies is extended to an interpretation M policy nonatomic policies using the following definition: (1) M policy (St)(p) = M AtPolicy (St)(p) for all atomic policies p and states St. (2) M policy (St)(p t q)(s, PermSet) = M policy (St)(p)(s, PermSet) ∪ M policy (St)(q)(s, PermSet). (3) M policy (St)(p u q)(St)(s, PermSet) = M policy (St)(p)(s, PermSet) ∩ M policy (St)(q)(s, PermSet). (4) M policy (St)(p ¯ q)(s, PermSet) = M policy (St)(p)(s, PermSet) \ M policy (St)(q)(s, PermSet). (5) M policy (St)(Á p)(s, PermSet) = {(s, PS) : PS ∈ PS} \ M policy (St)(p) (s, PermSet). (6) M policy (St)(φ :: p)(s, PermSet) = M policy (St)(p)(s, PermSet), if (s, PermSet) ∈ M setProp (St)(φ), and ∅ otherwise. (7) M policy (St)(p)(pkφ)(s, PermSet) = M prop (St)(p)(s, PermSet)∩ M setProp (St)(φ). (8) M policy (St)(p; q)(s, PermSet) = {(s, PermSet1 ) ∈ M policy (St 0 )(q)(s, PermSet2 ) : for some (s, PermSet2 ) ∈ M policy (St)(p)(s, PermSet)}. (9) To define M policy (St)(p∗ )(s, PermSet), inductively define M policy (St)(pn ) using the following rules: (a) M policy (St)(p1 ) = M policy (St)(p). n n (b) M policy (St)(pn+1 ) = S M policy (St)((p; p n) ∪ p ). ∗ (c) M policy (St)(p ) = n∈ω M policy (St)(p ). (10) M pol ic y(St) (p ∪ q)(s, PermSet) = {(s, PermSetp ∪ PermSetq ) : (s, PermSetp ) ∈ M policy (St)(p)(s, PermSetp ) and (s, PermSetq ) ∈ M policy (St)(q)(s, PermSetq )} (11) M policy (St)(p ∩ q)(s, PermSet) = {(s, PermSetp ∩ PermSetq ) : (s, PermSetp ) ∈ M policy (St)(p)(s, PermSetp ) and (s, PermSetq ) ∈ M policy (St)(q)(s, PermSetq )} (12) M policy (St)(p − q)(s, PermSet) = {(s, PermSetp \ PermSetq ) : (s, PermSetp ) ∈ M policy (St)(p)(s, PermSetp ) and (s, PermSetq ) ∈ M policy (St)(q)(s, PermSetq )} (13) M policy (St)(¬p)(s, PermSet) = {(s, −PermSet 0 ) : (s, PermSet) ∈ M policy (St) (p)(s, PermSet, 0 )}. (14) M policy (St)(φ : p)(s, PermSet{(o, a) 6∈ M prop (St)(φ)}) = M if M policy (St)(p)(s, PermSet) = M . (15) M policy (St)(p \ φ)(s, PermSet) = M provided that M policy (St)(p)(s, PermSet) / M prop (St 0 )(φ)})}, where M policy (St)(p) = St 0 . = {(s, PermSt0 {(o, a) : (s, o, a) ∈ (16) M policy (St)(max(p))(s, PermSet) = {(s, PermSet1 ) : PermSet1 = PermSet2 \ {(o, −a) : (o, +a), (o, −a) ∈ PermSet2 } for some (s, PermSet2 ) ∈M policy (St)(p) (s, PermSet)}. (17) M policy (St)(min(p))(s, PermSet) = {(s, PermSet1 ) : PermSet1 = PermSet2 \ {(o, +a) : (o, +a), (o, −a) ∈ PermSet2 } for some (s, PermSet2 ) ∈M policy (St)(p) (s, PermSet)}. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

296

•


(18) M policy (St)(¯(p))(s, PermSet) = (s, ∅). (19) M policy (St)(cCom(p))(St)(s, PermSet) = {(s, PermSet1 ) : PermSet1 = PermSet2 ∪ {(o, −a) : (o, −a), (o, +a) 6∈ PermSet2 } for some (s, PermSet2 ) ∈ M policy (St)(p)(s, PermSet). (20) M policy (St)(oComp)(s, PermSet) = {(s, PermSet1 ) : PermSet1 = PermSet2 ∪ {(o, +a) : (o, −a), (o, +a) 6∈ PermSet2 } for some (s, PermSet2 ) ∈ M policy (St)(p) (s, PermSet). Note that some of the internal operators were introduced by Bonatti et al. [2000]. Now we explain the difference between external and internal operators. For example, consider the external union t. As stated in Definition 6, M policy (St)(pt q)(s, PermSet) = M policy (St)(p)(s, PermSet)∪ M policy (St)(q)(s, PermSet). Consider the example of policies p and q that have the following semantics: (1) Suppose that policy p maps (Alice, ∅) in state St to (Alice, {{(file1,+read),(file1,-write)}, {(file2,-read),(file2,+write)}}) in state St’. That means if Alice had no permissions prior to applying p, then p allows her to read but not write file1 or write but not read file2. That is, policy p gives a read-only lock on file1 or a write-only lock on file2 to Alice as one of two possibilities. (2) Similarly, suppose that policy q maps (Alice, ∅) in state St to (Alice, {{(file2,+read),(file2,-write)}, {(file1,-read),(file1,+write)}}) in state St’. That means if Alice had no permissions prior to applying q, then q grants Alice read but not write permissions on file2 or write but not read permissions on file1. That means policy q grants a read-only lock on file2 or a write-only lock on file1 to Alice. (3) According to Definition 6, in state St, p t q maps (Alice, ∅) to (Alice,{{(file1,+read),(file1,-write)}, {(file2,-read),(file2,+write)}} ∪ { {(file2,+ read),(file2,-write)},{(file1,-read), (file1,+write)}}). That is, p t q grants Alice either read but not write or write but not read locks to either file1 or file2. Thus, p t q grants one of four sets of permissions to Alice, whereas p and q allowed only two included in the four granted by p t q. (4) In contrast, according to Definition 6, the internal union of p and q, denoted by p ∪ q, maps (Alice, ∅) to the union of any two sets taken from { {(file1,+read), (file1,-write)}, {(file2,-read), (file2,+write)} } and {{(file2,+read),(file2,-write)}, {(file1,-read),(file1,+write)} }. That results in mapping from (Alice,∅) in state St to (Alice,PermSet) where PermSet has the following elements in state St 0 : —{(file1,+read), (file1,-write), (file2,+read),(file2,-write)} —{(file1,+read), (file1,-write), (file1,-read),(file1,+write)} —{(file2,-read),(file2,+write), (file2,+read),(file2,-write)} —{(file2,-read),(file2,+write), (file1,-read),(file1,+write)} Therefore, p∪q does not enforce any form of locking, as permission sets such as {(file2,-read),(file2,+write), (file2,+read),(file2,-write)} are even contradictory. But there are many examples of useful internal operators, as shown ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

297

in Bonatti et al. [2000]. Similar differences exist between external and internal intersection and difference operators. As we mentioned earlier, our internal operators are those introduced in Bonatti et al. [2000]. Likewise, our definitions of external conjunction, disjunction, and difference have been used earlier in the nondeterminism and concurrency literature. See, for example, Chandra et al. [1981]. Note that composition and recursion are external operators. These definitions are again taken from the programming logics literature [Peleg 1987; Manna 1970]. Our scoping operators restrict the domain of the M policy (St)(s, PermSet) to those (s, PermSet) pairs that satisfy the proposition specifying the scope. In the case of the external scoping operator, only those permission sets in the range that satisfy the specified proposition remain, and the rest are not taken. For example, consider the policy p that is defined as follows. Let p map (Alice,{{(file1,+read),(file1,-write)}}) in state St to (Alice, {{(file1,+write), (file1,-read)}, {(file1,+read),(file1,-write)}}) in state St’, and (Alice,{{(file1,+read),(file1,-write), (file2,+write),(file2,-read)}}) in state St to (Alice, {{(file1,+write), (file1,-read)}, {(file1,+read),(file1,-write)}}) in state St’. Thus, p swaps read and write locks between file1 and file2. Now assume that we want to restrict the scope of p so that p switches the lock of file1’s permissions only. Now let 8 be the proposition that is satisfied by permission sets that have only file1 as an object. (Formally, 8 is the second order statement ∀ y∀z[( y, z) ∈ X → y = file1] with the free set variable X .) Therefore, when {(file1,+read),(file1,-write)} is substituted for X , 8 is satisfied, but not when {(file1,+read),(file1,-write), (file2,+write),(file2,-read)} is substituted. Hence, (8 : p) maps (Alice, {{(file1,+read),(file1,-write)}}) in state St to (Alice,{{(file1,+write),(file1,-read)}, {(file1,+read),(file1,-write)}}) in state St’ and p maps (Alice,{{(file1,+read),(file1,-write), (file2,+write),(file2,-read)}}) in state St to (Alice,∅) in state St’. For internal scope, let us assume that we want to alter p so that it grants the same permissions as before, but only to read locks. To do so, let φ be the proposition that symbolizes the first-order statement permission(x,+read) ∨ permission(x,-read), where permission(x, ± a) means that subject x has permission a. Then (φ : p) maps (Alice,{{(file1,+read)}}) in state St to (Alice,{{(file1,+write),(file1,-read)}, {(file1,+read),(file1,-write)}}) in state St’ and (Alice,{{(file1,+read),(file2,-read)}}) in state St to (Alice,{{(file1, + write),(file1,-read)}, {(file1,+read),(file1,-write)}}) in state St’. Similarly, our definition of the provisioning operator restricts the range of the mapping M policy (St)(s, PermSet) to that satisfying the provisioning proposition. Such definitions for scoping and provisioning have been introduced in Jajodia et al. [2001] and Kudo and Hada [2000]. The min and max operators correspond to prohibitions take precedence and permissions take precedence in conflict resolution policies. These names were chosen because when both signed +a and -a are present for the same object’s permissions, they select -a (i.e., the minimum of the two) and +a (i.e., the maximum of the two), respectively. As stated earlier, these operators are to be applied ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

298

•


to overspecified policies. oCom and cCom add permissions and prohibitions, respectively when neither is present. That is, when neither +a nor -a is specified by a policy p, oCom(p) adds +a and cCom(p) adds -a. All four of min(p) , max(p,) oCom(p), and cCom(p) have been used to specify security policies [Jajodia et al. 1997a, 1999]. 4. THE ALGEBRA OF OPERATORS Now we explore algebraic properties of policy operators. First, because our policy framework is designed to be general, the properties are limited in number, and their verification can be reduced to verifying simple algebraic properties of sets, relations, and functions. Second, we have explored two different types of policy operators, namely, external and internal. Therefore, semantic differences between these two types of operators give rise to different algebraic properties. For example, some distributivity and idempotency properties that hold for external operators do not hold for internal operators and vice versa. Section 4.1 states properties of external operators and Section 4.2 states properties of internal operators.

4.1 Algebra of External Operators THEOREM 1. External operators, namely, (P O L, t, u, Á , 1pol , 0pol ) form a Boolean algebra under the following interpretation of 1pol and 0pol . M policy (St)(1pol )(s, PermSet) = (s, ℘(P S)) M policy (St)(0pol )(s, PermSet) = (s, ∅) for each s ∈ S ∪ R and St ∈ STATES. PROOF.

See the Appendix.

Theorem 1 shows some properties of policy compositions. First, 1pol and 0pol are specific policies that are in a sense at opposite ends. The first grants all possible sets of permissions and the second grants no permissions. Therefore, taking the external intersection and union with 1pol does not alter the interpretation of any other policy p and adds all possible sets of permissions, respectively. In addition, as a Boolean algebra, t and u satisfy distributivity properties satisfied by propositional operators such as ∨ and ∧. In this respect, 1pol and 0pol act like True and False in truth tables. In summary, Theorem 1 says that we can manipulate policy operators just as operators in propositional logic and therefore use the same disjunctive or conjunctive normal forms etc. Although Boolean algebra gives a sense of familiarity in manipulating policy operators, it does not cover other operations such as sequencing (;). Now we explore other properties of external operators. As will be seen shortly, some distributive laws such as (p1 u p2 ); p3 = (p1 ; p3 ) u (p1 ; p3 ) fail to hold. Theorem 2 provides details. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

299

THEOREM 2. Let p, p1 , p2 , and p3 be policy terms and I = (M policy , M prop , M setProp ) be an interpretation. Then the following properties are valid in I : (1) Idempotency of conjunctions and disjunctions: (a) p t p = p; (b) p u p = p; (2) Distributivity of composition over unions and intersections: (a) (p1 t p2 ); p3 = (p1 ; p2 ) t (p1 ; p3 ) (b) p1 ; (p2 t p3 ) = (p1 ; p2 ) t (p1 ; p3 ) (c) (p1 u p2 ); p3 ⊆ (p1 ; p3 ) u (p2 ; p3 ) (d) p1 ; (p2 u p3 ) ⊆ (p1 ; p2 ) u (p1 ; p3 ) (3) Properties of the scoping operator: (a) 8 :: (9 :: p) = (8 ∧ 9) :: p (b) 8 :: (p1 t p2 ) = (8 :: p1 ) t (8 :: p2 ) (c) 8 :: (p1 u p2 ) = (8 :: p1 ) u (8 :: p2 ) (d) 8 :: (p1 ; p2 ) = (8 :: p1 ); p2 (e) 8 :: (p1 ¯ p2 ) = (8 :: p1 ) ¯ (8 :: p2 ) (4) Properties of the provisioning operator: (a) (pk8)k9 = pk(8 ∧ 9) (b) (p1 t p2 )k8 = (p1 k8) t (p2 k8) (c) (p1 u p2 )k8 = (p1 k8) u (p2 k8) (d) (p1 ; p2 )k8 = p1 ; (p2 k8) (e) (p1 ¯ p2 )k8 = (p1 k8) ¯ (p2 k8) PROOF.

See the Appendix.

Theorem 2 shows how policy operators interact with each other. Note that our definitions of unions and intersections have similarities with automata theoretical operators, in which the sequencing operator (;) distributes over unions and intersections. However, as stated in 1(a)–(d) of Theorem 2, (;) distributes over t but only partially over u. The reason for this partiality is that in automata that accept regular expressions, the transition relation is between states, but in our case the transition relation takes a state to a set of states. Theorem 2 also shows that scoping and provisioning operators distribute over unions, intersections, and sequencing operators. The advantage of these algebraic identities is that they can be used to express composed policies in particular forms. For example, identities such as 8 :: (p1 t p2 ) = (8 :: p1 ) t (8 :: p2 ) and 8 :: (p1 u p2 ) = (8 :: p1 ) u (8 :: p2 ) can be used to collect all policies that are subject to the same scoping restriction.

4.2 Algebra of Internal Operators Internal operators, most of which were introduced in Bonatti et al. [2000], satisfy different algebraic properties. As they do not satisfy properties such as p ∪ p = p and p ∩ p = p, they do not form a Boolean algebra. Properties satisfied by internal operators are given in Theorem 3. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

300

•


THEOREM 3.

The following properties hold for all policies:

(1) Partial idempotency of unions and intersections: (a) p ⊆ (p ∪ p) (b) p ⊆ (p ∩ p) (2) Associativity of unions, intersections, and compositions: (a) (p1 ∪ p2 ) ∪ p3 = p1 ∪ (p2 ∪ p3 ). (b) (p1 ∩ p2 ) ∩ p3 = p1 ∩ (p2 ∪ p3 ). (c) (p1 ; p2 ); p3 = p1 ; (p2 ; p3 ). (3) Commutativity of unions and intersections: (a) p1 ∪ p2 = p2 ∪ p1 . (b) p1 ∩ p2 = p2 ∩ p1 . Composition (i.e., ;) is not commutative, as expected. (4) Distributivity of unions and intersections: (a) p1 ∪ ( p2 ∩ p3 ) = (p1 ∪ p2 ) ∩ (p1 ∪ p3 ). (b) p1 ∩ (p2 ∪ p3 ) = (p1 ∩ p2 ) ∪ (p1 ∩ p3 ). (5) Right distributivity of compositions over unions and intersections: (a) p1 ; (p2 ∩ p3 ) ⊆ (p1 ; p2 ) ∩ (p1 ; p3 ). (b) p1 ; (p2 ∪ p3 ) = (p1 ; p2 ) ∪ (p1 ; p3 ). Compositions are not left distributive over unions and intersections. (6) Properties of the difference operator: (a) p1 − (p2 ∪ p3 ) = (p1 − p2 − p3 ). (b) ¬(p1 − p2 ) = (¬p1 ) − (¬p2 ). (7) Properties of the null operator: (a) Idempotency: ¯ ¯ p = ¯p. (b) ¯(p1 ∪ p2 ) = (¯p1 ) ∪ (¯p2 ). (c) ¯(p1 ∩ p2 ) = (¯p1 ) ∩ (¯p2 ). (d) Distributivity over compositions: ¯(p1 ; p2 ) = (p1 ; ¯p2 ). (8) Properties of the negation operator: (a) Self inversion: ¬¬p = p. (b) ¬(p1 ∪ p2 ) = (¬p1 ) ∪ (¬p2 ). (c) ¬(p1 ∩ p2 ) = (¬p1 ) ∩ (¬p2 ). (d) ¬(p1 ; p2 ) = (p1 ; ¬p2 ). (9) Properties of the scoping operator: (a) φ : (ψ : p) = (φ ∧ ψ) : p (b) φ : (p1 ∪ p2 ) = (φ : p1 ) ∪ (φ : p2 ) (c) φ : (p1 ∩ p2 ) = (φ : p1 ) ∩ (φ : p2 ) (d) φ : (p1 ; p2 ) = (φ : p1 ); p2 (e) φ : (p1 − p2 ) = (φ : p1 ) − (φ : p2 ) (10) Properties of the provisioning operator: (a) (p | φ) | ψ = p | (φ ∧ ψ). (b) (p1 ∪ p2 ) | φ = (p1 | φ) ∪ (p2 | φ). (c) (p1 ∩ p2 ) | φ = (p1 | φ) ∩ (p2 | φ). (d) (p1 ; p2 ) | φ = p1 ; (p2 | φ). ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

301

(11) Properties of max and min operators: (a) max{p1 ; p2 } = p1 ; max{p2 }. (b) min{p1 ; p2 } = p1 ; min{p2 }. (12) Properties of completion operators (a) oCom(oCom(p)) = oCom(p) (b) cCom(cCom(p)) = oCom(p) (c) cCom(oCom(p)) = oCom(p) (d) oCom(cCom(p)) = cCom(p) (e) oCom(p1 ; p2 ) = p1 ; (oComp2 ) (f) cCom(p1 ; p2 ) = p1 ; (cComp2 ) (13) Miscellaneous interactions between operators: (a) ¬ ¯ p = ¯p = ¯¬p. (b) max{p1 ; p2 } = p1 ; max{p2 }. (c) min{p1 ; p2 } = p1 ; min{p2 }. (d) max{¯p} = ¯ max { p} = ¯p. (e) min{¯p} = ¯ min {p} = ¯p. PROOF.

See the Appendix.

Theorems 2 and 3 have long lists of properties satisfied by internal and external operators. The first difference between external and internal operators is that the former satisfy idempotency properties such as p t p = p and p u p = p, but the latter satisfy them only partially. As Theorem 3 lists, only p ⊆ (p∪p) and p ⊆ (p∩p) hold. One of the consequences of this partial failure of idempotency is that internal operators do not form a Boolean algebra. Therefore, simplifications that were possible for external operators are not possible for internal operators. The primary reason for this failure is the fact that in our semantics, the range is a set and not a single permission. For policies where the range is always a set with one permission, idempotency of ∪ and ∩ holds, as described in Lemma 1. Because usual Boolean properties fail for internal operators, next we state other related properties, resulting in a rather long list. Some other properties, such as commutativity and associativity of ∪ and ∩ hold, implying some simplifications of policy expressions are possible. But distributivity of the sequencing operator over ∪ and ∩ runs into problems, as shown in Theorem 3. One of the consequences of the failure of distributivity of (;) over ∪ and ∩ is that expressions involving ∪ and ∩ can be simplified using laws of commutativity, associativity, and distributivity as long as they do not involve sequential composition. Again, the reason is that our policies return permission sets. Scoping, provisioning, and negation operators satisfy the same distributivity properties over internal and external operators, implying that similar simplifications such as collecting common provisions and scopes are possible using properties such as (p1 ∪ p2 ) | φ = (p1 | φ) ∪ (p2 | φ) and (p1 ∩ p2 ) | φ = (p1 | φ) ∪ (p2 | φ). 4.3 Singular Policies As explained earlier, in our model, given a state St and a subject S with a set of permissions, PermSet is mapped to a collection of permission sets ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

302

•


M(St)(p)(S,PermSet) by a particular policy p. In this section, we consider the consequences of assuming that permissions in PermSet can be granted one at a time. That means if (S,PS)∈M(St)(p)(S,PermSet), then (S,PS’) ∈ M(St)(p)(S,PermSet) for every subset PS’ of PS. First, we state a formal definition, and then explain it by means of an example, and finally discuss its consequences. Definition 7 (Singular Policies). We say that a policy p is singular if whenever (s, PS) ∈ M policy (St)(p)(s,PermSet’), (s, PS’)∈ M policy (St)(p) (s,PermSet) for all subsets PS’⊆ PS. Furthermore, if (s, PS1 ), (s, PS2 ) ∈ M policy (St)(p)(s,PermSet), then so is (s, PS1 ∪ P S2 ) ∈ M policy (St)(p)(s,PermSet). Let us consider the example where p maps (Alice,{{(file1,+read),(file2,+ write)}}) to (Alice, {{(file2,+read),(file2,-write),(file1,+write),(file1,-read)}}) and also to (Alice, {{(file1,+read),(file1,-write), (file3,+write),(file3,-read)}}). If p is singular, then it maps (Alice,{{(file1,+read),(file2,+write)}}) to all subsets of {(file2,+read),(file2,-write),(file1,+write),(file1,-read), (file3,+read),(file3, -write),(file1, +write),(file1,-read)}. That includes permissions such as {(file1,+write),(file3,+write)}. Note that the originally assigned permission sets changed exclusive write locks from file1 to either file2 or file3, but not both. But if p is singular, then the exclusivity of locks disappears. Nevertheless, the main intuition behind this definition is that every access permission is granted on its own, and thus any combinations of granted permissions are acceptable. In contrast, nonsingular policies explicitly state allowed combinations. Many published papers that were main precursors to ours, such as Bonatti et al. [2000] and Jajodia et al. [2002], use singular policies; that means every permission is granted or denied on its own merits. Therefore, results obtained under this assumption allow us to directly compare results with those of Bonatti et al. [2000] and Jajodia et al. [2002]. The first consequence we have to explore is the closure properties of singular policies. In our definition, singular policies are not closed under external operators such as t, u. The reason is that if (S,{{(file1,+read)}}) ∈ M(St)(p)(S,∅) and (S,{{(file1,+write)}}) ∈M(St)(p)(S,∅), then we do not have (S,{{(file1,+read),(file1,+write)}}) ∈ M(St)(p t q)(S,∅). But singular policies are closed under internal operators, as stated in Lemma 1. As these results show, singular policies are appropriate for modeling some access control requirements, but they must be then composed using external but not internal operators. The reason is that in singular policies every permission is granted based on its own, not as a member of a set, and therefore do not work well with external operators that are designed to work with sets. LEMMA 1. PROOF.

Singular policies are closed under internal operators.

See the Appendix.

In addition to closure under internal operators, as stated in Lemma 2, internal unions and intersections are idempotant operators on singular policies. Note that as stated in Theorem 3, nonsingular polices are guaranteed to satisfy only (p ∩ p) ⊆ p(p ∪ p). The result of Lemma 2 is useful because it says that ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

303

taking the union of a singular policy with itself does not add any extra signed permissions. LEMMA 2 (Idempotency of Singular Policies). for singular policies:

The following properties hold

(1) (p ∪ p) = p (2) (p ∩ p) = p PROOF.

Similar to the proof of Lemma 1.

4.4 Extending (P O L, t, u, Á , 1pol , 0pol ) to Infinitary Constructs This section extends external union and intersection operators to infinitary versions. There are several motivations behind this extension. First, we recall the way recursive closure is defined: for any policy p, pi is defined recursively as pi+1 = (pi t (p; pi )). Then the semantics of p∗ is defined as (syntacti∞ ∞ pi+1 . But we do not have a syntactic term for ti−=0 pi+1 . cally nonexistent) ti−=0 ∞ i+1 as a policy in our Adding infinitary unions would facilitate having ti−=0 p syntax. Introducing infinitary disjunction to the syntax makes reasoning about properties of recursive closure an easier task. For example, suppose that we need to prove that applying policy p∗ in a state where the subject Alice has no permissions always ends up in states that satisfy some property ψ. Then what we need to prove is that for every i, applying policy pi in a state where the subject Alice has no permissions always ends up in states that satisfy ψ and that infinitary disjunction preserves ψ. Another advantage of introducing infinitary constructs is that when taking conjunctions or disjunctions over a collection of properties, we do not need to ensure the finiteness of the collection over which union and intersection operators are applied. For these reasons, we extend Definition 1 to include infinitary conjunctions and disjunctions as follows. Definition 8 (Infinitary External Operators). Add the following clause to Definition 1. That is, extend the language to include infinitary external conjunctions and disjunctions: p := t∞ {p ∈ P } | u∞ {p ∈ P } Here P ⊆ POL is a set of policy terms. Then extend the semantic definition (i.e., Definition 6) to include: M policy (St)(t∞ {p ∈ P })(s, PermSet) = ∪p∈P M policy (St)(p)(s, PermSet) M policy (St)(u∞ {p ∈ P })(s, PermSet) = ∩p∈P M policy (St)(p)(s, PermSet) Then, one of the main concerns is what are the properties of infinitary constructs. Here we show that t∞ and u∞ are generalizations of external operators t and u, respectively and (P O L, t∞ , u∞ , Á , 1pol , 0pol ) forms a complete Heyting algebra. A Heyting algebra is a generalization of a Boolean algebra. Heyting algebras model intuitionistic reasoning (where ψ ∨ ¬ψ is not a tautology) in the same way that Boolean algebras model propositional reasoning [Gabbay 1981]. Heyting algebras have been used to model programming languages in ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

304

•


which convergence is not guaranteed (here, ψ is taken as the proposition that a program converges) [Girard et al. 1989]. THEOREM 4. t∞ and u∞ are generalizations of external operators t and u, respectively and (P O L, t∞ , u∞ , Á , 1pol , 0pol ) is a complete Heyting algebra. PROOF.

See the Appendix.

Heyting algebras satisfy infinitary distributive laws, such as (p1 u (t∞ {p ∈ P }) = t∞ (p1 u p){p ∈ P }. Now let us explain how we can apply this infinitary distributive law to reason about recursion. Take P as {pi : 0 ≤ i}. Then the ∞ i ∞ p ) = ti=0 (p1 u pi ). Note that stated infinitary distributive law gives p1 u (ti=0 ∞ i now (ti=0 p ) is p∗. Hence, if we want to infer that some property (say) ψ holds in all post states after applying p1 u p∗, it suffices to prove that ψ holds in all post states after applying p1 u pi for all i. Usually, the latter can be proved using induction over i. 5. DETERMINISM, CONSISTENCY, AND COMPLETENESS Our framework for policy compositions allows for composing inconsistent, incomplete, or nondeterministic policies. But, deterministic policies are also important in access control specifications, and some related frameworks such as Bonatti et al. [2000] and Jajodia et al. [2002] only address policies deterministic in the sense of Definition 9. Because our broader formulation of policies allows inconsistent, incomplete, and nondeterministic policies, we define these notions formally and explore their closure properties. 5.1 Determinism In this section, we consider various flavors of determinisms and their consequences in access control policies. To motivate the need for both determinism and nondeterminism, consider an example security policy with two roles: a producer role and a consumer role. Assume that both roles require exclusive read/write access rights to a data buffer, say f . Alice wants to play them interchangeably. We specify these access requirements with policies as follows: — pinitial maps (Alice,∅) to (Alice,{{(f,+read),(f,-write)}, {(f,-read),(f,+write)}}). — pswap maps (Alice,{{(f,+read),(f,-write)}}) to (Alice,{{(f,-read),(f,+write)}}) and vice versa. — pend maps both (Alice,{{(f,+read),(f,-write)}}) and (Alice,{{(f,-read),(f, +write)}}) to (Alice,{{(f,-read),(f,-write)}}). Consider the policy pinitial . First, it allows Alice to choose between reader’s and writer’s roles initially. This policy is nondeterministic. Second, the policy pswap allows Alice to switch roles from a reader to a writer and vice versa. This policy is deterministic. Third, the policy pend allows Alice to end playing reader or writer roles. This policy is deterministic. Thus, pinitial t pswap t pend permits all combinations of access requirements for Alice to safely play producer and ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

305

consumer roles. As this example shows, deterministic and nondeterministic policies are useful in modeling access control specifications. Now we formally state these intuitive concepts. Definition 9 (Determinism). Let p be a policy, I = (M policy , M prop , M setProp ) be an interpretation, and (s,PermSet) be an authorization. (1) Deterministic with respect to Authorizations: We say that a policy p is deterministic for the authorization (s,PermSet) in the interpretation I if the cardinality of the set M policy (St)(p)(s,PermSet) is one for all states St. That is, | M policy (St)(p)(s,PermSet)| = 1 for all states St. If a policy p is not deterministic with respect to an interpretation I and an authorization it is said to be nondeterministic with respect to I and (s,PermSet). (2) Deterministic with respect to an Interpretation: We say that a policy p is deterministic with respect to an interpretation I if it is deterministic for every authorization in I . If a policy p is not deterministic with respect to an interpretation I , then it is said to be nondeterministic with respect to I . (3) Deterministic Policy: We say that a policy p is deterministic if whenever for every interpretation I , all atomic constituents of p are deterministic, then so is p. If a policy p is not deterministic, then it is said to be nondeterministic. (4) Ultra Deterministic Policy: We say that a policy p is ultra deterministic if p is deterministic with respect to all interpretations I . If a policy p is not ultra deterministic, then it is said to be nonultra deterministic. Definition 9 states four flavors of nondeterministic access control policies. In the first flavor, determinism depends on the subject and an authorization available in a state for that subject. For example, consider a world with two subjects Alice and Bob, one object file1, and two types of actions read and write applicable to file1. Now consider a policy p that maps (Alice,∅) to (Alice,{ {(file1,+read),(file1,+write)}, {(file1,+write)}}) and (Bob,∅) to (Bob, {{(file1,+read)}}). Hence, p allows Alice a choice of having either write permissions or both read and write permissions (two choices). But p allows Bob only one choice, namely, read permissions to file1. Hence, p is nondeterministic for Alice (without any permissions) but deterministic for Bob. Conversely, this flavor of nondeterminism depends on how the policy is interpreted in a model. There is nothing stated in the syntax of p (at the higher propositional level) that can be used to infer the semantic difference between Alice’s and Bob’s permission choices or lack thereof. The second flavor of determinism also depends on the semantics of a policy, but not on the (subject,PermSet) pair. For example, consider a policy p that is to be applied in a world in which there is one subject Alice, two objects file1,file2 and two actions read and write applicable to file1 and file2. Now consider two models, M 1 and M 2 of p. In the first model M 1 , p maps (Alice, ∅) to (Alice, { {(file1,+read),(file2,+write)}, {(file1,+write),(file2,-read)}}). In the second model, M 2 , p maps (Alice, ∅) to (Alice, { {(file1,+read),(file2,+write)}}). Note that M 1 allows Alice to have either the permissions {(file1,+read),(file2,+write)} ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

306

•


or {(file1,+write),(file2,-read)}, but M 2 only allows the latter. Hence, the same atomic policy p is nondeterministic in M 1 , but deterministic in M 2 . Therefore, according to the second flavor, determinism or nondeterminism depends on how a policy is interpreted. That is, in a way, a disadvantage of modeling policies at the higher propositional level but, as this example shows, it is possible to do so. Note that, for example, nondeterministic policies of previous notions of determinism were constructed by using nondeterministic atomic policies. The third flavor of nondeterminism is designed to disallow this trick. Hence, in the third flavor of determinism, a policy p is said to be deterministic provided that p is deterministic with respect to all interpretations in which all atomic constituents of p are deterministic. For example, consider the atomic policies p and q. In this case, we are allowed to consider models in which p and q are interpreted to be atomic. That means, in a world consisting of one subject Alice, one object f , and two actions read and write applicable to f , every model must map ( Al ice, ∅) deterministically under p and q. For example, consider a model in which p maps (Alice,∅) to (Alice, { {(f,+read)}}) and q maps (Alice,∅) to (Alice, {{(f,+write)}}). Then p t q maps (Alice,∅) to (Alice,{{(f,+read)}, {(f,+write)}}). Hence, p t q is not deterministic, as it allows Alice a choice of obtaining either read or write permissions, although the atomic constituents of p t q are deterministic. However, the internal union p∪q maps (Alice,∅) to (Alice, { {(f,+read),(f,+write)}}), making p ∪ q deterministic. The definition of ultra determinism is stricter, where the assumption about the determinism of atomic constituents of a policy is being removed from the third flavor of determinism. That means a policy p is ultra deterministic iff | M policy (St)(p)(s,PermSet)| = 1 for all subjects s, states St in all models M . None of the examples given as atomic policies for the first three flavors are ultra deterministic. Reflecting upon the four flavors of determinism presented in Definition 9, the first two are dependent upon the interpretation of atomic policies. There again the second flavor is more stringent than the first. However, the third flavor disallows interpreting atomic policies to be deterministic with respect to the second flavor. The fourth flavor, while being most stringent, is almost impractical to verify without looking at all possible interpretations. Therefore, our recommendation is to consider the third flavor as the appropriate definition of determinism. Our recommendation is based upon the precedents set forth in the concurrency literature [Barringer 1985]. In the semantic models of nondeterministic programs, atomic constructs such as assignments of values to variables (i.e., x:=a) are deterministic. That is, assuming that a is a constant, there is only one post state for executing x:=a, namely, the state in which the variable x takes the value a. Nondeterminism is only possible due to constructs such as the if . . . then . . . else . . . construct. Note that executing if . . . then . . . else . . . may lead to one of two possibilities that may not be known without evaluating the condition of the if . . . then . . . else . . .. Applying this reasoning for access control policies leads us to the third choice. Given that we use the third flavor of determinism, next we determine the policy operators that preserve determinism in Lemma 3. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


LEMMA 3.

•

307

Determinism is closed under the following operators.

(1) External Operators: Conjunctions (u), sequencing (; ), scoping (k), provisioning (::), and differences ( ¯ ). (2) Internal Operators: Disjunction (∪), conjunction (∩), and negation (¬). In addition, if policy p is deterministic, then p ∪ p = p and p ∩ p = p PROOF.

Follows from properties of relational compositions.

Now let us consider the utility of Lemma 3. Now suppose we have have two policies p and q that are deterministic. Lemma 3 states that p u q is deterministic. But it does not say that p t q is deterministic. If our objective is to create deterministic policies, then we know that p u q is always deterministic no matter how p or q are interpreted in a model, but p t q does not behave so. That means, in order to ensure that p t q is deterministic, we need to know how it is interpreted in models that are of interest to us. Consider, for example, policies p that maps (Alice,∅) to (Alice,{{( f 1 ,+read)}}) and q that maps (Alice,∅) to (Alice, {{( f 1 ,+write)}}). Then ptq maps (Alice, ∅) to (Alice, {{( f 1 ,+read)},{( f 1 ,+write)}}), and is nondeterministic. But p u q maps (Alice,∅) to (Alice,∅), making it deterministic. But the last claim is true for all deterministic policies, and we did not have to look at intended interpretations to assert so, due to Lemma 3. 5.2 Consistency Now we address the issue of consistency. Recall that our models of policies map every (s,PermSet) to a set of (s,PermSet) where s is a subject and PermSet consists of (object, signed action) terms. To motivate our discussion, consider the example of a policy p that maps (Alice,∅) to (Alice, {{(file1,+read),(file2,-write)},{(file1,-read),(file2,+write)}}). The intuitive interpretation of p is that if Alice has no permissions, then she is granted permission either to read file1 but not write file2 or not read file1 but write file2. Note that in either case, p does not give contradictory permissions, such as granting both positive and negative read permissions to Alice on file1. Now consider another policy q that maps (Alice,∅) to {(Alice,{{(file1,+read),(file1,+write)}}). Note that q also does not grant contradictory permissions. Now consider the policy p ∪ q that maps (Alice,∅) to (Alice,{{(file1,+read),(file2,-write),(file1,+write)}, {(file1,-read),(file2,+write),(file1,+read), (file1,+write)}}). Note that p ∪ q now grants Alice two options of either {(file1,+read),(file2,-write),(file1,+write)} or {(file1,-read),(file2,+write),(file1,+read),(file2,+write)}, where the first one is noncontradictory and the second is contradictory. The reason for the contradiction arises from assigning both (file1,-read) and (file1,+read) within the same permission set. As seen from this example, some combinations of policies lead to options that are contradictory and others that are not. Our objectives in this section are to formalize the appropriate notions of consistency (i.e., lack of contradictions) and determine which policy operators preserve consistency. We need to deal with the complication that some policies map consistent ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

308

•


sets of permissions to some but not all consistent states. Some other policies may lead to all consistent states, and yet some others may lead to all contradictory states. As an example of the former, consider a policy r that maps (Alice,∅) to (Alice,{{(file2+read),(file1,+write)}}). Then p ∪ r maps (Alice,∅) to (Alice, {{(file1,+read), (file1,+write),(file2+read),(file2,-write)}, {(file1,-read),(file1,+write),(file2,+write),(file2, +read)}}). As an example of the latter, consider a policy p1 that maps (Alice,∅) to (Alice, {{(file1,-read),(file2,-write)}}). Then p ∪ p1 maps (Alice,∅) to (Alice, {{(file1, +read),(file1,-read),(file2,-write)}, {(file1,-read),(file2,+write),(file2,-write)}}). To summarize, p ∪ r maps a consistent state to a set of states that are all consistent, p ∪ r maps a consistent state a set of states in which some but not all states are consistent, and p ∪ p1 maps a consistent state to a set of inconsistent states. The above examples show the distinction between possible and necessary consistency of policies. This distinction has been studied in programming logics in the past [Harel 1979; Peleg 1987]. Following this tradition, our definitions and theorems about consistency (and completeness) address the notions of possible and necessary consistency. We begin this study by first formalizing these concepts in Definition 10. Definition 10 (Consistency). Let p be a policy, I = (M policy , M prop , M setProp ) be an interpretation, and (s,PermSet) be an authorization. (1) Contradictory Permission Sets: We say that a permission set PermSet is contradictory if there do not exist an object o and an action a such that (o,+a),(o,-a) ∈ PermSet. We say that an authorization (s,PermSet) is contradictory iff PermSet is contradictory and noncontradictory otherwise. (2) Policies Consistent for Authorizations: We say that a policy p is possibly/necessarily consistent for a noncontradictory authorization (s,PermSet) with respect to the interpretation I , if some/all PermSet’ satisfying (s, PermSet’) ∈ M policy (St)(p)(s,PermSet) is noncontradictory. (3) Policies Consistent with respect to an Interpretation: We say that a policy p is possibly/necessarily consistent with respect to an interpretation I if it is possibly/necessarily consistent for every authorization with respect to I . (4) Consistent Policy: We say that a policy p is possibly/necessarily consistent if it is possibly/necessarily consistent with respect to every interpretation I . According to the first concept in Definition 10, a permission set is contradictory if it contains both (o,+a) and (o,-a) for some object o and action a. For example, permission set {(file1,+read),(file1,-read), (file2,-write)} is contradictory, while {(file1,+read),(file1,+write), (file2+read),(file2,-write)} is not contradictory. According to the second concept in Definition 10, a policy is consistent for an authorization with respect to a given interpretation. Therefore, a policy can be consistent for an authorization with respect to one interpretation, but inconsistent with respect to another interpretion. For example, in interpretation I1 , if the policy p maps (Alice, ∅) to (Alice,{{(file1,+read),(file1,+write), (file2+read),(file2,-write)}}), then p is ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

309

consistent for (Alice,∅) with respect to I1 . In contrast, in interpretation I2 , if p maps (Alice,∅) to (Alice,{{(file1,+read), (file1,-read),(file2,-write)}}), then p is inconsistent for (Alice,∅) with respect to I2 . If another interpretation I3 maps (Alice,∅) to (Alice, {{(file1,+read),(file1,-read),(file2,-write)}, {(file1,+read), (file1,+write),(file2+read),(file2,-write)}}), then p is possibly, but not necessarily, consistent with respect to (Alice,∅) in interpretation I3 , as {(file1,+read),(file1,-read),(file2,-write)} is contradictory but {(file1,+read),(file1, +write), (file2+read),(file2,-write)} is not contradictory. The third concept in Definition 10 deals with possible and necessary consistency with respect to an interpretation. If in an interpretation I , a policy p is possibly/necessarily consistent with respect to all authorizations, then it is said to be possibly/necessarily consistent. For example, consider an interpretation I that maps (Alice,∅) to (Alice,{{(file1,+read),(file1,-read),(file2,-write)}, {(file1,+read), (file1,+write), (file2+read),(file2,-write)}}), and (Bob,∅) to (Bob,{{(file1,+read),(file1,+write),(file2+read),(file2,-write)}}). Then p is possibly but not necessarily consistent with respect to I . The fourth concept discussed in Definition 10 is that of consistency of a policy. A policy p is possibly/necessarily consistent if it is consistent with respect to all interpretations. Thus, in any interpretation a possibly consistent policy must map all authorizations to at least one consistent authorization. Similarly, in any interpretation a necessarily consistent policy must map all authorizations to sets of consistent authorizations. For example, consider a policy that removes all negative authorizations from any PermSet that has both positive and negatives. It is commonly referred to as permissions takes precedence policy and symbolized as max in our syntax. The policy max maps any (s,PermSet) to (s,PermSet \{(o,+a): (o,+a), (o,-a) ∈ PermSet}). Thus, max is a necessarily consistent policy. Note that max is independent of interpretations and (s, PermSet) pairs. The reason why we gave this policy a special name is that it behaves like a constant over all possible interpretations. Now we investigate the closure properties of consistent policies. We only consider closure properties of consistent policies because they are independent of interpretations. The utility of consistency properties will be shown shortly. LEMMA 4. operators:

Necessarily consistent policies are closed under the following

(1) External Operators: composition (; ), disjunction (t), conjunction (u), scoping (k), provisioning (::), and difference ( ¯ ). (2) Internal Operators: conjunctions (∩), differences (−), provisioning (|), scoping (:), negation (¬), max, and min. Possibly consistent policies are closed under the following operators: (1) External Operators: composition (; ) and disjunction (t). (2) Internal Operators: conjunctions (∩), differences (−), provisioning (|), scoping (:), negation (¬), max, and min. PROOF.

Follows from the properties of relational compositions. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

310

•


Lemma 4 can be directly applied in deriving consistency results without looking into the details of policy expressions. For example, according to Lemma 4, p t q preserves necessary/possible consistency of p and q. We have shown many examples of obtaining exclusive rights of usage such as read and write locks for files by different subjects. Possible/necessary consistency of p t q implies that any policies with exclusive rights can be safely merged using the external union. As the lemma says, and shown by examples earlier, the same result does not hold for internal unions. In addition, for operators that do not preserve either possible or necessary consistency, the lemma also indicates that consistency may not hold, implying the need to go into the details of how policies in question are interpreted in intended domains of application. 5.3 Completeness Now we address the issue of completeness. In the context of access control, a policy is complete if it either permits or denies all access requests. In policies with positive and negative authorizations, that translates to having (o, +a) or (o, −a) for every object o and action a that is applicable to o. For example, consider a policy p that in an interpretation I maps (Alice,∅) to (Alice,{{(file1,+read),(file1,+write),(file2-read),(file2,-write)}, {(file2,+read), (file2,-write)}}). Now suppose that both read and write apply to objects file1 and file2. Then, in the first alternative p specifies that Alice obtains {(file1,+read),(file1,+write), (file2,-read),(file2,-write)}. That is, she can read and write file file1 but cannot read or write file file2. Thus the first alternative specifies a grant or deny for all possible read/write requests on all files. The second alternative is quite different, in the sense that it allows Alice to read file1 and prohibits her from writing file2, but states nothing about writing file1 or reading file2. Thus we say that the second alternative is incomplete. Using other examples, it is possible to list policies that are complete with respect to some or all alternatives, introducing the distinction between possible and necessary completeness. They are formally introduced in Definition 11. Definition 11 (Completeness). Let p be a policy, I = (M policy , M prop , M setProp ) an interpretation and (s, PermSet) an authorization: (1) Complete Permission Sets: We say that a permission set PermSet is complete if for every object o and every action term a that is applicable to o, either (o,+a) ∈ PermSet or (o,-a) ∈ PermSet. We say that an authorization (s,PermSet) is complete if PermSet is complete. (2) Policies Complete for Authorizations: We say that a policy p is possibly/necessarily complete for an authorization (s,PermSet) with respect to the interpretation I if some/all permission sets PermSet’ satisfying (s,PermSet’) ∈ M policy (St)(p)(s,PermSet) are complete. (3) Policies Complete with respect to an Interpretation: We say that a policy p is possibly/necessarily complete with respect to an interpretation ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

311

I if p is possibly/necessarily complete with respect to I for every authorization. (4) Complete Policy: We say that a policy p is possibly/necessarily complete if it is possibly/necessarily complete with respect to every interpretation I . Now we explain the differences between different flavors of completeness in Definition 11. The first concept, a complete authorization set is one that has one of (o,+a) or (o,-a) for any object o and action a that is applicable to o . Hence in an application domain with object f and two actions read, write that are applicable to f, {(f,+read),(f,-write)} is complete and {(f,+read)} is incomplete. The second concept formalized in Definition 11 is that of possible and necessary completeness of a policy for a given subject with an assigned permission set with respect to and interpretation. As explained in the motivating example before Definition 11, if a policy p in an interpretation I that maps (Alice,∅) to (Alice, {{(file1,+read),(file1,+write),(file2-read),(file2,-write)}, {(file1,+read), (file2,-write)}}), then p is possibly but not necessarily complete with respect to (Alice,∅). This is so because under the interpretation I , p maps (Alice,∅) to (Alice, {{(file1,+read),(file1,+write),(file2-read), (file2, -write)}}). Note that {(file1,+read),(file2,-write)}, and {(file1,+read),(file1, +write),(file2-read),(file2,-write)} are complete permission sets, but {(file1,+read),(file2,-write)} is incomplete. The third concept formalized in Definition 11 is that of possible and necessary completeness of a policy with respect to an interpretation. Suppose that in addition, under the interpretation I , policy p is possibly but not necessarily complete for all other subjects and permission set pairs. In order to ensure that this is the case, we need to ensure that I maps (Alice, PS) for every permission set PS to at least one complete permission set. Then we say that p is possibly but not necessarily complete with respect to I. The fourth concept formalized by Definition 11 is that of possible and necessary completeness of a policy. For example, if we consider all possible interpretations of p, and still find out that p is possibly complete with respect to all of them, then p is possibly complete. The difference between the third and the fourth cases is that the former is with respect to one interpretation and the latter must hold for all interpretations. As in the case of consistency, we wish to know which policy operators preserve possible and necessary completeness of policies. That is answered in Lemma 5. LEMMA 5. operators:

Necessarily complete policies are closed under the following

(1) External Operators: composition (; ), disjunction (t), conjunction (u), scoping (k), provisioning (::), recursion (∗), and difference ( ¯ ). (2) Internal Operators: internal negation (¬), oCom, and cCom. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

312

•


Possibly complete policies are closed under the following operators: (1) External Operators: composition (; ), recursion (∗), and disjunction (t). (2) Internal Operators: negation (¬), oCom, and cCom. PROOF.

Follows from properties of relational compositions.

In comparison with Lemma 4 about consistency, Lemma 5 can also be directly applied in deriving completeness of composed policies without looking into the details of policy expressions. For example, according to Lemma 4, p u q preserves both necessary and possible completeness of p and q. But only p t q preserves possible completeness. That result implies that if p and q are necessarily complete, then necessary completeness of p u q is guaranteed. Thus, all choices allowed by p u q are complete, but may not be so with p t q (recall that our policies allow choices). Hence, to ensure that all choices allowed by p t q are complete in any interpretation, we need to know how p and q map permission sets in that interpretation. 5.4 Comparing Consistency with Completeness As stated, different versions of consistency and completeness are closed under the same external operators. The reason is that both consistency and completeness are ensured on the basis of assigned permission sets and, according to our definitions, external operators do not alter them. On the other hand, internal operators do alter the combination of permission sets and accordingly, they have more restrictive closure properties with respect to consistency and completeness. Although the proofs of Lemmas on determinism, consistency, and completeness (Lemmas 3–5) are simple, they can be used to determine if a given policy is deterministic, consistent, or complete without analyzing their details. For example, deterministic policies are closed under internal disjunction, conjunction, and negation. Similarly, consistent policies are closed under internal disjunction and negation, while complete policies are closed under internal negation. As stated, closure conditions for determinism are supersets of those for consistency which in turn are supersets of closure conditions for completeness. Accordingly, if some policy is constructed by applying internal negation, conjunction, and disjunction to a collection of deterministic, consistent, and complete constituent policies, then the resulting policy is guaranteed to be consistent and complete, but not deterministic. 6. EXAMPLES This section shows two examples taken from other frameworks that can be modeled using our policy composition algebra. We do so by taking an example from each of these frameworks. Our objective here is not only to show that some sample policies can be modeled using our policy algebra, but also to show how many policies used in practice are compositions of other policies. The point here is that many frameworks and specification models use policy compositions implicitly, but our algebra can be used to make them explicit. The first example ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

313

is taken from the Flexible Authorization Framework (FAF) [Jajodia et al. 2001, 2002], and the second example is taken from role-based access control (RBAC). 6.1 An Example from FAF Described in detail in a number of papers [Jajodia et al. 2002; Jajodia et al. 1997a,b], FAF is a logic-based framework for specifying authorizations in the form of rules. It is based on four categories of policies that are applied one after the other. We show how these policies can be modeled as sequential compositions in our algebra. In FAF, an authorization specification is a locally stratified logic program. It has four categories of rules: propagation, decision, conflict resolution, and integrity rules. A FAF specification is a sequential composition of these rules. To show policy compositions implicit in FAF, we use the following running example:  in(John, Mgr, ASH) ←     in(Mary, Mgr, ASH) ←     in(Bob, Sales, ASH) ←     in(Alice, Sales, ASH) ←     in(Mgr, Emp, ASH) ←    Propagation in(Sales, Mgr, ASH) ← in(BMW, Car, AOH) ← Policy     in(SAAB, Car, AOH) ←     in(x, z, ASH) ← in(x, y, ASH), in(y, z, ASH)     cando(s, o, +Sell) ← in(o, Car, AOH), in(s, Emp, ASH)     cando(s, o, +OK) ← in(o, Car, AOH), in(s, Mgr, ASH)    dercando(s, o, a) ← cando(s, o, a) ½ Decision Policy

do(s, o, a) ← dercando(s, o, a) do(s, o, −a) ← ¬do(s, o, +a)

½ Conflict Resolution Policy

Not specified, because there are no conflicts to resolve

© Integrity Policy error ← (s, o, +Sell), (s, o, +OK) Because our algebra transforms permission sets into permission sets, translating a FAF specification to our algebra is not straightforward. Therefore, for each type of specification, we take the rules as they are specified in FAF and translate them as transformers of permission sets. At each stage, we take the input permission set as the output of the previous stage and apply the set of rules corresponding to the current stage to compute the output permission set. Therefore, the first policy, namely propagation, has an empty permission set for every subject. We will make this process clear in the subsequent description. The first 12 rules specify the propagation policy in FAF. The policy specifies the subject and object hierarchies and describes how accesses propagate ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

314

•

D. Wijesekera and S. Jajodia Table I. Interpretation of the Propagation Policy pprop

Source of M policy (St)(pprop ) (Alice,∅) (Bob,∅) (John,∅) (Mary,∅)

Target of M policy (St)(pprop ) (Alice,{{(BMW,+sell),(SAAB,+sell)}}) (Bob,{{(BMW,+sell),(SAAB,+sell)}}) (John,{{(BMW,+sell),(SAAB,+sell),(BMW,+OK),(SAAB,+OK)}}) (John,{{(BMW,+sell),(SAAB,+sell), (BMW,+OK),(SAAB,+OK)}})

Table II. Interpretation of the Decision Policy pdes Source of M policy (pdes ) (Alice,{{(BMW,+sell),(SAAB,+sell)}}) (Bob,{{(BMW,+sell),(SAAB,+sell)}}) (John,{{(BMW,+sell),(SAAB,+sell), (BMW,+OK),(SAAB,+OK)}}) (Mary,{{(BMW,+sell),(SAAB,+sell), (BMW,+OK),(SAAB,+OK)}})

Target of M policy (pdes ) (Alice,{{(BMW,+sell),(SAAB,+sell), (BMW,-OK),(SAAB,-OK)}}) (Bob,{{(BMW,+sell),(SAAB,+sell), (BMW,-OK),(SAAB,-OK)}}) (John,{{(BMW,+sell),(SAAB,+sell) (BMW,+OK),(SAAB,+OK)}}) (Mary,{{(BMW,+sell),(SAAB,+sell) (BMW,+OK),(SAAB,+OK)}})

along these hierarchies. The predicate in(x, y, hierarchy name) is used to specify properties of subject and object hierarchies. Here, AOH and ASH denote authorization object and authorization subject hierarchies, respectively. The authorization subject hierarchy ASH consists of two roles, Manager (abbreviated as Mgr) and Salesperson (abbreviated as Sales). The salesperson role is junior to the manager role, which is encoded as the rule in(Sales,Mgr,ASH) ←. We assume that there are four employees: Alice and Bob as salespersons and John and Mary as managers. The first four rules of the propagation policy state these facts. We have two objects, BMW and SAAB, and selling (abbreviated Sell) and approving the sale of these objects (abbreviated OK) are two actions. The two rules with cando at their heads specify that all employees are allowed to sell cars and only managers are allowed to approve such sales. The dercando rule is used to define recursive closures. Assuming that Alice, Bob, John, or Mary did not have any prior permissions, Table I shows the source and target of our modeling of the propagation policy, which we name pprop . Conflict resolution policies in FAF remove inconsistencies derivable using rules specified in the propagation policy. Being able to derive cando(s, o, +a) and cando(s, o, −a) is considered a conflict in FAF. Because there is no need for conflict resolution in our example, there are no rules corresponding to specifying conflict resolution. Therefore, in our algebra, the conflict resolution policy pconRes is the identity mapping in the sense that it maps every authorization (i.e., (subject,PermSet)) to itself. We call this pconRes . Decision policies in FAF ensure the completeness of authorizations. Namely, every authorization request is either granted or denied. In FAF, rules with (subject,object,action) heads specify decision policies. In our example, these are rules 13 and 14, and they specify the closed policy that we refer to as pdes . Interpretation of pdes is shown in Table II. FAF states its integrity constraints using rules with an error head. The intended meaning in FAF is that such rules should not be satisfied. Hence, ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

315

Table III. Interpretation of the Integrity Constraint Enforcement Policy pinte g Source of M policy (pinteg ) Target of M policy (pinteg ) (John,{{(BMW,+sell),(SAAB,+sell), (John,{{(BMW,+sell),(SAAB,+sell)(BMW,-OK),(SAAB,-OK)}, (BMW,+OK),(SAAB,+OK)}}) {(BMW,+sell),(SAAB,-sell),(BMW,-OK),(SAAB,+OK)}, {(BMW,-sell),(SAAB,+sell),(BMW,+OK),(SAAB,-OK)}, {(BMW,-sell),(SAAB,-sell),(BMW,+OK),(SAAB,+OK)}}) (Mary,{{(BMW,+sell),(SAAB,+sell), (Mary, {{(BMW,+sell),(SAAB,+sell)(BMW,-OK),(SAAB,-OK)}, (BMW,+OK),(SAAB,+OK)}}) {(BMW,+sell),(SAAB,-sell),(BMW,-OK),(SAAB,+OK)}, {(BMW,-sell),(SAAB,+sell),(BMW,+OK),(SAAB,-OK)}, {(BMW,-sell),(SAAB,-sell),(BMW,+OK),(SAAB,+OK)}}) (Alice,{{(BMW,+sell),(SAAB,+sell), (Alice,{{(BMW,+sell),(SAAB,+sell), (BMW,-OK),(SAAB,-OK)}}) (BMW,-OK),(SAAB,-OK)}}) (Bob,{{(BMW,+sell),(SAAB,+sell), (Bob,{{(BMW,+sell),(SAAB,+sell), (BMW,-OK),(SAAB,-OK)}}) (BMW,-OK),(SAAB,-OK)}}) Table IV. Interpretation of the Composed Policy pprop ; psctconRes ; pdes ; pinteg = pcar Source of M policy (pcar ) (John,∅),

(Mary,∅)

(Alice,∅) (Bob,∅)

Target of M policy (pcar ) (John,{{(BMW,+sell),(SAAB,+sell)(BMW,-OK),(SAAB,-OK)}, {(BMW,+sell),(SAAB,-sell),(BMW,-OK),(SAAB,+OK)}, {(BMW,-sell),(SAAB,+sell),(BMW,+OK),(SAAB,-OK)}, {(BMW,-sell),(SAAB,-sell),(BMW,+OK),(SAAB,+OK)}}) (Mary,{{(BMW,+sell),(SAAB,+sell)(BMW,-OK),(SAAB,-OK)}, {(BMW,+sell),(SAAB,-sell),(BMW,-OK),(SAAB,+OK)}, {(BMW,-sell),(SAAB,+sell),(BMW,+OK),(SAAB,-OK)}, {(BMW,-sell),(SAAB,-sell),(BMW,+OK),(SAAB,+OK)}}) (Alice,{{(BMW,+sell),(SAAB,+sell),(BMW,-OK),(SAAB,-OK)}}) (Bob,{{(BMW,+sell),(SAAB,+sell),(BMW,-OK),(SAAB,-OK)}})

FAF only states integrity constraints in its policy but does not resolve them. In our example, John, Mary, Bob, and Alice are permitted to sell both cars, namely, the BMW and the SAAB. In addition, John and Mary can authorize any of these sales. As specified in the last rule, the same car cannot be sold and approved by the same person. Hence, the intended integrity constraints can be enforced with a policy pinteg interpreted as given in Table III. Note that the integrity resolution policy is nondeterministic, in the sense that it derives more than one alternative for John and Mary. Policy pinteg is nondeterministic for (Alice,PermSet) and (Bob,PermSet) in our interpretation where PermSet is {(BMW,+sell), (SAAB,+sell)}. Second, FAF specification of the Car agencies policy is a composition pprop ; psctconRes ; pdes ; pinteg . This composition is given in Table IV. This example highlights two points. First, the different flavors of nondeterminism we defined are used in practice. Second, there are access control policy specification frameworks that use policy compositions. 6.2 An Example Using Set Predicates In this example, we show how separation of duty (SOD) principle, commonly referred to as operational SOD, can be modeled in our framework. Gligor et al. [1998] defines operational SOD as any subject with any active roles from a ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

316

•


given set of roles (say RS), may not perform all operations from a given set of operations (say OS). Thus, the constraint in operational SOD applies to a set of permissions. Accordingly, in our formulation, operational SOD requires that the range of any mapping of a policy must satisfy the condition that whenever the subject is assigned a role from a set of roles RS, then every role from RS must have at least one negative permission assigned to an operation from OS. Consider the example of Alice, playing the role of a program tester. The tester’s role is allowed to create, execute, and destroy myFile.exe. Suppose that in addition, operational SOD specifies that no subject can have more than two permissions in the set {create, execute, destroy}. Therefore, the principle of operational SOD, taken as a policy (say p), is interpreted as a mapping with the source (Alice, {{(myFile.exe,+create), (myFile.exe,+execute), (myFile.exe,+destroy)}}). Its target includes subsets with two out of three positive permissions out of {(myFile.exe,+create), (myFile.exe,+execute), (myFile.exe,+destroy)}. There are three such subsets, resulting in the following target for the interpretation of p: (Alice, {{(myFile.exe,+create), (myFile.exe,+execute), (myFile.exe,-destroy)}, {(myFile.exe,+create), (myFile.exe,-execute), (myFile.exe,+destroy)}, {(myFile.exe,-create), (myFile.exe,+execute), (myFile.exe,+destroy)}}) This example show the need for set predicates in role-based access control. 7. COMPARISONS 7.1 Comparison with the Work of McLean McLean suggested using the notion of algebraic (set theoretic) constructs for composition of access control and information flow policies [McLean 1994, 1996, 1998]. He referred to nondeterminism as possibilistic semantics and sequence operators as cascading operators. Most of his work focuses on multilevel security (MLS). In this paper, we are concerned with discretionary access control policies and consequently do not address notions such as noninference and noninterference. 7.2 Comparison with Bonatti et al. and Wijesekera and Jajodia The fundamental difference between the work of Bonatti et al. [2000] and ours is that they formulate an access control policy as a set of ground terms over an alphabet for (subject, object, action) terms, whereas we model policies as nondeterministic transformers (relations) over a collection of subjects, objects, and action terms. Thus, Bonatti et al. [2000] takes a set-based approach influenced by logic programming, whereas we take a state-transformation-based approach. Further, Bonatti et al. [2000] use Horn clause rules to derive consequences of policies, and the algebra of policies is captured by having a collection of operators such as union, intersection, closure under rules, scoping restrictions over policies, etc. In addition, Bonatti et al. [2000] use policy variables for yet-to-be-specified policies in policy expressions that can be replaced by a ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

317

collection of (subject, object, action) triples supplied by an environment. We do not have such policy templates. Our policies are relations, as opposed to being functions, because we wanted to model nondeterministic policies. Consequently, there is a difference between our policy operators and those available in Bonatti et al. [2000]. All operators allowed in Bonatti et al. [2000] (such as addition, conjunction, and subtraction) operate on ground authorization terms, whereas ours operate on relations that map ground authorization terms to a collection of them. In our model, sequencing is a first class operator; that is, if p1 and p2 are policies, then ( p1 ; p2 ) and ( p2 ; p1 ) are policies and they may not result in permitting the same accesses. Because policies are modeled as a set of ground authorization terms and set operations of union, intersection, difference, and closure under a collection of rules, sequential applications of policies cannot be directly modeled as a first class operation in Bonatti et al. [2000]. However, there are examples provided in Bonatti et al. [2000] that show how the net effect of sequencing (such as in the denials takes precedence policy) can be modeled by analyzing the semantics of the components. The modular approach of Bonatti et al. [2000] does not explicitly support negative authorizations. Nevertheless, they show how to model hybrid policy such as the denials take precedence policy as p+ − p− , where p+ and p− contain positive and negative authorization terms, respectively. The difficulty, however, is that if authorization terms are not signed, then in order to define p+ and p− one needs to know the nature and the form of rules (or any other internal mechanism), which arguably violates the abstractness of policy operators. We are especially concerned about how this step would be carried out when unknown policies are added in as variables. As stated in Section 1, this paper is an extension of Wijesekera and Jajodia [2001], which in turn is an extension of the composition framework of Bonatti et al. [2000]. The primary additions are the introduction of external operators and infinitary operators. Because of the introduction of external operators and nondeterminism, flavors of consistency and completeness have been extended to include possible and necessary consistency and completeness. The issue here is that both consistency and completeness are local properties of the permission sets granted by a policy, but nondeterministic policies have the liberty to make none, some, or all possible alternatives become consistent or complete. In our terminology (as in the case of the same terminology in Modal Logic and concurrency literature), not possible, possible, and necessary cover all cases. In addition, all forms of conditionals have been grouped as either propositions about individuals or propositions about sets. 7.3 Modeling Sets of Accesses versus Individual Accesses Our semantics transform sets of accesses for each subject object pair to another set of accesses and, furthermore, this transformation can associate one access set in the domain to multiple sets of accesses in the range of a policy. This allows us to model SOD types of policies clearly by mapping a given set of accesses to all allowable combinations of accesses. Neither the flexible framework of Jajodia ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

318

•


et al. [2002] nor the modular approach of Bonatti et al. [2000] capture them. The main reason for this is that they both lack set-based rules. It is possible to model them in Jajodia et al. [2002] provided that all requests are serialized, but this limitation has been removed from our framework. Simon and Zurko [1997] and Gilgor et al. [1998] discuss SOD policies and their compositions. The former presents a categorization of SOD policies such as static, static-strict, dynamic, and object based SOD, etc. The latter formalizes them with respect to system states and state transitions. In this formalization, every SOD principle is written as a first-order sentence over sets of objects, subjects, roles, membership relations over these categories, and sets of operations permitted in roles. They use the notation pi (Rol eSeti , Appi ) as a definition for a particular SOD principle. For example SSOD(RoleSet, App) is satisfied at any state ρ if ∀r1 , r2 ∈ RoleSetr1 6= r2 → rol e set(r1 ) ∩ rol e set(r2 ) 6= ∅. [Gilgor et al. 1998] uses the notation p1 (Rol eSet, App) to denote the set {ρ ∈ STATES : ρ |= p1 (RoleSet, App)}. By means of these characterizations, they show that some SOD principles imply others. Further, they derive sufficient conditions for p1 and p2 to be composable as SOD principles. Although our policy compositions were not designed to explicitly model SOD-preserving compositions, it is sufficient to model static SOD policies and investigate SOD-preserving state transformations. Nevertheless, this work shows the utility of modeling sets of accesses, as opposed to modeling accesses. 7.4 Other Logic-Based Models Bai and Varadarajan [1997] present another logic-based model for access control policies. They model a given state of a security policy as a collection (C, M ), where C is a finite set of first-order formulas over language consisting of ground atoms and M is a Herbrand interpretation. They view C as the nonchangeable part of the policy and M as changeable facts. Their definition of transformation, syntactically given as [Pre(tran) | P ost(tran)], where Pre(tran){h1 , . . . , hm }, and P ost(tran){l 1 , . . . , l n }, intuitively means that if the facts h1 , . . . , hm held before the state transformation, then the transformation would be eligible to be applied and that the postconditions l 1 , . . . , l n must hold afterwards. Because this work uses the closed-world assumption, each such transformation can have multiple states satisfying the postcondition and the invariant part. They suggest some priority-based methods to choose one among such competing states. Although our work is not based on the closed-world assumption and we do not derive states from postconditions, we can model these state transformations followed by choosing the appropriate end state as a composition of two policies: ptrans f orm ; pchoose . The two pertinent points are that nondeterministic choice is relevant, as shown in the work of Bai and Varadarajan [1997], and our framework is able to capture it. Furthermore, by decomposing the transformation with the priority-based choice for the end state, we can investigate the consequences of and alternatives to resolving the nondeterminacy. 7.5 Automata-Based Models We compare our work with automata-based models of security policies because our framework uses a notion of nondeterminism that has its origins in ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

319

nondeterministic automatons. Although there are many access control-related works based on automatons, we compare our work with Schneider [1998]. This work formulates policies related to access control, information flow, and resource availability as automatons. An enforceable security policy is defined as a safety property and, drawing upon earlier work [Alpern and Schneider 1985; Alpern and Schneider 1987], it is shown how these can be enforced by reference monitors. This work shows how to reverse engineer an access control matrix-based security enforcement mechanism as an automaton, and argues that by composing automatons, one could be composing policies, independent of their implementation mechanisms, and this is the view taken by our policy composition framework. We further argue that some of our algebraic properties can be used to derive the equivalences among such reverse engineered security policies. 8. CONCLUSIONS We presented a propositional algebra to model policy operators such as union, intersection, sequential composition, recursive closure under rules, adding provisions, etc., used in composing security policies for access control. In recognition of the fact that authorization policies can be nondeterministic (possibilistic in the sense of McLean [1998]) and they can assign sets of permissions to subjects, we have identified two types of operations. The first type, referred to as external, only quantifies over permission sets without reorganizing them. The second type, internal operators, alters these sets. Our choice of assigning sets of permissions allows us to model SOD principles that authorize access sets in an all-or-nothing manner. Because some assignments of permission sets are conditional, we need propositions to model these conditions. As properties of individuals have a different logical standing (i.e., first order vs. higher order) from those of permission sets, we have introduced two types of propositions to model scoping and provisions. One use of policy models is that they can be used to determine if two policy compositions are semantically equivalent (i.e., result in granting or denying exactly the same accesses). To this end, we developed some algebraic identities that can be used to determine equivalent policies. A second way policy models can be used is to determine if composite policies are complete, consistent, or deterministic, given that the components satisfy all, some, or none of these properties. We have categorized the operators that preserve determinacy, consistency, and completeness, and shown how they can be used. The work reported here is being improved in many ways. We are developing a predicate version in which properties are not left as abstract symbols, but are created from relation, function, variable, and constant symbols over subjects, objects, and accesses. Doing so will enable us to reason more about the restriction operator (|) and the provisioning operator (:). Note that having a richer language for restrictions and provisions would adversely affect the computability of the algebra, and we want to strike a balance between them so that we have reasonable expressibility at an affordable cost of complexity. This is especially relevant, given that some conditionals may require quantification over sets. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

320

•


The second improvement is in the area of the basic automata model. Although our framework can model a single (subject, permission set) pair being given a nondeterministic choice in selecting between two sets of access permissions, it cannot model the following types of access permissions. Say a policy wants to assign (s1 , o1 ) the permission set A and (s2 , o2 ) the permission set B simultaneously, or none at all. If we extend set-based nondeterministic automatons to and-or computation trees, as they were advocated in Chandra et al. [1981], we can model such requests. The advantage of this addition is that we can not only model sets of permissions, but also specify which combinations of them are valid. APPENDIX: PROOFS OF THEOREMS PROOF OF THEOREM 1. In order to prove that (P O L, t, u, Á , 1pol , 0pol ) forms a Boolean algebra, we need to prove the following facts: (1) t and u are associative, and they are distributive over each other. These are true as each of them reduce to the corresponding property of the second (permission set) component of (s,PermSet) with respect to union and intersection for sets. (2) For any policy p and any interpretation I , M policy (St)(p t 0pol ) = M policy (St)(p), and M policy (St)(p u 1pol ) = M policy (St)(p). To see why the former is true, consider (s, PermSet) ∈ M policy (St)(p t 0pol ) (s, PermSet 0 ). Then (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ), as by definition (s, PermSet) 6∈ M policy (St)(0pol )(s, PermSet 0 ). Conversely, if (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ), then (s, PermSet) ∈ M policy (St)(p t 0pol )(s, PermSet 0 ) by definition. To see why 1pol has the required property, consider (s, PermSet) ∈ M policy (St)(p u 1pol )(s, PermSet 0 ). As PermSet ∈ P S, (s, PermSet) ∈ M policy (St) (1pol )(s, PermSet 0 ). Conversely, if (s, PermSet) ∈ M policy (St)(p u 1pol ) (s, PermSet 0 ), then (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ). (3) For any policy p and any interpretation I , M policy (St)(p t Á p) = M policy (St)(1pol ), and M policy (St)(p u Á p) = M policy (St)(0pol ). To see why the first claim is true, consider any (s, PermSet) ∈ M policy (St)(p t Á p)(s, PermSet 0 ). Then either (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ) or (s, PermSet) ∈ M policy (St)(Á p)(s, PermSet 0 ). In both cases, (s, PermSet) ∈ M policy (St)(1pol )(s, PermSet 0 ). Conversely, suppose (s, PermSet) ∈ M policy (St)(1pol )(s, PermSet 0 ). Then either (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ), or else by definition of M policy (St)(Á p), (s, PermSet) ∈ M policy (St)(Á p)(s, PermSet 0 ) To see why the second claim is true, consider any (s, PermSet) ∈ M policy (St)(p u Á p)(s, PermSet 0 ). Then by definition of M policy (St)(Á p), either (s, PermSet) ∈ M policy (St)(Á p)(s, PermSet 0 ) or (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ), but not both. Hence, it cannot be the case that (s, PermSet) ∈ M policy (St)(p u Á p)(s, PermSet 0 ) for any (s, PermSet 0 ). These properties show that (P O L, t, u, Á , 1pol , 0pol ) is a Boolean algebra. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

321

PROOF OF THEOREM 2. Suppose I = (M policy (St), M prop , M setProp ) is an interpretation and (s, PremSet), (s, PremSet’) are authorization pairs. (1) On distributivity of composition over unions and intersections, as we prove the first and third claims, as others are similar. (a) To prove M policy (St)(p1 t p2 ); p3 ) = M policy (St)(p1 ; p2 ) t (p1 ; p3 ): Suppose (s, PermSet) ∈ M policy (St)(p1 t p2 ); p3 )(s, PermSet 0 ). Then there is an authorization pair (s, PermSet00 ) satisfying (s, PermSet) ∈ M policy (St)(p3 ) (s, PermSet00 ) and (s, PermSet00 ) ∈ M policy (St) (p1 t p2 ) (s, PermSet 0 ). From the definition of t, either (s, PermSet00 ) ∈ M policy (St)(p1 )(s, PermSet 0 ) or (s, PermSet00 ) ∈ M policy (St)(p2 )(s, PermSet 0 ). Either case (s, PermSet) ∈ M policy (St)((p1 ; p3 ) t (p2 ; p3 ))(s, PermSet 0 ), as (s, PermSet) ∈ M policy (St)(p1 ; p3 )(s, PermSet 0 ) in the former case and (s, PermSet) ∈ M policy (St)(p2 ; p3 )(s, PermSet 0 ) in the latter case. This argument can be reversed to prove the converse. (b) To prove that M policy (St)(p1 ; (p2 u p3 )) ⊆ M policy (St)((p1 ; p2 ) u (p1 ; p3 )): Suppose (s, PermSet) ∈ M policy (St)(p1 ; (p2 u p2 ))(s, PermSet 0 ). Then there is an authorization pair (s, PermSet00 ) satisfying (s, PermSet) ∈ M policy (St)(p2 u p2 ) (s, PermSet00 ) and (s, PermSet00 ) ∈ M policy (St) (p1 )(s, PermSet 0 ). From the definition of u, (s, PermSet00 ) ∈ M policy (St)(p2 )(s, PermSet 0 ) and (s, PermSet00 ) ∈ M policy (St)(p3 )(s, PermSet 0 ). Thus, (s, PermSet) ∈ ∈ M policy (St)((p1 ; p2 ) u (p1 ; p3 ))(s, PermSet 0 ), as (s, PermSet) M policy (St)(p1 ; p2 )(s, PermSet 0 ) and (s, PermSet) ∈ M policy (St)(p1 ; p3 ) (s, PermSet 0 ). This argument cannot be reversed to prove the converse. Similar proofs can be given for (p1 u p2 ); p3 ⊆ (p1 ; p2 ) u (p1 ; p3 ) and p1 ; (p2 t p2 ) = (p1 ; p2 ) t (p1 ; p3 ). (2) On properties of the external scoping operator, we prove the first, second, and fifth: (a) To prove 8 :: (9 :: p) = (8 ∧ 9) :: p: Suppose that (s, PermSet) ∈ M policy (St)(8 :: (9 :: p))(s, PermSet 0 ). Then (s, PermSet 0 ) ∈ M setProp (8) and (s, PermSet) ∈ M policy (St)(9 :: p) (s, PermSet 0 ), and therefore (s, PermSet 0 ) ∈ M setProp (9) and (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ). Hence, (s, PermSet 0 ) ∈ M setProp (8 ∧ 9), and consequently (s, PermSet) ∈ M policy (St)((8 ∧ 9) :: p))(s, PermSet 0 ). This argument can be reversed to derive the converse. (b) To prove 8 :: (p1 t p2 ) = (8 :: p1 ) t (8 :: p2 ): Suppose (s, PermSet) ∈ M policy (St)(8 :: (p1 t p2 ))(s, PermSet 0 ). Then (s, PermSet 0 ) ∈ M setProp (8), and (s, PermSet) ∈ M policy (St)(p1 t p2 ) (s, PermSet 0 ). Therefore, (s, PermSet) ∈ M policy (St)(p1 )(s, PermSet 0 ) and (s, PermSet) ∈ M policy (St)(p2 )(s, PermSet 0 ). Thus, (s, PermSet) ∈ M policy (St)(8 :: p1 )(s, PermSet 0 ) and (s, PermSet) ∈ M policy (St)(8 :: p2 )(s, PermSet 0 ). Therefore, (s, PermSet) ∈ M policy (St)((8 :: p1 ) t (8 :: p2 ))(s, PermSet 0 ). This argument can be reversed to prove the converse. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

322

•


(c) To prove 8 :: (p1 ¯ p2 ) = (8 :: p1 ) ¯ (8 :: p2 ): Suppose (s, PermSet) ∈ M policy (St)(8 :: (p1 ¯ p2 ))(s, PermSet 0 ). Then, (s, PermSet) ∈ M policy (St)(p1 ¯ p2 )(s, PermSet 0 ) and (s, PermSet 0 ) ∈ M setProp (8). Therefore, (s, PermSet) ∈ M policy (St)(8 :: p1 )(s, PermSet 0 ), but (s, PermSet) 6∈ M policy (St)(8 :: p2 )(s, PermSet 0 ). Hence, (s, PermSet) ∈ M policy (St)((8 :: p1 ) ¯ (8 :: p2 ))(s, PermSet 0 ). Conversely, suppose that (s, PermSet) ∈ M policy (St)((8 :: p1 ) ¯ (8 :: p2 )) (s, PermSet 0 ). Then, (s, PermSet 0 ) ∈ M setProp (8), (s, PermSet) ∈ M policy (St)(p1 )(s, PermSet 0 ), but (s, PermSet) 6∈ M policy (St)(p2 ) (s, PermSet 0 ). Hence, (s, PermSet) ∈ M policy (St)(8 :: (p1 ¯ p2 ))(s, PermSet 0 ). (3) The proofs of properties of the external scoping operator are similar to corresponding properties of the external provisioning operator. PROOF OF THEOREM 3. Due to the repetitive nature of simple set theoretical arguments, we prove properties (1)-(6) only. To do so, assume that I is an interpretation. (1) Inclusion of unions: (a) To prove that p ⊆ ( p ∪ p): Suppose (s, PermSet) ∈ M policy (St)(p)(s, PermSet 0 ). Then (s, PermSet) ∈ M policy (St)(p)(s, PermSet0 ∪ PermSet 0 ), and therefore (s, PermSet) ∈ M policy (St)(p ∪ p)(s, PermSet 0 ). (b) A similar argument holds for p ⊆ ( p ∩ p). (2) To prove the associativity of unions, intersections, and compositions: Suppose (s, PermSet) ∈ M policy (St)((p1 ∪ p2 ) ∪ p3 )(s, PermSet 0 ). Then, PermSet0 = PermSet1 ∪ PermSet2 ∪ PermSet3 , where (s, PermSet) ∈ M policy (St)(pi )(s, PermSet 0 ) for i = 1, 2, 3. Hence, (s, PermSet) ∈ M policy (St) (p1 ∪ (p2 ∪ p3 ))(s, PermSet 0 ). The converse argument is similar. A similar argument holds for the associativity of ∩. The associativity of composition follows from the associativity of relational compositions. (3) Commutativity of unions and intersections: As shown above, this reduces commutativity of unions and intersections for PermSets. (4) Distributivity of unions and intersections: Similarly, this reduces to the distributivity of unions and intersections for PermSets. (5) Right distributivity of composition over unions and intersections: To show that p1 ; ( p2 ∪ p3 ) ⊆ ( p1 ; p2 ) ∪ ( p1 ; p3 ): Suppose (s, PermSet) ∈ M policy (St)(p1 ; (p2 ∪ p3 ))(s, PermSet 0 ). Then, there is a permission set P S such that (s, P S) ∈ M policy (St)(p1 )(s, PermSet 0 ) and (s, PermSet) ∈ M policy (St)(p2 ∪ p3 )(s, P S). Therefore, there are permission sets P S2 and P S3 satisfying PermSet = P S2 ∪ P S3 , (s, P S2 ) ∈ M policy (St)(p2 )(s, P S) and (s, P S3 ) ∈ M policy (St)(p3 )(s, P S). Hence, (s, P Si ) ∈ M policy (St)(p1 ; pi ) (s, PermSet 0 ) for 1 = 2, 3. Hence, (s, P S2 ∪ P S3 ) ∈ ∈ M policy (St)((p1 ; p2 )∪ (p1 ; p3 ))(s, PermSet 0 ). Therefore, (s, PermSet) M policy (St)((p1 ; p2 ) ∪ (p1 ; p3 )) (s, PermSet 0 ). A A similar argument holds for p1 ; ( p2 ∩ p3 ) ⊆ ( p1 ; p2 ) ∩ ( p1 ; p3 ). ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

323

(6) Properties of the difference operator: (a) p1 − (p2 ∪ p3 ) = (p1 − p2 − p3 ). Follows from A1 − (A2 ∪ A3 ) = (A1 − A2 − A3 ) for sets A1 , A2 , A3 . (b) ¬(p1 − p2 ) = (¬p1 ) − (¬p2 ). Suppose (s, PermSet) ∈ M policy (St)(p1 − p − 2)(s, PermSet 0 ). Then PermSet = −(PS1 \ P S2 ) = −PS1 \ −PS2 for some permission sets PS1 , PS2 . Hence, (s, PermSet) ∈ M policy (St)(¬p1 − ¬p − 2) (s, PermSet 0 ). PROOF OF LEMMA 1.

We show some cases:

(1) To prove that if p and q are singular, then p ∪ q is singular: Supppose (S, PS) ∈ M (St)(p ∪ q)(S, PermSet). Then PermSet = P Sp ∪ PSq for some permissions sets PSp and PSq satisfying (S, PS) ∈ M (St)(p)(S, PSp ) and (S, PS) ∈ M (St)(q)(S, PSq ). Then for any PS0 ⊆ PS and PermSet0 ⊆ PermSet, PermSet0 = PS0p ∪ PS0q for some PS0p ⊆ PSp and PS0q ⊆ PSq . Because p and q are singular, (S, PS0 ) ∈ M (St)(p)(S, PS0p ) and (S, PS0 ) ∈ M (St)(q)(S, PS0q ). Thus, (S, PS0 ) ∈ M (St)(p ∪ q)(S, PS0p ∪ PS0q ). Hence, (S, PS0 ) ∈ M (St)(p ∪ q)(S, PermSet 0 ). Now suppose that (S, PS), (S, PS0 ) ∈ M (St)(p ∪ q)(S, PermSet). Then PS = PSp ∪ PSq and PS0 = PS0p ∪ PS0q for some permission sets PSp , PSq , PS0p , PS0q satisfying (S, PSp ), (S, PS0p ) ∈ M (St)(p)(S, PermSet) and (S, PSq ), (S, PS0q ∈ M (St)(q)(S, PermSet). Hence, (S, PS ∪ PS0 ) = (S, (PSp ∪ PS0p ) ∪ (PSq ∪ PS0q )), (S, (PSp ∪ PS0p ) ∈ M (St)(p)(S, PermSet) and (S, (PSq ∪ PS0q ) ∈ M (St) (q)(S, PermSet), proving that p ∪ q is singular. (2) To prove that if p and q are singular, then p u q is singular: Suppose (S, PS) ∈ M (St)(p u q)(S, PermSet), PS0 ⊆ PS and PermSet0 ⊆ PermSet. We need to show that (S, PS0 ) ∈ M (St)(p u q)(S, PermSet 0 ). This follows directly from the definition of u, as (S, PS) ∈ M (St)(p u q)(S, PermSet) iff (S, PS) ∈M (St)(p)(S, PermSet) and (S, PS) ∈ M (St)(q) (S, PermSet). (3) To prove that if p and q are singular, then p; q is singular: Suppose (S, PS) ∈ M (St)(p; q)(S, PermSet), PS0 ⊆ PS and PermSet ⊆ PermSet0 . Because (S, PS) ∈ M (St)(p; q)(S, PermSet), there is a state St 0 and a permission set PSS such that (S, PS) ∈ M (St 0 )(q)(S, PSS) and (S, PSS) ∈ M (St)(p)(S, PermSet). Therefore, for any PSS0 ⊆ PSS, (S, PS0 ) ∈ M (St 0 )(q) (S, PSS0 ) and (S, PSS0 ) ∈ M (St)(p)(S, PermSet 0 ), and hence (S, PS0 ) ∈ M (St) (p; q)(S, PermSet 0 ). The other part, where we need to show that (S, PS0 ) ∈ M (St) (p; q)(S, PermSet) for any PS0 ⊆ PS and (S, PS) ∈ M (St)(p; q)(S, PermSet) can be similarly proved. PROOF OF THEOREM 4. laws to be valid:

This proof requires the following infinitary distributive

M policy (St)(p1 u (t∞ {p ∈ P }) = t∞ M policy (St)(p)(s, PermSet)(p1 u p){p ∈ P } M policy (St)(p1 t (u∞ {p ∈ P }) = u∞ M policy (St)(p)(s, PermSet)(p1 t p){p ∈ P } ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

324

•


The truth of this follows from the distributivity proved in Theorem 1 and the definition of t∞ as stated in Definition 8. REFERENCES ALPERN, B. AND SCHNEIDER, F. B. 1985. Defining liveness. Inf. Process. Lett. 21, 4, 181–185. ALPERN, B. AND SCHNEIDER, F. B. 1987. Recognizing safety and liveness. Distributed Comput. 2, 117–126. APT, K. R. 1997. Verification of Sequential and Concurrent Programs, 2nd ed. In Graduate Texts in Computer Science. Springer-Verlag, New York. BAI, Y. AND VARADARAJAN, V. 1997. A logic for state transformations in authorization policies. In Proceedings of 10th IEEE Computer Security Foundations Workshop. 173–182. BARRINGER, H. 1985. A Survey of Verification Techniques for Parallel Programs /. Lecture Notes in Computer Science, vol. 191. Springer-Verlag, Berlin. BONATTI, P., DI VIMERCATI, S. D. C., AND SAMARATI, P. 2000. A modular approach to composing access control policies. In Proceedings of 7th ACM Conference on Communications and Security. 164–173. CHANDRA, A., KOZEN, D., AND STOCKMEYER, L. 1981. Alternation. J. ACM 28, 1, 114–133. GABBAY, D. M. 1981. Semantical Investigations in Heyting’s Intuitionistic Logic, vol. 148. D. Riedel, London, UK. GILGOR, V. D., GAVRILA, S. I., AND FERRAIOLO, D. 1998. On the formal definition of separation-of-duty policies and their compositions. In IEEE Computer Society Symposium on Research in Security and Privacy. 173–181. GIRARD, J.-Y., LAFONT, Y., AND TAYLOR, P. 1989. Proofs and Types. Number 7 in Cambridge Tracts in Theoretical Computer Science. Cambridge University Press, Cambridge, U.K. GLIGOR, V. D., GRAVRILLA, S. I., AND FERRAIOLO, D. 1998. On the formal definition of seperationof-duty policies and their composition. In Proceedings of the IEEE Symposium on Research in Security and Privacy. (Oakland, CA.), 172–183. HAREL, D. 1979. First Order Dynamic Logic. Lecture Notes in Computer Science, vol. 68. Springer-Verlag, Berlin. JAJODIA, S., BERTINO, E., AND SAMARATI, P. 1999. A flexible authorization mechanism for relational data management. ACM Trans. Inf. Syst. 17, 9, 01–140. JAJODIA, S., KUDO, M., AND SUBRAHMANIAN, V. S. 2001. Provisional authorizations. In Recent Advances in Secure and Private E-Commerce, A. Ghosh, Ed. Kluwer Academic Publishers, Boston. 133–159. JAJODIA, S., SAMARATI, P., SAPINO, M.-L., AND SUBRAHMANIAN, V. S. 2001. Flexible support for multiple access control policies. ACM Trans. Database Syst. 26, 2, 214–260. JAJODIA, S., SAMARATI, P., AND SUBRAHMANIAN, V. S. 1997a. A logical language for expressing authorizations. In Proceedings of IEEE Symposium on Security and Privacy (Oakland, CA), 31– 42. JAJODIA, S., SAMARATI, P., SUBRAHMANIAN, V. S., AND BERTINO, E. 1997b. A unified framework for enforcing multiple access control policies. In Proceedings of ACM SIGMOD International Conference on Management of Data (Tucson, AZ), 474–485. KOZEN, D. C. 1999. Language based security. Tech. Rep. TR- 99-1775, Department of Computer Science, Cornell University. KUDO, M. AND HADA, S. 2000. Xml document security based on provisional authorizations. In Proceedings of the 7th ACM Conference on Computer and Communications Security. 87–96. MANNA, Z. 1970. The correctness of nondeterministic programs, Artificial Intelligence 1, 1–26. MCLEAN, J. 1994. A general theory of composition for trace sets closed under selective interleaving functions. In Proceedings of IEEE Symposium on Security and Privacy (Oakland, CA), 79– 93. MCLEAN, J. 1996. A general theory of composition for a class of ”possibilistic” properties. IEEE Trans. Softw. Eng. 22, 1, 53–67. MCLEAN, J. 1998. Algebra of security. In Proceedings of IEEE Symposium on Security and Privacy (Oakland, CA), 2–7. PELEG, D. 1987. Concurrent dynamic logic. J. ACM 34, 2, 450–479. ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.


•

325

SCHNEIDER, F. B. 1998. Enforceable security policies. Tech. Rep. TR 98-1664, Department of Computer Science, Cornell University. SIMON, R. T. AND ZURKO, M. E. 1997. Separation of duty in role-based environments. In Proceedings of 10th IEEE Computer Security Foundations Workshop. 183–194. WIJESEKERA, D. AND JAJODIA, S. 2001. Policy algebras for access control—the propositional case. In Proceedings of the 8th ACM Conference on Computer and Communications Security. 38–47. Received March 2002; revised November 2002; accepted January 2003

ACM Transactions on Information and System Security, Vol. 6, No. 2, May 2003.

A Propositional Policy Algebra for Access Control - CiteSeerX

A Propositional Policy Algebra for Access Control - CiteSeerX

Suggest Documents

A Propositional Policy Algebra for Access Control - CiteSeerX

Logics of Propositional Control - CiteSeerX

A Flexible Mandatory Access Control Policy for XML ... - CiteSeerX

Ontology-based Access Control Policy Interoperability - CiteSeerX

Policy-based Access Control Framework for Large Networks - CiteSeerX

A Role-Based Access Control Policy Verification ... - CiteSeerX

SPECIFYING DISCRETIONARY ACCESS CONTROL POLICY FOR ...

A Policy-Based Access Control Mechanism for the Corporate ... - acsac

A Policy-Based Access Control Mechanism for the Corporate ... - acsac

A Semantic Policy Framework for Context-Aware Access Control ...

a policy based role framework for access control - Department of ...

a prototype for policy driven control of heterogeneous network access

A Logic of Games and Propositional Control

Access Control Policy Translation and Verification within ... - CiteSeerX

Policy Based Access Management and Handover Control ... - CiteSeerX

Inferring Access-Control Policy Properties via Machine ... - CiteSeerX

Access Policy Sheet for access control in fine-grained XML - CiteSeerX

RDF Metadata for XML Access Control - CiteSeerX

Flow-Control for Multi-Access Systems - CiteSeerX

Access Control Infrastructure for Digital Objects - CiteSeerX

Practical Access Control Management for Outsourced ... - CiteSeerX

Access-Control Language for Multidomain Environments - CiteSeerX

A context-aware access control framework - CiteSeerX

RelBOSS: A Relationship-Aware Access Control ... - CiteSeerX