4.4.1 Policy Specification
Our policy lattice construction is based on the notion of semantics given in Section 4.2. The protection level provided by a policy can only be measured in terms of the requests that are permitted or denied by the policy.
This is measured by the policy’s provided security level (PSL):
Definition 4.8 The provided security level of a policy P ∈ PS is a relative measure of the access requests P authorises, obtained with the following rule:
∀Pi, Pj∈ PS : PSLPj ≤ PSLPi ⇐⇒ RPYi ⊆ RYPj∧ RPNj ⊆ RPNi
In other words, a policy’s provided security level PSLPi is greater or equal to PSLPj if the set of requests authorised by Piis a subset of the set of requests authorised by Pjand the set of requests denied by Pjis a subset of the set of requests denied by Pi. Not applicable (NA) results do not affect this relationship.
Given a set of sensitivity tags T S and the lattice of data classification labels that their discrete sensitivity levels generate, we associate each (tag, level) pair with at most one policy for each possible action that can be performed on data (multiple policies for the same action can be easily combined into one with a conjunction or disjunction of their individual constraints). Given a data item with a certain classification label, we can therefore determine the applicable policies for all sensitivity domains. In the example of Figure 4.3, the data label {(p,0) (i,1)} indicates that the data is associated with policies Preadp,0 and Pwritep,0 for the privacy domain and with policies Preadi,1 and Pwritei,1 for the integrity domain. However, we must guarantee that the policy lattice implied by the lattice of data labels is well-formed, i.e. that higher sensitivity levels correspond to policies with an higher PSL. In other words, the higher an object classification, the fewer access requests are granted.
To construct such a lattice, we constrain the way policies are specified by users. Rather than directly writing policies that will later be included in a lattice, we let users specify the individual constraints that must hold at each sensitivity level, for each tag. The set of policies associated with a given (tag, level) pair is then constructed as a combination of the individual constraints of all levels up to that one. This restriction ensures a monotonic growth of the constraints that must be satisfied to obtain access at higher sensitivity levels, thus guaranteeing
that the so-created policy lattice is well-formed (see Section 4.4.3 for a more detailed proof). Constraints are specified by defining each tag t as a chain of sensitivity levels:
t: ∗ → ({ f alse}, {true}) → (Dt,1, At,1) → ... → (Dt,n, At,n)
where Dt, j and At, j are sets of compound Boolean expressions ceact (at most one for each possible action act) and n is the maximum sensitivity level for tag t. Dt, j and At, j represent the individual constraints that must hold at every sensitivity level and that will be used to build up the deny and allow constraint sets for policies associated with each (tag, level) pair. The sensitivity levels of a given tag correspond to the PSLs policies must provide to protect data sufficiently. The ∗ level indicates that a security domain is not applicable to the data item, i.e. that the data must never be protected under that domain, whereas sensitivity level 0 indicates that the data is not currently protected. In both cases any action is allowed with no obligations. To include obligations in this model, we can simply redefine a chain of sensitivity levels as:
t: ∗ → ( /0, { f alse}, /0, {true}) → (Ot,1N , Dt,1, Ot,1Y , At,1) → ... → (OtN,n, Dt,n, OYt,n, At,n) where each level is also associated with the supersets OtN,i= {Ot,iN,act
1. . . Ot,iN,act
j} and Ot,iY = {Ot,iY,act
1. . . OY,actt,i
j} of obligatory actions valid at that level. Therefore, each action is associated with two sets of obligations, one for negative and one for positive evaluations.
Given a chain of sensitivity levels for each tag, a set of policies for each action can be determined that are totally ordered according to their PSL, as described in definition 4.8. We define the policy applicable to an action request r = (q, read) ∈ R for a data item with sensitivity level l for tag t as:
Pactt,l(r) =
In other words the deny constraint set for a policy associated with level l and action act, DSlact, comprises all the compound Boolean expressions ceact ∈ Dt,ifor the protection levels lower than l. Similarly, the allow
constraint set for a policy associated with level l and action act, ASlact, comprises all the compound Boolean expressions ceact ∈ At,i for the protection levels lower than l. Note that the equation does not contain any reference to policy subjects or objects. This is because both subjects and objects are identified by the set of constraints that can include conditions on subjects’ and objects’ attributes.
Consider an example privacy domain to protect the personal information of the victims of an accident.
Information should be accessible by all police or ambulance rescuers in the emergency area or in a hospital (privacy sensitivity is equal to 1). However, access to data containing medical information (privacy sensitivity is equal to 2) can be granted only to someone who possesses a first-aid expertise certification or is a paramedic or medic. Also consider the read action as the only possible one. We represent this case by defining two sensitivity levels for privacy:
p: ∗ → ( /0, { f alse}, /0, {true}) → ( /0, Dp,1, /0, Ap,1) → ( /0, Dp,2, /0, Ap,2) associated with the following compound Boolean expressions:
Dp,1= (ceread= {zone 6= hospital ∨ zone 6= emr. area}) Ap,1= (ceread= {(role ≥ Volunteer ∨ role ≥ Constable}) Dp,2= /0
Ap,2= (ceread= {aid exp. = true ∨ role ≥ Paramedic})
where the inequality operators applied on roles are based on an existing role hierarchy (or partial order) where medics are higher-level rescuers than paramedics and volunteers. Hence, the corresponding encoding for the two policies applicable at privacy level 1 and privacy level 2 is:
Preadp,1(r) =
else if r|= (role ≥ Volunteer ∨ role ≥ Constable)
∧(aid exp. = true ∨ role ≥ Paramedic) < Y, /0 >
otherwise < NA, /0 >
The proof that policies corresponding to different levels of the same tag and to the same action are totally ordered on the basis of their provided security level is given in Section 4.4.3.
4.4.2 Policy Ratification
Given the above allow and deny constraint set combination rule, it is possible that redundant policies are created.
Consider a compound Boolean expression at level i requiring that a user has at least a paramedic role and an expression at level j with i < j requiring that a user has at least role medic, where medic dominates paramedic in the considered role hierarchy. In the policy obtained for level j the paramedic condition is redundant and could be eliminated.
In the general case, using a chain of compound Boolean expressions can lead to redundant policies. To avoid a waste of computational resources, it might be useful to reduce a policy to its minimal form, i.e. a form where no conditions can be removed without changing the output of the policy evaluation for any given request. However, finding the minimal form of a constrained Boolean expression, for example using binary decision diagrams (BDDs), is a well-known NP-complete problem [BW96]. It is therefore only possible to apply heuristics for fast reductions. Given a specific Boolean expression representing a policy, we could for example transform it in Conjunctive Normal Form or Disjunctive Normal Form and perform a dominance check between atomic conditions contained in the same conjunct or disjunct, and then a coverage check between distinct conjuncts or disjuncts [AGLL05]. However, this solution has two main drawbacks. First, given our definition of constraint, dominance checks cannot cause the deletion of a constraint that is the only one specified over a specific attribute.
This means that the number of credentials that must be gathered for a policy evaluation would remain the same after a reduction operation. Second, a reduction step might cost more than evaluating redundant constraints.
This is why we do not take any action to reduce policy redundancy. Similarly, a redundant or even conflicting set of obligations (e.g. closing and opening a connection) could be defined. However, conflicting obligations are application-specific in the sense that conflicts depend on the semantic of the involved obligations. This kind of conflicts can be detected and thus solved with existing techniques [CLM+09].
Besides redundant policies, the allow and deny constraint set combination rule we described also allows the specification of inconsistent constraints at different sensitivity levels and thus the creation of policies that deny all requests. However, we do not consider such policies as errors, since it should always be possible to specify situations where a data object must be sealed forever. If this is not the case and data is put out of reach by mistake, recovery mechanisms must be put in place to take the data classification back to a consistent state. As already stated, recovery mechanisms are left for future work.
4.4.3 Lattice Derivation
Once a set of tags has been specified as described above, their totally ordered sensitivity levels automatically generate a lattice where sensitivity classes are actually policy sets. In the following we demonstrate that:
• policy sets are partially ordered according to the PSLs of their individual policies, i.e. the policy lattice is isomorphic to a lattice of data classification labels;
• the set of sensitivity classes, together with the ordering relationship amongst policies (that is equivalent to the flow relation of traditional information flow systems), constitute a well-formed lattice.
Our information flow model is defined by:
PM= hSC, →, ⊕i
where SC is the set of all sensitivity classes (i.e. of sets of Pactt,l policies) and → is a flow relation defined on pairs of sensitivity classes that indicates the permitted information flows. In particular, A → B indicates that any object protected by the policies contained in A can also be protected by the policies contained in B (i.e.
the policies in B are at least as restrictive as the policies contained in A). The third component, ⊕, is a class-combining operator on SC defining how to label information obtained by class-combining information from other sensitivity classes and will be described later. Given our construction, we define → as:
A→ B ⇔ ∀Pactt, j ∈ A ∃ Pactt,i ∈ B | PSL
Pactt, j ≤ PSL
Pactt,i
In other words, B dominates A if and only if for each policy Pactt, j in A there exists at least one policy Pactt,i in Bdefined for the same tag and action and that provides a higher security level. We must now demonstrate that this rule holds for all flow relations created when specifying a set of tags and their chains of sensitivity levels.
For simplicity in the notation we also assume only one action is available.
Demonstration 4.1 Let us consider two policies Pactt,i and Pactt, j such that i≥ j. We must prove that PSL
Pactt,i ≥ PSLPt, j
act. This follows immediately from the construction of the policies. Consider the policy corresponding to the first sensitivity level for tag t:
Pactt,0(r) =
if r.act 6= act < NA, /0 >
else if f alse < N, /0 >
else if true < Y, /0 >
The policy allows every request (and returns an empty set of obligations) and denies none, i.e. RP
N = /0. We call this policy the zero policy. Each policy at successive levels Pt,i∀ i > 0 adds a disjunction of Boolean conditions to the deny rule and a conjunction of Boolean conditions to the allow rule. This increases the number of denied requests and restricts the number of allowed ones, i.e. RP
t,i
From the definition of PSL we can therefore derive that PSLPt, j
act≤ PSLPt,i act.
Note that the solution we are proposing is not the only possible one and different approaches can be taken to order policies according to the definition of PSL we have given.
To show that hSC, →i forms a lattice in our model we must establish that:
• SC is finite;
• hSC, →i is a partially ordered set;
• SC has a lower bound ⊥ such that ⊥ → A ∀A ∈ SC;
• There exists a least upper bound operator on SC, t.
SC is finite as an obvious consequence of the limited set of sensitivity tags and levels (and thus policies) that it is possible to specify. To demonstrate that hSC, →i is a partially ordered set we must demonstrate that the flow relation → is reflexive, transitive and antisymmetric, that is:
• A → A ∀A ∈ SC (reflexivity);
• A → B ∧ B → C ⇒ A → C ∀A, B,C ∈ SC (transitivity);
• A → B ∧ B → A ⇒ A = B (antisymmetry).
Demonstration 4.2 The three properties can be easily proven by proving that they hold when comparing individual policies rather than sensitivity classes. Reflexivity is immediately proven as given a policy Pactt,i, PSLPt,i
act = PSLPt,i
act. Reflexivity then holds for sensitivity classes if it holds for all of their policies. Transitivity can be proven similarly. Given three policies Pactt,i, Pactt, jand Pactt,ksuch that PSLPt,i
act≤ PSLPt, j
actand PSLPt, j act≤ PSL
Pactt,k, the total ordering given by PSLs requires that PSLPt,i
act≤ PSL
Pactt,k for consistency. Finally, given two policies Pactt,i and Pactt, j such that PSLPt,i
act ≤ PSLPt, j
act and PSLPt, j
act≤ PSLPt,i
act, consistency requires that PSLPt, j
act= PSLPt,i
act, proving antisymmetry.
The sensitivity class containing zero policies for all tags acts as the lower bound ⊥ for SC. In fact, for each policy Pactt,i, PSLPt,i
act ≥ PSL
Pactt,0. The least-upper bound operator t can also be easily obtained as the operator
that given two sensitivity classes returns a sensitivity class containing for each tag the highest level in the input classes. In other words the operator returns a sensitivity class associated with the policies with the highest PSL in the input classes, for each tag and action:
Lat Lb(t) =
where Laindicates a label, and thus a tuple of (tag, level) pairs in the lattice isomorphic to the policy lattice and La(t) indicates the numeric value of the label’s sensitivity level for tag t. We can then show that:
• A → A t B and B → A t B;
• A → C ∧ B → C ⇒ A t B → C.
Demonstration 4.3 Both properties are derived from the very definition of t and →. For every policy Pactt,i associated with A, At B is associated with either the same policy, or a policy Pactt, j from B such that PSLPt,i
act ≤
PSLPactt, j, thus proving the first property. If for every policy Pactt,i associated with A and Pactt, jassociated with B there exists a policy Pactt,k associated with C such that PSLPt,i
act ≤ PSL
Pactt,k and PSLPt, j act ≤ PSL
Pactt,k, then At B cannot be associated with a policy with PSL higher then the corresponding policy in C, thus proving the second property.
Therefore, defining a set of tags and their chains of sensitivity levels leads to the construction of a lattice of policy sets. The existence of a greatest-lower bound operator u and of a highest bound > (the sensitivity class containing the policies with the highest possible PSL for all tags) is implied by the above properties. We can thus define u as:
Policies defined for each tag are fully ordered according to their PSLs. Introducing new tags allows us to specify more policies that are relevant for different sensitivity domains and to generate a policy lattice whose minimal element is ⊥ and maximal element is >. Therefore, data can be associated at any moment with a sensitivity class Ld and thus with a set of currently applicable policies PactLd = {Pactt1,l1, Pactt2,l2, . . . Pacttn,ln} for each action, such that an access request r = (q, act) is evaluated as follows:
PactLd(r) =
< N, ON>⇐⇒ ∃Pactt,lt | Pactt,lt(r) = N
< Y, OY >⇐⇒ ∃Pactt,lt | Pactt,lt(r) = Y ∧
¬∃Pactt,lt | Pactt,lt(r) = N
< NA, /0 >⇐⇒ ∀Pactt,lt | Pactt,lt(r) = NA
(4.4)
where ON and OY are the sets of all obligations returned by all policies returning a negative and positive evaluation, respectively. In other words, an access request is not authorised if at least one policy specified for the requested action and associated with the current sensitivity class returns N. Otherwise, if at least one policy returns Y the access request is authorised. This implies that a deny overrides rule is applied whenever different policies return conflicting results. Not applicable results (obtained if all policies from all tags return NA) can be treated differently according to the specific application scenario. A default permission or denial could be returned or decision might be deferred to specific non-conflicting decision policies [JSSS01]. In the remainder of this thesis we will use a default deny policy so that not applicable results correspond to denials.