Specifying and enforcing constraints in dynamic access control policies

2014 Twelfth Annual Conference on Privacy, Security and Trust (PST)

Specifying and enforcing constraints in dynamic access control policies Nada Essaouini∗† , Fr´ed´eric Cuppens∗ , Nora Cuppens-Boulahia∗ and Anas Abou El Kalam† ∗

T´el´ecom Bretagne Email: frederic.cuppens,nora.cuppens,[email protected] http://www.telecom-bretagne.eu † Cadi Ayyad University, ENSA of Marrakesh Email: [email protected]

Abstract—Constraints in access control models are used to organize access privileges in order to avoid fraudulent situations. Ensuring that the constraints are satisfied during the evolution of the system is an important issue. Thus, there is a need to have a formal reasoning language in order to express the constraints policy and to prove that the constraints are always satisfied. In this work, we propose a formal language based on the deontic logic of actions and situation calculus. The proposed language is easy to use to specify various constraints mentioned in the literature. In addition, we formally specify the condition to prove that the system specification is secure with respect to the access control requirements.

I. I NTRODUCTION Constraints are undoubtedly an important aspect of access control models. They can be used to ensure, for instance, the least privilege principle [1]. In access control models based on roles (RBAC, see [2]), two kinds of constraints have been defined: static mutually exclusive roles (SMER) and dynamic mutually exclusive roles (DMER) [3]. The SMER constraint specifies that some roles should not be assigned mutually to the same users, while the DMER constraint specifies that some roles should not be activated simultaneously in the same session. Managing such constraints becomes more complex when a hierarchy of roles is defined and administrative operations like deleting and adding roles are used. In ANSI RBAC standard [3], the permission inheritance is handled as follows. Consider two roles r1 and r2 and suppose that r1 is a senior role of role r2 . The authorized users for r1 are also authorized for r2 and then users will have all r2 permissions (User Inheritance - UI). The authorized users for r1 can use permissions of r2 without being explicitly authorized for this role (Permission Inheritance - PI). The activation of r1 in a session induces activation of r2 and then users can use r2 permissions in this session without being authorized for r2 (Activation Inheritance - AI). As discussed in [4], the use of PI without UI can circumvent the purpose of the use of SMER and DMER constraints. For example one can create a role r3 as a senior role of two roles that are mutually exclusive and assigns user to r3 , then with PI, the user will use the permissions of the two exclusive roles. This is not a violation of the SMER constraint but contradicts the objective of a SMER constraint to enforce the separation of duty requirement. In the same way the permission inheritance

978-1-4799-3503-1/14/$31.00 ©2014 IEEE

contradicts the objective of DMER constraints. Thus, to ensure that the constraints are not violated despite how the system evolves, it is necessary to have a formal logical reasoning language to be able to prove such properties. Furthermore, beyond the fact that there is a need to prove the satisfiability of these constraints, it is more suitable to organize the decisions taken and actions performed in the system to ensure it. In transactional databases for example, to ensure the enforcement of integrity constraints, the classical approach is to verify if after the transaction execution the database is consistent (i.e., does not violate the constraints). If an inconsistency is detected, all operations of the transaction are canceled (rollback). This approach cannot be applied in systems where a rollback is not possible (e.g., operating systems). In this kind of system, it should be ensured that the constraints are met before executing the actions. The approach we propose is to build the precondition axioms of actions so it is proved that the constraints remain ensured after any execution of actions verifying these axioms. In this work, we propose a logical language based on deontic logic of actions and the Situation Calculus [5] to express and enforce policy constraints. We define two kinds of constraints which are referred throughout this paper as non historical (called ahistorical in the following) and historical constraints. We show through examples how these two types of constraints can be used to express SMER and DMER constraints and also periodic temporal constraints by simply extending our language with other temporary settings (Temporal situation calculus [6]). The Situation Calculus allows us to analyze decidability and complexity of several useful problems: •

•

290

Temporal projection problem [7]: asks whether a formula holds after a sequence of actions is performed in the initial situation. This is useful to decide if a given access should be granted or denied by deriving if the permission conditions hold. Planning [8]: given a goal formula, planning consists in finding a sequence of actions so that the goal is satisfied after executing this sequence of actions. This can be used to distribute users privileges to complete a given task in accordance with the specification of the access control

policy. Moreover, in [9], the authors use the regression operator [10], [11], [12] to build action precondition axioms taking into account constraints formulated as a simple state formula. These axioms are calculated so that, if the constraints are satisfied in the initial situation, they will be satisfied in all situations resulting from the execution of actions with respect to these axioms. In this work, we extend their approach to take into account the historical constraints which cannot be expressed as a simple state formula. This paper is organized as follows. In section 2, we present related work. An overview of the situation calculus is given in section 3. In section 4, we define our specification of the constraints. How to derive authorization decisions is detailed in section 5. In section 6, we describe how regression is used to implement constraints written as simple formulas (ahistorical constraints), then we show how the historical constraints can be rewritten as simple formulas to generalize the concept of enforcement of specified constraint policies. In section 7, we extend our model with time parameters to allow the specification of periodic temporal constraints. Section 8 concludes the article and presents future work. II. R ELATED WORK Ahn and Sandhu [13], [14], [15] propose a Role-based constraints specification language when they identify useful role-based authorization constraints such as prohibition and obligation constraints. However, the proposed language is complex to use and it is difficult for an administrator to check if the specified constraints actually reflect the needed safety requirements. Our approach is comparatively simpler to use. In fact, in our model there are just two kinds of constraints easy to grasp. Note that this does not affect the expressiveness of our model that allows us to express several constraints known in the literature as we will show in the rest of this article through various examples. In this paper, we only address authorization constraints but our model can be easily extended with other fluents to express obligations, prohibitions and exemptions. Then obligation and prohibition constraints can be expressed using these fluents and enforced exactly in the same way as authorization constraints. Tidswell and Jaeger propose a graphical access control model implementing administrative controls [16], [17], [18]. In this model, the nodes represent sets of subjects, objects, etc. And the edges represent binary relationships on those sets. The constraints are expressed using a set of operators on graph nodes. The verification of various safety properties is done at run time involving a comparator function. With the construction of precondition axioms of actions using regression, our approach ensures in advance enforcement of constraints. The constraints will always be satisfied for all possible evolutions of the system from an initial situation that respects the constraints to situations resulting from execution of actions in accordance with precondition axioms (executable situations). In the runtime execution of the system, ensuring that the precondition axiom of actions is satisfied amounts to

solve the temporal projection problem which is decidable in polynomial time. In addition our approach allows us to express and enforce periodic temporary constraints which are not handled in other related works. Simpler specification scheme for separation of duty constraints for RBAC model is defined by Crampton in [19], but with this scheme, it is not possible to express for example that a subject is restricted from executing an operation on a particular object twice. This is what we express in the example related to taxing bad check presented in section 6. And more interesting, in this example we also show how we can specify the restrictions of acting on objects during a time interval. III. S ITUATION CALCULUS AN OVERVIEW The situation calculus (McCarthy [5]) is a logical first-order language specifically designed to represent change in dynamic worlds. The basic elements of situation calculus are actions, situations and fluents. Actions bring change in the world and are represented by a first order term. Then we consider a finite set A of actions and it is assumed that every change is caused by an action. Situations are possible histories of the world which are sequences of actions. Fluents describe the properties of the world and are denoted by predicate symbols taking a situation term at last argument. We consider a finite set F of fluents. There is a distinguished binary function symbol do; do(α, σ) denotes the resulting situation from executing action α in the situation s. The constant σ0 is used to denote the initial situation in which no actions have yet occurred. The predicate P oss(α, σ) states that action α is executable in situation σ. The language also includes the binary predicate symbol < which provides ordering on situations. The atom σ < σ 0 means that the action sequence σ 0 can be obtained from the sequence σ by performing one or more actions in σ. The notation σ 0 ≤ σ means that σ < σ 0 ∨ σ = σ 0 . Normally, before performing any action in a current state, there are some sufficient conditions that must be verified in this state at first. These conditions are specified under actions preconditions axioms. The situation calculus provides a simple solution to the so called well known frame problem, ie. the problem of specifying what properties of the world remain unchanged after the execution of an action. In [12], to solve the frame problem, the evolution of every fluent F is represented by a successor state axiom of the form: P oss(a, σ) → [F (~x, do(a, σ)) ↔ γF+ (~x, a, σ) ∨ F (~x, σ) ∧ ¬γF− (~x, a, σ)] where γF+ (~x, a, σ) and γF− (~x, a, σ) indicate the conditions under which if the action a is executed in situation σ, F (~x, do(a, σ)) becomes true and false respectively. Our approach to implement constraints policies is based on the regression concept. The regression of a formula W denoted R[W ] (cf. [10], [11], [12]) is obtained from W by replacing each fluent F (~x, do(a, σ)) mentioned by W by ΦF (~x, a, σ)

291

where the succession state axiom of F is:

IV. ACCESS CONTROL SPECIFICATION

(∀a, σ).P oss(a, σ) → (∀~x).F (~x, do(a, σ)) ↔ ΦF (~x, a, σ) All other atoms of W not of this form remain unchanged. In the following we denote, Axioms = Σ ∪ Ass ∪ Anec ∪ Acls ∪ Aahis ∪ Ahis ∪ Aσ0 where : • Σ is the foundational axiomatic of the situation calculus: – The second order induction axiom: (∀P ).P (σ0 ) ∧ (∀a, σ)[P (σ) → P (do(a, σ))] → (∀σ)P (σ),

In this section, we define the language that we use to specify authorization rules and the specification of constraint policies. Then we show how to specify SMER and DMER constraints as the most well-known constraints in access control policies based on roles (R-BAC, see [2]). A. Specifying authorizations The language we define to specify the access control is based on deontic logic of actions. We consider the modality: Permission. Permissions are specified using dyadic modality P (α|p) where α is an action of A and p is the condition of the permission. The condition is any formula built using fluents of F without situation. P (α|p) means that the action α is permitted when condition p holds. B. Specifying constraints

– The unique names axioms:

In our model, we have two kinds of constraints, ahistorical constraints and historical ones. • An ahistorical constraints: It is a simple formula of the form:

σ0 6= do(a, σ), do(a, σ) = do(a0 , σ 0 ) → a = a0 ∧ σ = σ 0 , – Axioms that define an order relation < on situations:

(∀σ)¬(∃x~1 , ..x~n ) (F1 (x~1 , σ) ∧ F2 (x~2 , σ) ∧ ... ∧ Fn (x~n , σ))

¬σ < σ0 , 0

0

0

σ < do(a, σ ) ↔ P oss(a, σ ) ∧ σ ≤ σ . • •

Ass is a set of successor state axioms. Anec is a set of necessary conditions for P oss action precondition axioms of the form: P oss(a(x1 , ..., xn ), σ) → Πa ,

•

•

where a(x1 , ..., xn ) is an n-ary action prototype, and Πa is a simple state formula whose free variables are among σ, x1 , ..., xn . Acls be the domain closure axiom for actions:

(∀σ, σ 0 ), σ ≤ σ 0 ¬(∃x~1 , ..x~n ) (F1 (x~1 , σ) ∧ ... ∧ Fi (x~i , σ) ∧ Fi+1 (xi+1 ~ , σ 0 ) ∧ ...Fn (x~n , σ 0 ))

(∀a)((∃~x)a = a1 (~x) ∨ ... ∨ (∃~y )a = an (~y )), •

•

This constraint specifies that the fluents F1 , , Fn must not all be true in the same situation. This also means that if, in some situation, some fluents were true and become false before the remaining fluents in the constraint become true, the constraint is not violated. A historical constraint expressed using a formula of the form:

where a1 , ..., an are action prototypes. Aahis is a set of formulas of the form: (∀σ)¬C(σ) where C(σ) is a simple formula with a unique free variable of type situation is σ. This set is referred to the set of ahistorical constraints. Ahis is a set of formulas of the form: (∀σ, σ 0 )σ ≤ σ 0 → ¬(C(σ) ∧ C 0 (σ 0 ))

where C(σ) (resp. C 0 (σ 0 )) is a simple formula with a unique free variable of type situation is σ (resp. σ 0 ). The set Ahis characterizes the set of historical constraints. • Aσ0 is a set of initial situation axioms. Aσ0 is a set of sentences with the property that σ0 is the only term of sort situation mentioned by the fluents of a sentence of Aσ0 . Thus, no fluent of a formula of Aσ0 mentions a variable of sort situation or the function symbol do. We denote Axioms ` p the fact that the sentence p can be derived from the set of axioms Axioms.

Unlike ahistorical constraint, a historical constraint contains two parts. If it happened that the fluents specified in the first part were true in the same situation, the second part of the constraint should never be true in the future. C. Example We show here how to formalize the fragment of the RBAC model related to role assignment and role hierarchy using our language. We then give examples of SMER and DMER constraints. Fluents: • Assign(s, r, σ): Subject s is assigned to role r in σ. • Sub role(r1 , r2 , σ): r1 is a sub-role of role r2 in σ. • Empower(s, r2 , ss, σ): Subject s empowers the role r in the session ss in σ. • DEM R(r2 , r1 , ss, σ): Role r1 is separated from role r2 in the session ss in σ. • SM ER(r1 , r2 , σ): Role r1 is statically separated from role r2 in σ. Actions:

292

Create hierarchy(s, r1 , r2 ) (resp. Revoke hierarchy): Subject s creates (resp. revokes) a hierarchy relation between role r1 and role r2 . • Create assignment(s, s1 , r) (resp. Revoke assignment): Subject s assigns (resp.revokes) subject s1 to role r. • Create SMER(s, r1 , r2 ) (resp. Revoke SMER): Subject s creates (resp.revokes) a SM ER relation between role r1 and role r2 . • Create DMER(s, r1 , r2 , ss), σ)(resp. Revoke DMER): Subject s creates (resp. revokes) a DM ER relation between role r1 and role r2 in the session ss. Succession state axioms: •

such that Sub role(r1 , r3 , σ) and Sub role(r3 , r2 , σ) then Sub role(r1 , r2 , σ). We also assume that a hierarchy between roles r1 and r2 can only be revoked by applying the action of revoking hierarchy between r1 and r2 . Assign(s1 , r1 , do(a, σ)) ↔ (∃s)a = Create assignment(s, s1 , r1 ) ∨ (∃r2 , s)[Assign(s1 , r2 , σ) ∧ a = Create hierarchy(s, r1 , r2 ) ∨ Sub role(r1 , r2 , σ) ∧ a = Create assignment(s, s1 , r2 )] ∨ Assign(s1 , r1 , σ) ∧

SM ER(r1 , r2 , do(a, σ)) ↔

¬(∃s)a = Revoke assignment(s, s1 , r1 )

(∃s)[a = Create SM ER(s, r1 , r2 ) ∨ a = Create SM ER(s, r2 , r1 )] ∨ (∃r3 , s)Sub role(r2 , r3 , σ) ∧ a = (Create SM ER(s, r3 , r1 ) ∨

The role assignment (resp. revocation) can be done by the action Create assignment (resp. Revoke assignment). If a subject is assigned to some role, he is assigned to all its lower roles.

Create SM ER(s, r1 , r3 )) ∨

Empower(s1 , r, ss, do(a, σ)) ↔

Sub role(r1 , r3 , σ) ∧

Assign(s1 , r, σ) ∧

(a = Create SM ER(s, r3 , r2 ) ∨

(∃s)a = Activate role(s, s1 , r, ss) ∨

Create SM ER(s, r2 , r3 )) ∨

(∃r1 )Empower(s1 , r1 , ss, σ) ∧

SM ER(r1 , r3 , σ) ∧

(∃s)a = Create hierarchy(s, r, r1 ) ∨

a = Create hierarchy(s, r2 , r3 ) ∨

(∃r1 )Sub role(r, r1 , σ) ∧ Assign(s1 , r1 , σ) ∧

SM ER(r2 , r3 , σ) ∧

(∃s)a = Activate role(s, s1 , r1 , ss) ∨

a = Create hierarchy(s, r1 , r3 ) ∨

Empower(s1 , r, ss, σ) ∧ ¬(∃s)a = Deactive role(s, s1 , r, ss)

SM ER(r1 , r2 , σ) ∧ ¬(∃s)a = (Revoke SM ER(s, r1 , r2 ) ∨ Revoke SM ER(s, r2 , r1 ). This axiom specifies that a static mutually exclusion roles between r1 and r2 can be created by applying the action Create SM ER(s, r1 , r2 ). And for all situations σ, if SMER(r2 , r1 , σ) then SMER(r1 , r2 , σ). We admit that the action Revoke SMER is the unique action that turns the fluent SMER from true to false. Furthermore in all situation σ, we assume if there exists role r3 such that SM ER(r1 , r3 , σ) and Sub role(r2 , r3 , σ) then SM ER(r1 , r2 , σ). The succession state axiom of the fluent DM ER is the same like SM ER. Sub role(r1 , r2 , do(a, σ)) ↔

This axiom specifies that when the action Activate role(s, s1 , r, ss) is executed, the subject s1 empowers the role r in the session ss if r is assigned to him. He empowers also all the roles that are lower than the role r. The unique action that turns the fluent Empower(s1 , r, ss, σ) from true to false is the action Deactive role(s, s1 , r, ss). Examples of necessary conditions for Poss: P oss(Create hierarchy(s, r1 , r2 ), σ) → T rue P oss(Revoke hierarchy(s, r1 , r2 ), σ) → Sub role(r1 , r2 , σ) Examples of ahistorical constraints:

(∃s)a = Create hierarchy(s, r1 , r2 ) ∨

¬(SM ER(r1 , r2 , σ) ∧ Assign(s1 , r1 , σ) ∧

(∃r3 , s)[Sub role(r1 , r3 , σ) ∧ a = Create hierarchy(s, r3 , r2 ) ∨ Sub role(r3 , r2 , σ) ∧ a = Create hierarchy(s, r1 , r3 )] ∨ Sub role(r1 , r2 , σ) ∧ ¬(∃s)a = Revoke hierarchy(s, r1 , r2 ). When the action of creating hierarchy between two roles r1 and r2 is executed, the role r1 is then a sub-role of role r2 . We assume for any situation σ, if there exists role r3

(C1)

Assign(s1 , r2 , σ)) ¬SM ER(r, r, σ) ¬Sub role(r, r, σ)

(C2) (C3)

¬DM ER(r, r, ss, σ)

(C4)

The constraint C1 specifies that two roles r1 and r2 cannot be simultaneously assigned to a user. Note that with the assignment revocation concept, if some subject s is assigned to the role r1 and is revoked before that the role r2 is assigned to him, the SM ER is logically not violated as the roles r1

293

and r2 are not assigned to the subject s at the same time. Example of historical constraints: ¬(Empower(s, r1 , ss, σ) ∧

(C5)

0

Then the following action precondition axiom is obtained by predicate completion ([20]) of P oss: ^ P oss(a(x1 , ..., xn ), σ) ↔ Πa ∧ RegC

0

Empower(s, r2 , ss, σ ) ∧ DM ER(r1 , r2 , ss, σ )) The constraint C5 specifies roles r1 and r2 cannot be activated in the same session, although these roles may be assigned to the same user. V. AUTHORIZATION DECISION The objective of this section is to decide if a given access should be granted or denied. For this purpose, we extend the situation calculus with fluents P erm(α) (there is an actual permission to do α), F orb(α) (there is an actual prohibition to do α) where α is an action of A. We also assume that the access control policy is fixed in the initial situation σ0 . This means that we do not consider actions that would change (create, delete, update) the specified permissions and prohibitions that define the access control policy. We first extend the set of Axioms previously defined with a permission definition axiom for every fluent predicate P erm(α), α ∈ A. For this purpose, let Pα be the set of conditional permissions having the form P (α|p). We denote ψPα = p1 ∨ ... ∨ pn where each pi for i ∈ [1, ..., n] corresponds to the condition of a permission in Pα . If Pα = ∅, then we assume that ψPα = f alse. Using ψPα , the permission definition axiom of fluent predicate P erm(α) is defined as follows: ∀σ, P erm(α, σ) ↔ ψPα (σ) It is easy to show that the permission definition axiom is equivalent to the following initial situation axiom and successor state axiom for P erm(α, σ):

where the big conjunction ranges over the ahistorical constraints in Aahis . Let Apre the set of action precondition axioms thus obtained. For every simple constraint C(σ) in Aahis , it is proved that: Σ ∪ Auna ∪ Ass ∪ Apre ∪ Acls ` C(σ0 ) → (∀σ).σ0 ≤ σ → C(σ). To generalize this concept to the historical constraints, the idea is to rewrite them in the simple form. This is what we present in the following. B. Rewrite historical constraints in the form of simple state constraint The formulas contained in Ahis are in the following form: (∀σ, σ 0 )σ ≤ σ 0 → ¬(C(σ) ∧ C 0 (σ 0 )) where C(σ) (resp. C(σ 0 )) is a simple formula with a unique free variable σ (resp. σ 0 ). C(σ) will be mentioned in the following as the first part of the historical constraint. For each fluent F contained in C(σ), we associate the backup fluent Fbackup meaning there exists a situation where the fluent F was true, the fluent Fbackup becomes true when the associated fluent F becomes true and it will never be false, so we can build the succession state axiom for every fluent Fbackup from the succession state axiom of F by eliminating the part that specifies when the fluent F becomes false. Thus the succession state axiom of the fluent Fbackup is defined as follows: P oss(a, σ) → [Fbackup (~x, do(a, σ)) ↔

P erm(α, σ0 ) ↔ ψPα (σ0 )

γF+ (~x, a, σ) ∨ Fbackup (~x, σ)]

∀a∀σ, P erm(α, do(a, σ)) ↔ γψ+P (σ) ∨ P erm(α, σ) ∧ ¬γψ−P (σ) α

α

VI. E NFORCING CONSTRAINTS The idea to implement constraint policies is, for each action, build the preconditions that must be satisfied so that the constraints are not violated when this action is executed. In [9], the authors use the regression concept to generate a set of action precondition axioms, one for each action prototype using state constraint formulas which are of the form: (∀σ)C(σ), where C(σ) is a simple formula where the unique free variable of type situation is σ. The historical constraints in our model are in the form of state constraints. In this section, we show how this approach can be applied to enforce them. Then we extend it to implement historical constraints which are not simple formulas. A. Enforcing ahistorical constraints For each constraint C in Aahis , there is an associated simple state formula RegC such that: Auna ∪ Aahis ` (∀x1 , ..., xn , σ). R[C(do(A(x1 , ..., xn ), σ))] ↔ RegC

where γF+ (~x, a, σ) indicates the conditions under which the fluent F (~x, do(a, σ)) becomes true if the action a is executed in situation σ. Let Cbuckup (σ) be the formula obtained from C(σ) by replacing each fluent in C(σ) by his corresponding backup fluent. The constraint ¬(Cbuckup (σ) ∧ C 0 (σ)) is the simple form of the historical constraint ¬(C(σ) ∧ C 0 (σ 0 )). C. Enforcing the historical constraints Let A0ss be the new set of succession state axioms obtained by adding the succession state axioms to Ass for all backup fluents corresponding to fluents mentioned in every first part of constraints in Ahis . We can then verify that: A0ss ` (∀σ, σ 0 )σ ≤ σ 0 → 0

(C6) 0

¬(C(σ) ∧ C(σ )) ↔ (∀σ)¬(Cbuckup (σ) ∧ C (σ)) as (∃σ, σ 0 )σ ≤ σ 0 ∧ (C(σ) ∧ C 0 (σ 0 )) ↔ (∃σ 0 )Cbuckup (σ 0 ) ∧ C 0 (σ 0 ) Let A0ahis be the generated finite set of all rewritten constraints in Ahis . Note that according to the unique name axioms, we

294

can verify that for each historical constraint in Ahis , there is an unique corresponding ahistorical one. As shown in the previous section, we have:

The regression of appliying Create hierarchy to the constraint (C1) is given by the following formula: R[C1(do(Create hierarchy(s, r1 , r2 ), σ))] ↔

Σ ∪ Auna ∪ A0ss ∪ Apre ∪ Acls `

¬(∃s1 )[SM ER(r1 , r2 , σ) ∧ Assign(s1 , r2 , σ)] ∧

¬(Cbuckup (σ0 ) ∧ C 0 (σ0 )) →

¬(∃r3 , s1 )[SM ER(r3 , r2 , σ) ∧ Assign(s1 , r3 , σ) ∧

(∀σ).σ0 ≤ σ → ¬(Cbuckup (σ) ∧ C 0 (σ))

Assign(s1 , r1 , σ)] ∧

where, Apre is the set of precondition axioms generated as shown in the previous section by considering the set of simple constraints A0ahis ∪ Aahis . Using C6, we can prove that:

¬(∃r3 , s1 )[SM ER(r1 , r3 , σ) ∧ Assign(s1 , r2 , σ) ∧ Assign(s1 , r3 , σ)] Similarly we calculate the regression of the other constraints. Then the action precondition axiom of the action of creating hierarchy is as follows:

Σ ∪ Auna ∪ A0ss ∪ Apre ∪ Acls ` 0

¬(C(σ0 ) ∧ C (σ0 )) → (∀σ, σ 0 ).σ ≤ σ 0 → ¬(C(σ) ∧ C 0 (σ 0 )).

P oss(do(Create hierarchy(s, r1 , r2 ), σ)) ↔

We can define now the property that a given situation is secure with respect to access control requirements. Definition 1: For each constraint ¬C(σ) in Aahis and for each constraint ¬(C 0 (σ) ∧ C 00 (σ 0 )) in Ahis , the situation σ is secure iff:

¬(r1 = r2 ) ∧ ¬Sub role(r2 , r1 , σ) ∧ ¬SM ER(r1 , r2 , σ) ∧ ¬DM ER(r1 , r2 , ss, σ) ∧ ¬(∃s1 )[SM ER(r1 , r2 , σ) ∧ Assign(s1 , r2 , σ)] ∧ ¬(∃r3 , s1 )[SM ER(r3 , r2 , σ) ∧ Assign(s1 , r3 , σ) ∧

secure(σ) ↔

Assign(s1 , r1 , σ)] ∧

permitted(σ) ∧ 00

¬(∃r3 , s1 )[SM ER(r1 , r3 , σ) ∧ Assign(s1 , r2 , σ) ∧ 0

0

0

0

¬C(σ) ∧ (¬C (σ) ∨ ¬(∃σ )σ ≤ σ ∧ C (σ ))

Assign(s1 , r3 , σ)] ∧ ¬[DM ER(r3 , r2 , ss, σ) ∧

where permitted is defined as follows:

Empowerbuckup (s, r3 , ss, σ) ∧

permitted(σ0 ) ∧ ∀a∀σ, permitted(do(a, σ)) ↔

Empower(s, r1 , ss, σ)] ∧

P erm(a, σ) ∧ permitted(σ)

¬[DM ER(r1 , r2 , ss, σ) ∧ Empower(s, r2 , ss, σ)] ∧ ¬[DM ER(r3 , r2 , ss, σ) ∧

Definition 2: We say that the system evolves in a secure way with respect to the access control requirement iff all executable situations are secure.

Empowerbuckup (s, r1 , ss, σ) ∧ Empower(s, r3 , ss, σ)]

(∀σ)executable(σ) → secure(σ)

VII. E XTENDING MODEL WITH TIME PARAMETERS

Theorem 1: The system is secure with respect to access control requirements when the action precondition axiom of every action α is strengthened with the guarded condition that this action must be permitted and the regression of all ahistorical and rewritten historical constraints.

In this section, we extend our model with time parameters to allow the specification of temporal constraints. Then we show through an example how the periodic temporal constraints can be specified and enforced. To extend the model we use the temporal situation calculus [6] which is an extension of the situation calculus presented in the section 2. This extension consists of adding a time parameter in the last position of the action parameters to denote the time when the action occurs. The language is also extended with the fluent T ime(A(~x, t)) namely the time of the action A, and the function symbol Start(σ) denoting the start time of the situation σ. The fundamental axiomatic for the situation calculus Σ is extended with other axiomatic, for more details about that the reader can refer to [6]. We mention here the most interesting axioms:

secure(σ0 ) ∧ (∀α, poss(α, σ) ↔ ^ Πα (σ) ∧ RegC (σ) ∧ P erm(α, σ)) where the big conjunction ranges over the ahistorical constraints in Aahis and the rewritten historical constraints in A0ahis . Proof: The proof is by induction. The started situation σ0 is secure by applying the hypothesis. Let σ be the situation such that secure(σ). We should demonstrate that do(a, σ) is secure where a is any action in A such that poss(a, σ). The situation do(a, σ) verifies permitted(do(a, σ)) as σ verifies that. Regarding constraints, we have already seen that it is sufficient to verify them in the initial situation. Example 1: In this example, we show how we can calculate precondition axiom of the action Create hierarchy.

• • •

295

The axiom giving the action occurrence time: T ime(A(~x, t)) = t, where A is an action. The axiom: Start(do(a, σ)) = T ime(a). The axiom that characterizes the executable situations is changed to take into account the time of occurrence of actions. Then a situation σ is executable if it is the result

of executing possible actions whose time of occurrence is not decreasing: executable(σ) ↔ (∀a, σ).do(a, σ) ≤ σ → P oss(a, σ) ∧ Start(σ) ≤ T ime(a). Temporal constraints can then be specified by using fluents taking time as parameters. They can be expressed as historical and ahistorical constraints and enforced in the same way as non temporal ones. Example 2: The payment incident occurs when the bank rejects a check payment order. The regulation like for example in France Monetary and Financial Code1 specifies that the bank can apply tax to payment incident but after sending to the bank issuer an injunction mail informing him that he will be taxed for the bad check. A rejected check can be returned to the beneficiary, then to solve the payment incident, the check issuer must replenish his account with the appropriate amount and ask the beneficiary to make a new presentation of the check. The regulation specifies that the bank cannot apply a new tax on payment incident that may happen a second time within 30 days after the first rejection. We assume that mails are received after being sent and there is no delete action applied to the received mails. So we can suppose we have the following succession state axiom for the fluent ackInjM ailRCV :

The constraint (C7) specifies that a tax should not be applied to check more than once when the injunction mail is received. The constraint (C8) specifies that a check should never be taxed more than once within 30 units of time even if it is rejected again. These constraints are impacted just by the action applyT ax, so in this example for simplicity, we omit to speak about the precondition axiom of sendAckInjM ail action and the context when it is permitted to apply it. To enforce these constraints, we can use the regression concept to calculate precondition axiom of the action applyT ax. Another approach consists in introducing the concept of temporary activation of roles related to objects. This kind of constraints is known in the literature under the name of object-based separation of duty [18]. Thereby we introduce the following: • The fluent Empowertmp (s, r, o, t, ss, σ), namely the subject s plays the role r to act on object o at time t in the session ss. • The action Activate roletmp (s, r, o, ss, t) activates the role r for the subject s to act on the object o at the time t. The succession state axiom for Empowertmp is defined as: Empowertmp (s, r, o, t, ss, do(a, σ)) ↔ Assign(s, r, σ) ∧ a = Activate roletmp (s, r, o, ss, t) ∨ (∃r1 )[Sub role(r, r1 , σ) ∧ Assign(s, r1 , σ) ∧

ackInjM ailRCV (mail, t, do(a, σ)) ↔

a = Activate roletmp (s, r1 , o, ss, t)] ∨ F alse

a = sendAckInjM ail(mail, t) ∨ ackInjM ailRCV (mail, t, σ) The fluent payIncT axed(check, t) means that the check is taxed at the time t. We assume there is no revocation on the tax operation. Then the succession state axiom of the fluent payIncT axed is as follows: payIncT axed(check, t, do(a, σ)) ↔ a = applyT ax(check, t) ∨ payIncT axed(check, t, σ) We suppose that a taxing operation can be always possible:

This above axiom specifies that a temporary activated role is true just in the situation resulting from the execution of the action Activate roletmp (s, r, o, ss, t). Any other action is performed after restoring the fluent at a false value. Suppose now that the authorization to apply tax to a check which is subject to an injunction mail is associated with a temporary activation of role Clerk. Then a subject that temporary empowers the role Clerk is permitted to apply a tax to the bad check but when he does, he will not yet empower the role Clark to act again on the check, but there is nothing that prevents him to activate the Clerk role again. For this purpose, we should add the following constraint:

P oss(do(applyT ax(check, t), σ)) → T rue

¬∃(mail, t, t0 )[check = subjOf Inj(mail, σ) ∧ Empowertmp (s, Clerk, check, t, ss, σ) ∧

And consider the two constraints: ¬(∃mail)[check = subjOf Inj(mail, σ) ∧

(C7)

Empowertmp (s, Clerk, check, t0 , ss, σ 0 )

payIncT axed(check, t, σ) ∧ payIncT axed(check, t0 , σ) ∧ ¬(t0 = t)) ¬(∃mail, mail0 )[check = subjOf Inj(mail, σ) ∧ check = subjOf Inj(mail0 , σ) ∧

(C8)

The check that is rejected one more time activates two different injunction mails. Normally it is permitted to apply tax to the check that is rejected one more time but not during the 30 days after the last rejection. This is expressed by the following historical constraint:

payIncT axed(check, t, σ) ∧

¬(∃mail, mail0 )[check = subjOf Inj(mail, σ) ∧

payIncT axed(check, t0 , σ) ∧ (t0 − t) ≤ 30)] 1 Article

(C9)

check = subjOf Inj(mail, σ 0 ) ∧

Empowertmp (s, Clerk, check, t, ss, σ) ∧ check = subjOf Inj(mail0 , σ 0 ) ∧

L131-73 and Article D131-25

296

(C10)

Empowertmp (s, Clerk, check, t0 , ss, σ 0 ) ∧ 0

t − t ≤ 30 VIII. C ONCLUSIONS AND FUTURE WORK We proposed in this work a formal language to express constraints in access control policy. In our language, there is two kinds of constraints which we call historical and ahistorical constraints. We show how this language is adequate to express well-known constraints in the literature. Then using the situation calculus, we show how to decide if a given access should be granted or denied. To enforce constraints, first we propose to rewrite the historical constraints into simple formulas. We then give a procedure based on the regression concept to enforce these constraints. It is clear that in our model there is a step that requires more simplification, this consists in the definition of succession state axioms for fluents which belong to domain application. Our proposal in this case is to specify axioms of positive (resp.negative) effects on fluents and derivation rules and then build automatically succession state axioms. In addition, we do not take advantage in this work of the planning task. In the future work we will develop in more details the use case of taxing bad check in workflow context. We intend to use the planning task to distribute user roles in order to accomplish the complete workflow task in compliance with access control policies. Our model will be extended by obligations and prohibitions modalities to allow specification of obligation and prohibition constraints necessary to express certain requirements of the law regarding the tax of bad checks. Planning will also allow us to detect if there is a conflict between specified constraints. We will, in the future work, give a formal specification of constraint consistency and provide means to prove it. R EFERENCES

[9] F. Lin and R. Reiter, “State constraints revisited,” J. Log. Comput., vol. 4, no. 5, pp. 655–678, 1994. [10] R. Waldinger, “Achieving several goals simultaneously,” in Machine Intelligence, E. W. Elcock and D. Michie, Eds. Wiley, 1977, vol. 8, pp. 94–136. [11] E. P. D. Pednault, “Synthesizing plans that contain actions with context-dependent effects.” Computational Intelligence, vol. 4, pp. 356–372, 1988. [Online]. Available: http://dblp.unitrier.de/db/journals/ci/ci4.htmlPednault88 [12] R. Reiter, “Artificial intelligence and mathematical theory of computation,” V. Lifschitz, Ed. San Diego, CA, USA: Academic Press Professional, Inc., 1991, ch. The frame problem in situation the calculus: a simple solution (sometimes) and a completeness result for goal regression, pp. 359–380. [Online]. Available: http://dl.acm.org/citation.cfm?id=132218.132239 [13] G.-J. Ahn and R. Sandhu, “The rsl99 language for role-based separation of duty constraints,” in Proceedings of the fourth ACM workshop on Role-based access control, ser. RBAC ’99. New York, NY, USA: ACM, 1999, pp. 43–54. [Online]. Available: http://doi.acm.org/10.1145/319171.319176 [14] ——, “Role-based authorization constraints specification,” ACM Trans. Inf. Syst. Secur., vol. 3, no. 4, pp. 207–226, Nov. 2000. [Online]. Available: http://doi.acm.org/10.1145/382912.382913 [15] E. Bertino, E. Ferrari, and V. Atluri, “The specification and enforcement of authorization constraints in workflow management systems,” ACM Trans. Inf. Syst. Secur., vol. 2, no. 1, pp. 65–104, Feb. 1999. [Online]. Available: http://doi.acm.org/10.1145/300830.300837 [16] J. E. Tidswell and T. Jaeger, “Integrated constraints and inheritance in dtac,” in Proceedings of the fifth ACM workshop on Role-based access control, ser. RBAC ’00. New York, NY, USA: ACM, 2000, pp. 93–102. [Online]. Available: http://doi.acm.org/10.1145/344287.344307 [17] ——, “An access control model for simplifying constraint expression,” in Proceedings of the 7th ACM conference on Computer and communications security. New York, NY, USA: ACM, 2000, pp. 154– 163. [Online]. Available: http://doi.acm.org/10.1145/352600.352622 [18] T. Jaeger and J. E. Tidswell, “Practical safety in flexible access control models,” ACM Trans. Inf. Syst. Secur., vol. 4, no. 2, pp. 158–190, May 2001. [Online]. Available: http://doi.acm.org/10.1145/501963.501966 [19] J. Crampton, “Specifying and enforcing constraints in role-based access control,” in Proceedings of the eighth ACM symposium on Access control models and technologies, ser. SACMAT ’03. New York, NY, USA: ACM, 2003, pp. 43–50. [Online]. Available: http://doi.acm.org/10.1145/775412.775419 [20] K. L. Clark, “Readings in nonmonotonic reasoning,” M. L. Ginsberg, Ed. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1987, ch. Negation as failure, pp. 311–325. [Online]. Available: http://dl.acm.org/citation.cfm?id=42641.42664

[1] J. H. Saltzer and M. D. Schroeder, “The protection of information in computer systems,” Proceedings of the IEEE, vol. 63, no. 9, pp. 1278– 1308, 1975. [2] N. Li, M. V. Tripunitara, and Z. Bizri, “On mutually exclusive roles and separation-of-duty,” ACM Trans. Inf. Syst. Secur., vol. 10, no. 2, May 2007. [Online]. Available: http://doi.acm.org/10.1145/1237500.1237501 [3] D. F. Ferraiolo, R. Sandhu, S. Gavrila, D. R. Kuhn, and R. Chandramouli, “Proposed nist standard for role-based access control,” ACM Trans. Inf. Syst. Secur., vol. 4, no. 3, pp. 224–274, Aug. 2001. [Online]. Available: http://doi.acm.org/10.1145/501978.501980 [4] N. Li, J. Byun, and E. Bertino, “A critique of the ansi standard on rolebased access control,” Security Privacy, IEEE, vol. 5, no. 6, pp. 41–49, 2007. [5] J. McCarthy, “Programs with common sense,” in Semantic Information Processing. MIT Press, 1968, pp. 403–418. [6] R. Reiter, “Sequential, temporal golog,” in In Proc. KR’98. Morgan Kaufmann, 1998, pp. 547–556. [7] S. Hanks and D. McDermott, “Readings in nonmonotonic reasoning,” M. L. Ginsberg, Ed. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1987, ch. Default reasoning, nonmonotonic logics, and the frame problem, pp. 390–395. [Online]. Available: http://dl.acm.org/citation.cfm?id=42641.42670 [8] C. Green, “Application of theorem proving to problem solving,” in Proceedings of the 1st international joint conference on Artificial intelligence, ser. IJCAI’69. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1969, pp. 219–239. [Online]. Available: http://dl.acm.org/citation.cfm?id=1624562.1624585

297