4 A Data Labelling System for Derived Data Control
4.2 A Notation and Semantics for Policy Languages
Our solution is based on the XACML-based notation and policy semantics used by Rao et al. [RLB+] that we modify to include new constraints and obligations. Also, while Rao et al. (and XACML) consider actions as part of the policy constraints (thus allowing the specification of a policy valid for different actions), we bind actions directly with the policy ID, so that each policy specifies constraints for one action only. As we will see later, this is done to ease the “partial ordering” of policy sets. Intuitively, the notion of policy semantics is defined by the set of requests that are permitted and the set of requests that are denied by the policy. We first give some basic definitions:
• AT T is a finite set of attribute names. Attributes characterise context, data and subjects, have a name ai∈ AT T and a domain of possible values dom(ai). We assume names are unique, so that no ambiguities can arise;
• Op = {>, ≥, =, 6=, ≤, <} is the set of all inequality and equality operators used to compare attribute val-ues; inequality operators can be used only to compare values from ordered or partially ordered domains;
• A is the set of all actions that can be performed. Actions have a name acti∈ A.
For the sake of simplicity, in the following we will ignore the distinction at syntactic level between attributes whose values belong to ordered or partially ordered sets and attributes whose values are not ordered, as the meaning will be clear from the context. We define a request context as:
Definition 4.1 A context q ∈ Q is a set {(a1, v1) . . . (ak, vk))} where a1, a2, . . . ak∈ AT T are attribute names, vi∈ dom(ai) for 1 ≤ i ≤ k are attribute values. Set Q is the set of all possible request contexts.
Intuitively, a request context is the set of subject, object and context attributes that can be verified at the moment a subject requests permission to perform an action on an object. We therefore define an action request ras:
Definition 4.2 An action request r ∈ R is a pair (q, act) where q ∈ Q is a request context and act ∈ A is an action. Set R is the set of all possible action requests.
A policy can then be defined as a function P : R → {Y, N, NA} that given an action request r ∈ R returns a value in {Y, N, NA}, indicating whether the action is allowed, denied or a response could not be determined.
The policy semantics is defined as:
Definition 4.3 The semantic meaning of a policy P ∈ PS is a 2-tuple < RYP, RPN> where RPY and RPNare the set of allowed and denied requests, respectively, and RYPTRPN= /0. Set PS is the set of all policies.
The condition on the disjunction of the two sets RPYand RPNis an internal consistency condition that is enforced by the policy syntax and construction at the base of our solution. The described semantics is general enough to represent several policy languages such as XACML. Similarly, we must define a general policy syntax. To do so we define an atomic Boolean expression and a compound Boolean expression as:
Definition 4.4 An atomic Boolean expression ae can be:
• A constraint on an attribute value of the form ai c where ai∈ AT T , ∈ Op and c ∈ dom(ai);
• A constraint on two attribute values of the form ai aj where ai, aj ∈ AT T , ∈ Op and dom(ai) = dom(aj);
Definition 4.5 A compound Boolean expression ce ∈ CE is the association of a set of atomic Boolean expres-sions via the logical operators∧ and ∨. Set CE is the set of all compound Boolean expressions.
Examples of compound Boolean expressions are: (time < 8am ∨ time > 8pm) and (role = manager ∧ location= South Kensington Campus). We specify a policy as:
Definition 4.6 A Policy P ∈ PS is a tuple (act, DSact, ASact) where act ∈ A is an action and DSact ⊆ CE, ASact ⊆ CE are respectively a deny constraint set and an allow constraint set, containing the conditions that must hold to respectively deny or allow an action request.
In other words policies specify a set of constraints over typed attributes whose values range over predefined domains. Policy decision can then be defined as a function Pact(r) (Figure 4.1) that given an access request r
Figure 4.1: Function representing the policy evaluation process
substitutes free variables in its Boolean formulae with values from r’s context and returns an access decision depending on whether the disjunction and conjunction of compound Boolean expressions in the deny and allow constraint sets evaluate to true. Also, we consider that the evaluation procedure is based on the closed world assumption, so that atomic Boolean expressions are evaluated to false if r’s context does not provide a value for any of their variables. For the sake of simplicity, we did not include a negation symbol in the notation, since negation is implicitly included in the atomic expressions. Note that the ordering of evaluation of the policy expressions implies a deny overrides rule for conflict resolution. We decide to support both negative and positive authorisations as exceptions often need to be dealt with (e.g. denials for large groups of users but few [SdV00]). The not applicable (NA) return value is introduced as not all policies might be applicable to all requests. In this sense, NA cannot be treated as a default denial or permission as it would disrupt the result given by other applicable policies. Consider for example a policy P1granting access to Alice only and a policy P2 granting access to Bob only, both associated with the same data item. When Alice files an access request, P1will return Y and P2will return NA. If the result returned by P2 was considered N by default and the conflict resolution strategy were a deny override strategy, Alice would be denied access. The NA result is instead ignored and does not have any effect on the final access decision. Default decisions can instead be applied if no policies are applicable to a specific access request, i.e. if all policies return NA, as we will see later.
This particular representation might seem redundant as compound Boolean expressions could be used rather than constraint sets to represent policy constraints. However, this format eases the lattice construction we will introduce later and still allows users to specify any Boolean expression as access constraints. In other words, this makes the notation with which we specify how policies are organised simpler. Usage control requirements
such as obligations and continuous controls can also be introduced. We can define obligations as:
Definition 4.7 An obligation o ∈ O is a procedure call act(parameters) where act is an action to be performed before access to data is granted. Set O is the set of all obligations.
In this sense, the semantics of obligations is the same considered in the XACML model. Obligations can be easily introduced in the definition of a policy function as:
Pact(r) =
where policy decisions also contain the corresponding set of obligations that must be performed when request-ing access. As for the other constraints, obligation’s free parameters are also substituted with values from r’s context. As we have already described in Chapter 3, obligations are intended as procedures to be automatically performed by the PEP when receiving the policy evaluation result from the PDP and before granting access to the data. If there are errors during the execution or the obligation cannot be performed, the PEP denies access (even if the policy result was Y ) and logs the failure. In this way the system is never in an inconsistent state as only the completion of an obligation is considered as the “committing time” for policy decision and decryption key release. Policies can thus be represented as (act, {o1. . . ok}Y, ASact, {o1. . . ok}N, DSact) tuples.
Continuous controls (i.e. the monitoring of specific conditions throughout the whole duration of the access to the data that could invalidate the original policy decision and revoke the access) do not need to be included in the notation as attribute monitoring depends on the enforcement mechanism rather than on the policy model and simply consists of a continuous re-evaluation of the same policies. In other words, after access has been granted, the PEP keeps requesting a new policy evaluation to its local PDP at regular intervals (depending on the system’s configuration) or whenever the value of an attribute used in the policy changes, so that access can be revoked if the policy evaluation result changes into a denial. More complex conditions could be specified where only certain attributes and conditions need to be monitored. However, this is a matter of optimisation rather than modelling since it simply allows the PEP to request re-evaluations of only a subset of policies. Note that this differs from the UCONABC model where ongoing obligations can also be specified (i.e. obligations
to be performed at regular intervals during the access). In our implementation, obligations are performed only once when access is requested and policy re-evaluation does not force the PEP to perform them again. We stress that the inclusion into our model of such additional controls would be straightforward, but we did not do so as this type of obligations have been already treated in other works [PS04, CLM+09] and are beyond the scope of this thesis.
An example policy for the crisis management scenario described in Section 1.3 to protect personal informa-tion of victims in the accident area may state that access should be granted to all police or ambulance rescuers in the area or in a hospital and that such access should be logged. Such policy can be specified as:
Pread(r) =
if r.act 6= read < NA, /0 >
else if r|= zone 6= hospital ∨ zone 6= emr. area < N, /0 >
else if r|= role ≥ Volunteer ∨ role ≥ Constable < Y, {(log(“read”, role, name, dataID)} >
otherwise < NA, /0 >
where we assume rescuers are organised in two role hierarchies, one for the ambulance services and one for the police force whose leaves are volunteers and constables, respectively. Note that the policy does not specify any target. While the compound Boolean expressions might simply include conditions to identify target objects (e.g. an equality condition on a document ID or document type) we decided not to do so because policies are associated with objects through sensitivity levels, as we will describe later. Similarly, the action may be included in the compound Boolean expressions rather than be bound directly to the policy ID. This would make for a simpler notation. Our choices come from the need to strictly organise policies and will be clarified later.