Embed Size (px)
Citation preview
Testing Delegation Policy Enforcement via Mutation Analysis
Phu H. Nguyen, Mike Papadakis and Iram RubabInterdisciplinary Centre for Security, Reliability and Trust (SnT), University of Luxembourg,
4, rue Alphonse Weicker, L-2721 Luxembourg
Email: {phuhong.nguyen, michail.papadakis, iram.rubab}@uni.lu
Abstract—Delegation is an important dimension of securitythat plays a crucial role in the administration mechanism of ac-cess control policies. Delegation may be viewed as an exceptionmade to an access control policy in which a user gets right to acton behalf of other users. This meta-level characteristic togetherwith the complexity of delegation itself make it crucial toensure the correct enforcement and management of delegationpolicy in a system via testing. To this end, we adopt mutationanalysis for delegation policies. In order to achieve this, a setof mutant operators specially designed for introducing mutantsinto the key components (features) of delegation is proposed.Our approach consists of analyzing the representation of thekey components of delegation, based on which we derive thesuggested set of mutant operators. These operators can thenbe used to introduce mutants into delegation policies and thus,enable mutation testing. A demonstration of the proposed ap-proach on a model-driven adaptive delegation implementationof a library management system is also provided.
Keywords-Mutation Analysis; Security Testing; Access Con-trol; Delegation; Model-Driven Engineering, Model-Based Test-ing
I. INTRODUCTION
In the field of access control, delegation is a very complexbut important aspect that plays a key role in the adminis-tration mechanism [1]. Delegation is a process of delegatingaccess rights from one user (called delegator) to another user(delegatee). The management and enforcement of a delega-tion policy is crucial because delegation can be considered asadministrative mechanism of access control. In a process ofdelegation, user gets exceptional capabilities to act on behalfof other users. Any discrepancy in delegation can cause amalicious user to get access to the protected resources ofthe system. It may cause privacy issues in case the datais used without the consent of authorized user. Thereforethe enforcement of delegation in the system should be freefrom any disparity. Testing is a way to get confidence onthe correctness of security policies enforcement, includingdelegation policies enforcement.
Software Testing aims at finding errors by executing testsagainst the flaws of the system. It is a way to establishconfidence on the correctness of the system behavior and toensure its quality. Although work is being done using formalverification [2], [3] and static/dynamic program analysisbased techniques [4], testing approaches are still in need. Asformal verification identifies design flaws but, some of the
underlying implementation defects still remain undetected.To this end, some work have been done on testing accesscontrol policies [5], [6], [7], [8]. However, none of theseworks aims at testing delegation policies. This forms themain issue addressed by the present paper.
Mutation analysis [9], [10] is a well established tech-nique supporting various software development activitieslike testing [11] and debugging [12]. It operates by in-troducing artificial defects called mutants into the artifactsof the program under investigation [13]. Its requirementis to design test cases capable of revealing these defects.Researchers has shown that mutants despite being artificiallyintroduced behave quite similarly to real faults [14]. Thus,the benefits of their use are evident. Mutation testing hasbeen applied on XACML policies [15] and OrBAC policies[16]. Additionally, generic policy mutants and Obligationspecific mutants have also been proposed in [17] and in[18], respectively. In this lines, the present paper proposesthe use of mutation analysis for testing the behavior of asystem with respect to its delegation policy. This practiceprovides an effective way to specialize the testing processto the delegation enforcement mechanism.
Delegation policy enforcement has certain testing chal-lenges that makes its testing task interesting and hard. Itrequires verifying the mapping between different delegationelements such as delegator, delegatee and role or permission.Additionally, since delegation is often context dependent,it is vital to ensure that a specific delegation rule is en-forced correctly in its specified context. Moreover, advanced(complex) delegation features (like monotonicity, temporarydelegation, multiple delegation, multi-step delegation, etc.)pose further difficulties to the testing process. However,as a key role in the administration mechanism of accesscontrol, the more complex delegation features that a systemsupports, the easier (and more secure) its administration taskis. Thus, testing delegation policy enforcement has to takeinto account various advanced delegation features that thispaper is dealing with.
Testing of a delegation policy enforcement is the processof ensuring the correct enforcement of its delegation rules ina system. Mutation analysis for delegation policy involvescreating mutants of a policy by injecting defects into thedelegation rules of the policy. The system implementation
is then checked against the enforcement of the mutatedpolicy versions. In view of the request-response nature ofa delegation, policy mutants can be recognized as killedor live. In this paper, we introduce the issues of testingdelegation policy enforcement. Ultimately, we suggest theuse of mutation testing for their effective test. Briefly, ourmain contributions consist of 1) a formal specification ofaccess control and delegation policy supporting advanceddelegation features; and 2) a set of mutant operators derivedfrom the process of analysing different aspects of delegation.
The rest of this paper is organized as follows. SectionII illustrates the aspects of testing a delegation policy viaa running example. Some background material is given inSection III. In Section IV the notations of delegation model,context and features are introduced. In Sections V and VIthe proposed set of mutant operators and a demonstrationexample of their application are given respectively. FinallySections VII discuses some related work and Section VIIIsummarizes the paper.
II. A RUNNING EXAMPLE
This section presents a library management system (LMS)providing library services. There are two types of useraccounts in the LMS: personnel accounts such as director,secretary, administrator and librarian, are managed by ad-ministrator; and borrower accounts like lecturer and studentthat are managed by secretary. A secretary can add newbooks in the LMS when they are delivered. The directorof the library has the same accesses as the secretary, butadditionally, he can also consult the personnel accounts. Thelibrarian can consult the borrower accounts. Lecturers andstudents can borrow, reserve and return books, etc.
The LMS implementation details can be found in [19]. Inthis paper we describe some delegation situations as followsto illustrate our approach. We refer to these delegations asdelegation 1, 2 and 3.
1) Bill (has role Director) delegates his permission ofconsulting personal account to Bob (Secretary).
2) Alice (Secretary) transfers her permission of creatingborrower account to Jane (Librarian). Alice cannot usethis permission while delegating it.
3) Bill (Director) delegates his permission of consultingpersonal account to Bob (Secretary) during his vaca-tion (the delegation is automatically activated at thestart of his vacation and revoked at the end of hisvacation).
These delegation situations also will be used further intesting their correct enforcement via mutation analysis.
III. BACKGROUND
A. Access Control
Access Control aims at securing a software system bycontrolling the access of users (or processes, components,etc.) to the resources (e.g. files, methods, etc.) of the system.
Every access is controlled through the enforcement of anaccess control policy, which is composed of a set of rulesfor allowing or denying the access to the system resources,in different contexts.
Definition 1 (Access Control): Let U be a set of users,P be a set of permissions, and C be a set of contexts. Anaccess control policy AC is defined as a user-permission-context assignment relation: AC ⊆ U × P × C. A user uis granted permission p in a given context c if and only if(u, p, c) ∈ AC. Additional details about contexts are givenin Section IV-B.
B. Delegation
In the field of access control, delegation is a very complexbut important aspect that plays a key role in the adminis-tration mechanism [1]. By supporting delegation, a systemallows its users to grant some authorizations, even thoughthose users do not have any specific administrative privi-leges. There are two types of authorization can be delegated:right and obligation. This paper studies right delegation,further work will be dedicated to obligation delegation. Inthe rest of this paper, “delegation” is understood as “rightdelegation”.
Figure 1. A simple example of Delegation Process
So, delegation is the process of delegating access rights(permissions) from one subject i.e. a delegator to anothersubject i.e. a delegatee. The basic concept of delegation ispresented in Figure 1. In this example, Alice (Secretary) andJane (Librarian) have access to the resources of LMS withtheir personal rights, i.e. Alice as a secretary can add newbooks, and create borrower account, while Jane as a librariancan consult borrower account. For some reason, Alice wantsto delegate her permission of creating borrow account toJane. As described by the arrow from Alice to Jane in Figure1, Alice (delegator) is delegating the permission of “createborrower account” to Jane (delegatee). Once Alice has beendelegating this permission to Jane, it is added to the accessrights of Jane. By this delegation, Jane can create borroweraccount while being delegated by Alice on this permission.
IV. SPECIFICATION OF DELEGATION FEATURES
This section defines a delegation policy by taking intoaccount its various features. We will further use thesedefinitions to express delegation mutant operators in SectionV.
A. Delegation Policy
A delegation policy can be considered as anadministrative-related security policy that is built ontop of an access control policy. It is composed of delegationrules that can be specified at two levels: master-level anduser-level. Basically, a delegation policy is two-fold:
1. It specifies who has the right to delegate which per-mission (for accessing to a given resource/action/subject) towhom, and in which context. Let us call this kind of ruleis master-level delegation rule as such a rule is normallydefined by policy officers. For example, a policy officer candefine a rule to specify that the head of department at auniversity can delegate the permission of updating personnelaccounts to a professor only.
Definition 2 (Master-Level Delegation): Let U be a set ofusers, P be a set of permissions, and C be a set of contexts.A master-level delegation policy MLD is defined as a user-user-permission-context assignment relation: MLD ⊆ U ×U × P ×C. A delegation of a permission p from a user u1
to a user u2 in a given context c can be performed if andonly if (u1, u2, p, c) ∈MLD.
2. It specifies who is delegating to whom which permis-sion, and in which context. Let us call this kind of rule isuser-level delegation rule as these rules are mostly definedby normal users. Note that user-level delegation rules mustconform to master-level delegation rules. For example, Bill(the head of department) is delegating his permission ofupdating personnel accounts to Bob (a professor) during hisabsence.
Definition 3 (User-Level Delegation): Let U be a set ofusers, P be a set of permissions, and C be a set ofcontexts. A user-level delegation policy ULD is defined asa user-user-permission-context assignment relation: ULD ⊆U × U × P × C. A user u2 can have a permission p bydelegation from a user u1 in a given context c if and onlyif (u1, u2, p, c) ∈ ULD.
B. Context
A context is a condition or a combination of conditionsin which an access control/delegation rule is active, i.e. en-forced in the running system. Cuppens et al. [20] discuss fivedifferent kinds of contexts. These kinds include temporal,spatial, user-declared, pre-requisite and provisional context.Temporal delegation is delegation within a time constraint,for example delegation is active for two days or delegation isactive for the time user is on vacation. The spatial context isused for subject location, e.g. a delegated permission is onlyactive when the delegatee is at office. User-declared context
is related to the purpose of the subject. Prerequisite contextallows delegation when some pre-condition is satisfied andthe provisional context depends on the previous actions thatsubject has performed on the system.
Our security model supports context composition usingfollowing operators: conjunction &, disjunction ⊕, andnegation .̄
Note that every delegation rule defined in this paperis always associated with a context c. By default, if notspecified explicitly, a context c is at least composed of acondition, called Default, i.e. always true.
C. Delegation Features
Delegation is a powerful and very useful way to performaccess control policy administration. On one hand, it allowsusers to temporarily modify the access control policy bydelegating access rights. By delegation, a delegatee can per-form the delegated job, without requiring the intervention ofthe security officer. On the other hand, the grantor/delegatorand/or some specific authorized users should be supportedto revoke the delegation either manually or automatically.On both hands, the administrative task can be simplified andcollaborative work can be managed securely, especially withthe increase in shared information and distributed systems.However, the simpler the administrative task can be, themore complex features of delegation have to be properlyspecified and enforced in the software system.
In this section, we define the most well-known complexdelegation features and formally specify them w.r.t thedefinitions of access control and delegation policies. Inthe following definitions, we use pre, body, and post torespectively specify the state of the policy before changing,the state while it is being changed by the function, and thestate after changing.
1) Monotonicity of Delegation: Monotonicity of delega-tion refers to whether or not the delegator can still use thepermission while delegating it [21]. If the delegator canstill use the permission while delegating it, the delegationis called grant delegation. Of course, the delegatee can usethe permission while it is being delegated to him. Thisis monotonic because available authorizations (in AC) areincreased due to successful delegation operations. Again,note that every delegation can only be performed if and onlyif it satisfies the master-level delegation policy.
Definition 4 (Grant Delegation):grantDelegation(u1, u2, p, c) : −pre (u1, p, c) ∈ AC ∧ (u2, p, c) /∈ AC ∧ (u1, u2, p, c) ∈MLDbody AC := AC ∪ {(u2, p, c)}; ULD :=ULD ∪ {(u1, u2, p, c)} endpost (u1, p, c) ∈ AC ∧ (u2, p, c) ∈ AC ∧ (u1, u2, p, c) ∈ULD
Vice versa, if the delegator can not use the permissionwhile delegating it, the delegation is called transfer dele-
gation. As such, this is non-monotonic because availableauthorizations (in AC) are not increased due to successfuldelegation operations.
Definition 5 (Transfer Delegation):transferDelegation(u1, u2, p, c) : −pre (u1, p, c) ∈ AC ∧ (u2, p, c) /∈ AC ∧ (u1, u2, p, c) ∈MLDbody AC := AC \ {(u1, p, c)}; AC := AC ∪ {(u2, p, c)};ULD := ULD ∪ {(u1, u2, p, c)} endpost (u1, p, c) /∈ AC ∧ (u2, p, c) ∈ AC ∧ (u1, u2, p, c) ∈ULD
2) Temporary Delegation: This is also a very commonfeature of delegation used by users. When revocation ishandled automatically, the delegation is called temporary.In this case, the delegator specifies the temporal conditionsin which this delegation applies: only at a given time, afteror before a given time, or during a given time interval. Thetemporal conditions may correspond to a day of the week,or to a time of the day, etc. If the temporal context is notused, the delegation needs to be revoked manually.
As we have mentioned, a delegator (e.g. Bill) can includea temporal condition in the context of the delegation rule,for instance during his vacation. Thus, here the temporalcontext is vacation period defined as follows:
Definition 6 (Temporary Delegation): Let c be a givencontext of a delegation (either grant delegation or transferdelegation). A delegation is specified as temporary if its con-text is associated with some time constraint. The delegationwill be only active while the time constraint is satisfied.
c := c&vacation period(startDate, endDate)where vacation period(startDate, endDate) : −startDate ≤ endDate ∧ afterDate(startDate) ∧beforeDate(endDate)
Here, afterDate(date) returns true iff date is equalor later than the current date. Similarly, beforeDate(date)returns true iff date is equal or earlier than the current date.
3) Multiple Delegation: Multiple delegation refers to themaximum number of times a permission can be delegatedat a given time. We define a counting function to countthe number of delegations of a permission, delegated by adelegator in a given context. The number returned by thisfunction is always updated according to the change in thedelegation policy, i.e. the number of delegation rules relatedto permission p.countDelegation(u, p, c) := |{(u, v, p, c) | ∀v ∈ U :
(u, v, p, c) ∈ ULD}|Let Nm be this number and it is pre-defined by the
security officer.Definition 7: grantDelegation(u1, u2, p,
c&countDelegation(u1, p, c) < Nm) : − pre (u1, p, c) ∈AC ∧ (u2, p, c) /∈ AC ∧ (u1, u2, p, c) ∈ MLD ∧countDelegation(u1, p, c) < Nm
body AC := AC ∪ {(u2, p, c)}; ULD := ULD ∪{(u1, u2, p, c)} end
post (u1, p, c) ∈ AC ∧ (u2, p, c) ∈ AC ∧ (u1, u2, p, c) ∈ULD
4) Multi-step Delegation: This characteristic refers to themaximum number of steps (Ns, normally specified by asecurity officer) that a permission p can be re-delegated,counted from the first delegator of this permission. So ifNs = 0 that means the permission p can not be re-delegatedanymore. First, let us define a helper function that returnshow the number of times a permission is re-delegated in agiven context.
stepCounter(u0, p, c) := Ns with u0 is the first delegatorof p in the delegation chain: u0 delegates p to ... in a givencontext c; ... re-delegates p to u1 in context c; and u1 re-delegates p to u2 in context c.
If there exists a pre-defined maximum number of stepsNs for a permission p as described above, the delegation isspecified as following.
Definition 8: grantDelegation(u1, u2, p, c&stepCounter(u1, p, c) ≥ 1) : −pre (u1, p, c) ∈ AC ∧ (u2, p, c) /∈ AC ∧ (u1, u2, p, c) ∈MLD ∧ stepCounter(u1, p, c) ≥ 1body AC := AC ∪ {(u2, p, c)}; ULD :=ULD ∪ {(u1, u2, p, c)}; stepCounter(u2, p, c) :=stepCounter(u1, p, c)− 1 endpost (u1, p, c) ∈ AC ∧ (u2, p, c) ∈ AC ∧ (u1, u2, p, c) ∈ULD
5) Delegation Revocation: Delegation support revocationfeature in which a delegation can be revoked and permissionsare returned back to the original user. The revocation of agrant delegation means to deny access of the delegatee tothe delegated permission.
Definition 9: revokeGrantDelegation(u1, u2, p, c) : −pre (u1, p, c) ∈ AC∧(u2, p, c) ∈ AC∧(u1, u2, p, c) ∈ ULDbody AC := AC \ {(u2, p, c)}; ULD := ULD \{(u1, u2, p, c)} endpost (u1, p, c) ∈ AC ∧ (u2, p, c) /∈ AC ∧ (u1, u2, p, c) /∈ULD
The permission to be revoked is deleted from the accessrights of delegatee.
To revoke a transfer delegation, it is not only to denyaccess of the delegatee to the delegated permission but alsoto re-grant access to the delegator who is temporarily nothaving this access.
Definition 10: revokeTransferDelegation(u1, u2, p, c) :−pre (u2, p, c) ∈ AC∧(u1, p, c) /∈ AC∧(u1, u2, p, c) ∈ ULDbody AC := AC \ {(u2, p, c)}; AC := AC ∪ {(u1, p, c)};ULD := ULD \ {(u1, u2, p, c)} endpost (u1, p, c) ∈ AC ∧ (u2, p, c) /∈ AC ∧ (u1, u2, p, c) /∈ULD
V. MUTANT OPERATORS
In this section, we define mutant operators for delegations.The operators are defined solely for delegation in an access
control policy and we do not consider other aspects of policysuch as obligations. Testing of access rights and obligationsis done separately in several works [18], [17]. We categorizethe operators into two broad categories: basic delegationoperator and advanced delegation operator.
Note that we omitted the notion of role in Section IIIbecause we focused on the formalisation of different featuresof delegation where they can be specified without thedefinition of role. However, in practice, the notion of roleis commonly used for supporting natural abstractions likesets of permissions. Role-Based Access Control (RBAC)introduces a set of role and decomposes the relation AC intouser-role assignment UR ⊆ U × R, and role-permission-context assignment RPC ⊆ R × P × C. Thus, AC =UR ◦ RPC. For evaluation of operators, we will deriveour delegation operators based on RBAC but we consideraspects that are commonly found in most access control anddelegation models.
A. Basic Delegation Mutant Operators
Basically delegation are of two types: permission delega-tion and role delegation.- Permission delegation: Users can delegate specific permis-sion(s) that are associated with their own roles.- Role delegation: Role delegation means a user empoweredin some role(s) can delegate his role to other user (s). Inthis way the delegatee can use permissions of his role andpermissions of role that is delegated to him. We introduce thefollowing operators based on the basic types of delegation.
1) Permission Delegation Operator: Permission delega-tions are the most frequent type of delegations used in accesscontrol. Permissions are delegated between two subjects, likein LMS, one such delegation is Alice (secretary) delegatedher permission to create borrow account to Jane (librarian).The Permission Delegation Operator (PDM) will mutate thepermission delegation rule by replacing the permission beingdelegated by another permission of the delegator.
Definition 11: PDM(u1, u2, p1a, c) : −pre (u1, u2, p1a, c) ∈ ULD ∧ (u1, r1) ∈ UR ∧ (u2, r2) ∈UR ∧ (r1, p1a, c) ∈ RPC ∧ (r1, p1b, c) ∈ RPCbody ULD := ULD \ {(u1, u2, p1a, c)} ∪ {(u1, u2, p1b, c)}; AC := AC ∪ {(u2, p1b, c)} endpost (u2, p1b, c) ∈ AC ∧ (u1, u2, p1b, c) ∈ ULD
2) Role Delegation Operator: The Role Delegation Op-erator (RDM) is used to simulate errors in delegation ofroles. The RDM operator will mutate the delegation rule byreplacing the delegator by some other user having differentrole. For example in the LMS system, one delegation is: Bill(Director) delegates his role to Bob (Secretary). The mostimportant aspect in such a delegation is to establish correctlink between delegator-role-delegatee. This means that theright delegator delegates the right role to the delegatee.
Definition 12: RDM(u1, u2, r1, c) : −pre (u1, r1) ∈ UR∧ (u2, r2) ∈ UR∧ (u3, r3) ∈ UR∧ r1 6=
r2 6= r3 ∧ (u1, u2, r1, c) ∈ ULDbody ULD := ULD \ {(u1, u2, r1, c)} ∪ {(u3, u2, r3, c)} ;UR := UR ∪ {(u2, r3)} endpost (u2, r3) ∈ UR ∧ (u3, u2, r3, c) ∈ ULD
B. Advanced Delegation Operators
Advanced delegation operators are described w.r.t ad-vanced properties of delegation such as transfer delegation,temporary delegation, user-specific delegation, role-specificdelegation, etc., we introduce mutants to simulate errors thataffects the correctness of these types of delegation.
1) Monotonic Delegation Operators: A delegation canbe monotonic or non-monotonic. The former specifies thatthe delegated access right is available to both the delegatorand delegatee after enforcing this delegation. The lattermeans that the delegated role/permission is transferred tothe delegatee, and the delegator temporarily loses his rightswhile delegating them. In this case, the delegation is called atransfer delegation. For instance in LMS, a secretary (Bob)transfers his role to an administrator (Sam) and Bob nolonger can use his role during the delegation period.
By mutating the property monotonicity of a delegation,we can simulate errors such as the enforcement of a transferdelegation is implemented as a grant delegation, or viceversa, a grant delegation is changed to a transfer delegation.The Transfer to Grant Delegation Operator (T2G) and theGrant to Transfer Delegation Operator (G2T) are defined forperforming these mutations.
Definition 13: G2T (u1, u2, p, c&IsMonotonic) : −pre (u1, p, c) ∈ AC ∧ (u1, u2, p, c&IsMonotonic) ∈ ULDbody ULD := ULD \ {(u1, u2, p, c&IsMonotonic)} ∪{(u1, u2, p, c&IsNonMonotonic)} endpost (u1, p, c) /∈ AC ∧ (u1, u2, p, c&IsNonMonotonic) ∈ULD
Definition 14: T2G(u1, u2, p, c&IsNonMonotonic) :−pre (u1, p, c) /∈ AC ∧ (u1, u2, p, c&IsNonMonotonic) ∈ULDbody ULD := ULD \ {(u1, u2, p, c&IsMonotonic)} ∪{(u1, u2, p, c&IsMonotonic)} endpost (u1, p, c) ∈ AC∧(u1, u2, p, c&IsMonotonic) ∈ ULD
2) Context-based Delegation Operators: Delegations arealways applied in some context. Test should guaranteecorrect implementation of context of delegations. Delegationcontexts can be temporal, spatial, provisional, pre-requisiteor a user declared context. The context is tested by reducingthe scope of the context (CR), by extending the scope of thecontext (CE) and by negating the original context (CN).
In this paper, we only deal with temporal delegationbecause of its popularity [20]. The other types of context-based delegations are not considered. We introduce theTemporal Delegation Operator (TDM) to mutate the durationof temporal delegation. To be more specific, we mutatethe temporal delegation rule by reducing or expanding the
duration of a temporal delegation. For example, we applyTDM for the temporal delegation defined in Definition 6 asfollows.
Definition 15: TDM(startDate, endDate) : −pre vacation period(startDate, endDate)body startDate := laterStartDate ∧ laterStartDate >startDate ∧ laterStartDate < endDate endpost vacation period(laterStartDate, endDate)
3) Role-Specific Delegation Operators: A security policycould allow users having a specific role can only delegateto other users having some role that belongs to the possibledelegation targets of that role. This can be seen as the casewhere the security policy ensures that no conflict of interestcan occur by delegation. Roughly speaking, one exampleis in any case a student must never have permissions ofboth roles student and lecturer because he can edit hisown grades. That means a lecturer does not have right todelegate his role to his student. To test this kind of restrictionwe propose the following operators. The Role DelegationOff-Target 1 Operator (RDOT1) will replace the delegateeby another user whose role is not a possible target of thedelegator’s role. That means there exists a delegation ruleat master level saying that a user of this role is a possibledelegatee of a user of another role: (u1, u2, r, c) ∈ MLD.Note that to keep it general, we use the definition of master-level delegation rule to refer to all kinds of delegation rulespecifying constraints, e.g. role-specific delegation, multipledelegation, multi-step delegation, etc.
Definition 16: RDOT1(u1, u2, r, c) : −pre (u1, u2, r, c) ∈ MLD ∧ (u1, u3, r, c) /∈ MLD ∧(u1, u2, r, c) ∈ ULDbody ULD := ULD \ {(u1, u2, r, c} ∪ {(u1, u3, r, c)} endpost (u1, u3, r, c) /∈MLD ∧ (u1, u3, r, c) ∈ ULD
Vice versa, the Role Delegation Off-Target 2 Operator(RDOT2) will replace the delegator by another user whoserole’s delegation targets set does not contain the delegatee’srole.
Definition 17: RDOT2(u1, u2, r, c) : −pre (u1, u2, r, c) ∈ MLD ∧ (u3, u2, r, c) /∈ MLD ∧(u1, u2, r, c) ∈ ULDbody ULD := ULD \ {(u1, u2, r, c} ∪ {(u3, u2, r, c)} endpost (u3, u2, r, c) /∈MLD ∧ (u3, u2, r, c) ∈ ULD
4) Permission-Specific Delegation Operators: In this cat-egory, we discuss permission specific operator. The Non-Delegable Permission Delegation Operators (NDPD) willmutate a permission delegation by changing the delegatedpermission from delegable to non-delegable.
Definition 18: NDPD(u1, u2, p, c) : −pre (u1, u2, p, c) ∈MLD ∧ (u1, u2, p, c) ∈ ULDbody MLD := MLD \ {(u1, u2, p, c} endpost (u1, u2, p, c) /∈MLD ∧ (u1, u2, p, c) ∈ ULD
5) Multiple Delegation Operator: Tests should revealproblems in ensuring that the number of concurrent dele-gations of a specific role/permission does not exceed the
threshold defined for it at the master level. To simulatethe case where adding a new delegation will make thatnumber exceeds a pre-define threshold of a role/permission,we introduce Multiple Delegation Operator (MultiD).
Definition 19: MultiD(countDelegation(u1, p, c) <Nm) : −pre (u1, u2, p, c) ∈ MLD ∧ countDelegation(u1, p, c) =Nm
body ULD := ULD ∪ {(u1, u2, p, c)} endpost (u1, u2, p, c) ∈ ULD ∧ countDelegation(u1, p, c) =Nm + 1
6) Multi-step Delegation Operator: Tests should alsoreveal problems in re-delegation of permissions and roles.Some roles and permissions can be defined as re-delegableonly after a limited number of times. We mutate the policyby re-delegating a role or permission that is not re-delegableand vice versa. In the mutated policy the delegatee willtake the role/permission of delegator. Similarly the roleand permissions that should not be redelegated are mutatedby re-delegating them. The Re-delegation Operator (ReD)add a new delegation rule into the policy where the dele-gating permission/role must not be re-delegated any more(stepCounter = 0).
Definition 20: ReD(stepCounter(u1, p, c)) : −pre (u1, u2, p, c) ∈MLD ∧ stepCounter(u1, p, c) = 0body ULD := ULD ∪ {(u1, u2, p, c)};stepCounter(u2, p, c) := stepCounter(u1, p, c) − 1endpost (u1, u2, p, c) ∈ ULD ∧ stepCounter(u2, p, c) = −1
7) Delegation Removal Operators: Tests should be ableto detect that a delegation rule is missing. We introduce theDelegation Removal Operator (DR) that removes one of thedelegation rules.
Definition 21: DR(u1, u2, p, c) : −pre (u1, u2, p, c) ∈ ULDbody ULD := ULD \ {(u1, u2, p, c} endpost (u1, u2, p, c) /∈ ULD
All the delegation mutants defined in this section arederived from basic delegation types as well as various(advanced) well-known delegation features. Thus, we believethey are representative for testing delegation policies. Ademonstration example of using some of these mutants isgiven in the next section.
VI. DEMONSTRATION OF TESTING DELEGATION POLICYENFORCEMENT
In this section, we first give a brief description of aprototype system (LMS) implemented as a proof-of-concept.Then, we demonstrate how the proposed mutation analysisapproach has been applied on this system.
A. Model-Driven Adaptive Delegation
The implementation of LMS is part of our previous work[19] on Model Driven Adaptive Delegation. In [19], we
Access Control Service
Transformation &
Adaptation
Delegation Management Service
Resource Proxy
Components
Role Proxy Components
User Proxy Components
Business Components
Base model – Business Logic mappings service
Native XML-DB Server
Security policy model
Base model
Business Logic DB Server
Authenticate Component
Adaptive Execution Platform
Business Components Business Logic
Components
Resource Proxy
Components
Role Proxy Components
User Proxy Components
Figure 2. Architectural framework
propose a model-driven framework in which on one hand,we can specify a security model using a Domain SpecificLanguage (DSL). On the other hand, the business logicof the system can be specified using another DSL, i.e.component-based architecture. As shown in Figure 2, thesecurity model will be transformed and composed with thearchitecture model of the system. The composed modelactually reflects the security policy at architecture level. Byleveraging the notion of model@runtime [22], the runningsystem can be adapted according to the newly composedmodel. Thus any change in the policy (access control and/ordelegation) will be automatically enforced in the runningsystem at runtime. Figure 3 shows an example of the 3-layer architecture reflecting security policy. In this policyconfiguration, Bill has role Director that can have accessrights to BorrowerAccountResource but currently Bill istemporarily transferring his role to Bob (his secretary). Thelinks between components at different layers are actually theservice bindings from “client” ports (of the components onthe left) to “server” ports (of the components on the right).
B. Mutation Process
Figure 4 gives an overview of the mutation process fortesting delegation. Based on the mutant operators presentedin Section V our delegation policy can be easily mutated. Viathe model-driven framework described above, those mutatedpolicies can be automatically enforced in the running system.
We performed mutation analysis on the examples de-scribed in Section II. We used those three delegation sit-uations to demonstrate the application of the proposedapproach. We chose five test cases to test these three types ofdelegation of our running example. Table I gives an overviewof them.
In case of delegation 1, Bill (Director) delegates his per-mission consultPersonnelAccount to Bob (Secretary). Thissimple delegation is mutated in two different ways, first
Personnel Account Service
Borrower Account Service
Book Service
Personnel Account Resource
Borrower Account Resource
Book Resource
Admin
Secretary
Librarian
Director
Student
Sam
Bob
Jane
Bill
Mary
consult
update
delete
create
consult
update
delete
create
deliver
fix
borrow reserve
return
User layer Role layer Resource layer Business layer
Figure 3. Component-based Architecture reflecting Security Policies
Transform &
adapt
Resource Proxy
Components
Role Proxy Components
User Proxy Components
Business Components
Access Control policy
Business Logic model
Authenticate Component
Adaptive Execution Platform
Business Components
Business Logic
Components
Resource Proxy
Components
Role Proxy Component
s
User Proxy Components
Delegation policy
Test cases
Access Control policy
Mutants Mutants
Mutants
Mutate
Compose
Figure 4. Mutation Process for testing Delegation Policy enforcement
replacing Bill by Sam who is an administrator (by usingRDM) and then by replacing consultPersonnelAccount withanother permission (using PDM), e.g. consultBorrowerAc-count. We created one test case (TC1) to test if Bob cando consultPersonnelAccount after enforcing the delegationrule. The test case was able to kill the second mutant becauseBob was not delegated consultPersonnelAccount but consult-BorrowerAccount. However, it did not kill the first mutantbecause Sam also has the right consultPersonnelAccount asBob. Thus, Sam’s rights including consultPersonnelAccounthave been delegated to Bob, that made him accessible toconsultPersonnelAccount.
In case of delegation 2, we use two test cases to test thisdelegation. One (TC2) is used to test the correct enforcementof the delegated permission (createBorrowerAccount). Itresembles the test case for delegation 1, in which we testright allocation of permission. Similarly, it detects mutant inwhere a wrong permission is inserted (PDM) but fails to kill
Table ISOME PRELIMINARY MUTATION ANALYSIS RESULTS
Test Case Killed Mutants Live MutantsTest Case-1 PDM (wrong permission mutant) RDM (delegator fault)Test Case-2 PDM (wrong permission) RDM (delegator replaced)Test Case-3 T2G (wrong type of delegation) PDM, RDM (wrong delegator, permission)Test Case-4 PDM (permission replaced) TDM (CE,CR)Test Case-5 TDM (CE,CR) PDM, RDM
mutant when the delegator is replaced (RDM). The other testcase (TC3) is used to test transfer (monotonicity) property ofthe delegation, i.e. Alice cannot use createBorrowerAccountwhile transferring it to Jane. For this case, we used T2Gto change the type of delegation 2 from transfer to grant.TC3 did kill the mutant of T2G but could not kill the othermutants of PDM and RDM because in those mutants Alicecannot use createBorrowerAccount.
We test delegation 3 in a temporal context. We chose twotest cases (TC4 and TC5) to kill the four mutants of thisdelegation. Two mutants are created by injecting permissionand delegator related faults (PDM and RDM). The other twomutants are created by reducing and expanding the durationof a temporal delegation (TDM). We created a test case(TC4) similar to TC1. The other test case (TC5) is designedto detect if enforcement of delegation 3 is correct during itsactive duration. TC5 kills TDM but leaves undetected themutants of PDM and RDM. Vice versa, TC4 cannot kill themutant of TDM.
VII. RELATED WORK
Testing of access control policy is a relatively new do-main. Some work is available on testing of access controlpolicy with XACML. Martin and Xie [17] propose a faultmodel for access control policies based on XACML. Thisfault model was then used to measure the effectiveness oftheir test cases. The fault model considers access controlfeatures composed of permissions and prohibitions. Hu et al.[15] elaborate the conformance checking of access controlpolicy. Other approaches try to test a policy by usingstate machines. The main focus of such approaches is thegeneration of test cases for access control policies [16],[7]. To the best of our knowledge, there has not been anyapproach dedicated to testing delegation enforcement takinginto account an extensive delegation model like ours.
Le Traon et al. [23] establish a mutation analysis approachfor performing security testing. Xu et al. [8] propose amodel based testing approach for access control policies.They use both the policy and its contracts implemented ina number of industry usable languages. The test adequacyis also measured through mutation analysis. El Rakaibyet al. [18] use mutation analysis to test obligations. Theirapproach (not model-based) is on the same lines with theone proposed here except that their focus is obligation andour focus is delegation. However, there is a big differ-
ence because delegation and obligation are two differentaspects. Especially, because of the “meta-level” character ofdelegation w.r.t access control, applying mutation analysisfor testing delegation enforcement has to take into accountdifferent delegation features in the whole process. Moreover,our mutation analysis approach bases on our model-drivenframework showed in [19] making it easy to leverage model-based testing techniques.
VIII. CONCLUSION
The process of delegating access rights forms one of thecentral issues in the administration of an access controlpolicy. The delegation of authority gives users more rightsover protected resources so its undisputed implementationand enforcement require a rigorous testing process. In viewof this, the present paper suggests the use of mutationanalysis to test the delegation policy enforcement. To achievethis, a careful and formal analysis of different delegationfeatures was performed. Based on this analysis a set ofmutant operators specific for delegation has been derived.
In future, a thorough empirical study using the proposedmutant operators is planed. This will lead in identifying themost useful and effective mutant operators. Moreover, weaim at investigating ways to automatically generate test casesfor killing the proposed mutants. Towards this directionwe aim at extending existing approaches [24], [25] to dealwith delegations. Finally, the integration of model-basedtesting with the suggested mutation approach will be alsoresearched.
ACKNOWLEDGMENT
This work is supported by the Fonds National de laRecherche (FNR), Luxembourg, under the MITER projectC10/IS/783852.
REFERENCES
[1] M. Ben-Ghorbel-Talbi, F. Cuppens, N. Cuppens-Boulahia,and A. Bouhoula, “A delegation model for extended RBAC,”International Journal of Information Security, vol. 9, pp. 209–236, June 2010.
[2] T. Ahmed and A. R. Tripathi, “Static verification of securityrequirements in role based CSCW systems,” SACMAT 03:Proceedings of the eighth ACM symposium on Access controlmodels and technologies, pp. 196–203, 2003.
[3] F. Hansen and V. Oleshchuk, “Conformance checking of rbacpolicy and its implementation,” Proceedings of InformationSecurity Practice and Experience: First International Con-ference, ISPEC.
[4] V. B. Livshits and M. S. Lam, “Finding security errors inJava programs with static analysis,” In Proceedings of the14th Usenix Security Symposium, August,2005.
[5] Y. Le Traon, T. Mouelhi, and B. Baudry, “Testing securitypolicies: going beyond functional testing,” in Proceedings of18th IEEE international symposium on Software Reliability.ser ISSRE, 2007.
[6] E. Martin and T. Xie, “Automated Test Generation for AccessControl Policies via Change-Impact Analysis,” Third Interna-tional Workshop on Software Engineering for Secure Systems, SESS’07: ICSE Workshops, 2007.
[7] A. Masood, R. Bhatti, A. Ghafoor, and A. Mathur, “Scalableand Effective Test Generation for Role-Based Access Con-trol Systems,” IEEE Transactions on Software Engineering,vol. 35,5, pp. 654–668, 2009.
[8] D. Xu, L. Thomas, M. Kent, T. Mouelhi, and Y. Le Traon,“A Model-Based Approach to Automated Testing of AccessControl Policies,” SACMAT, 2012.
[9] R. A. DeMillo, R. J. Lipton, and F. G. Sayward, “Hintson test data selection: Help for the practicing programmer,”Computer, vol. 11, pp. 34–41, Apr. 1978.
[10] R. G. Hamlet, “Testing programs with the aid of a compiler,”IEEE Trans. Softw. Eng., vol. 3, pp. 279–290, July 1977.
[11] Y. Jia and M. Harman, “An analysis and survey of thedevelopment of mutation testing,” IEEE Trans. Software Eng.,vol. 37, no. 5, pp. 649–678, 2011.
[12] M. Papadakis and Y. L. Traon, “Using mutants to locate”unknown” faults,” in ICST, pp. 691–700, 2012.
[13] J. Offutt, “A mutation carol: Past, present and future,” Infor-mation & Software Technology, vol. 53, no. 10, pp. 1098–1107, 2011.
[14] J. H. Andrews, L. C. Briand, Y. Labiche, and A. S. Namin,“Using mutation analysis for assessing and comparing testingcoverage criteria,” IEEE Trans. Software Eng., vol. 32, no. 8,pp. 608–624, 2006.
[15] V. C. Hu, E. Martin, J. Hwang, and T. Xie, “ConformanceChecking of Access Control Policies Specified in XACML,”Computer Software and Applications Conference, COMPSAC2007, 31st Annual International, vol. 2, pp. 275 – 280, 2007.
[16] K. Li, L. Mounier, and R. Groz, “Test Generation fromSecurity Policies Specified in Or-BAC,” Computer Softwareand Applications Conference, 2007. COMPSAC 2007, 31stAnnual International, vol. 2, pp. 255– 260, 2007.
[17] E. Martin and T. Xie, “A Fault Model and Mutation Testingof Access Control Policies,” International World Wide WebConference Committee, 2007.
[18] Y. Elrakaiby, T. Mouelhi, and Y. Le Traon, “Testing Obliga-tion Policy Enforcement Using Mutation Analysis,” ICST ’12Proceedings of the 2012 IEEE Fifth International Conferenceon Software Testing, Verification and Validation, pp. 673–680.
[19] P. H. Nguyen, G. Nain, J. Klein, T. Mouelhi, and Y. Le Traon,“Model-Driven Adaptive Delegation,” in Proceedings of theAspect-Oriented Software Development conference MODU-LARITY: aosd13, ACM, 2013.
[20] F. Cuppens and N. Cuppens-Boulahia, “Modeling contextualsecurity policies,” International Journal of Information Secu-rity, vol. 7, pp. 285–305, Nov. 2007.
[21] J. Crampton and H. Khambhammettu, “Delegation in role-based access control,” International Journal of InformationSecurity, vol. 7, pp. 123–136, Sept. 2007.
[22] B. Morin, O. Barais, J.-M. Jezequel, F. Fleurey, and A. Sol-berg, “Models@ run.time to support dynamic adaptation,”Computer, vol. 42, pp. 44–51, Oct. 2009.
[23] Y. Le Traon, T. Mouelhi, A. Pretschner, and B. Baudry, “Test-Driven Assessment of Access Control in Legacy Applica-tions,” Software Testing, Verification, and Validation, 20081st International Conference on, pp. 238 – 247, 2008.
[24] M. Papadakis and N. Malevris, “Mutation based test casegeneration via a path selection strategy,” Information &Software Technology, vol. 54, no. 9, pp. 915–932, 2012.
[25] M. Papadakis and N. Malevris, “Automatically performingweak mutation with the aid of symbolic execution, concolictesting and search-based testing,” Software Quality Journal,vol. 19, no. 4, pp. 691–723, 2011.
