In case of collaborative modeling, complex systems are developed by di erent stakeholders. To guarantee security, access control policies need to be enforced during the collaboration. Levels of required con dentiality and integrity may vary across modeling artifacts, and even features of a single model element. Fine-grained rule-based access control was proposed to meet the needs of exible and concise access control. Rulebased policies are inherently subject to con icts between the rules; these con icts should be interpreted in a consistent but also predictable way that caters to the preferences of the policy engineer. We propose a deterministic, parameterizable resolution strategy between con icting rules to calculate e ective access permissions for each fact in the model. Our approach is illustrated using a case study of the MONDO EU project.
The adoption of model driven engineering (MDE) by
system integrators (like airframers or car manufacturers) has
been steadily increasing in the recent years [
This paper is partially supported by the EU Commission with project MONDO (FP7-ICT-2013-10), no. 611125. and the MTA-BME Lendulet 2015 Research Group on CyberPhysical Systems.
Collaboration scenarios include traditional o ine
collaborations with asynchronous long transactions (i.e. to check
out an artifact from a version control system and commit
local changes afterwards) as well as online collaborations with
short and synchronous transactions (e.g. when a group of
collaborators simultaneously edit a model, similarly to
wellknown on-line document / spreadsheet editors). Several
collaborative modeling frameworks (like CDO [
However, such collaborative scenarios introduce signi cant challenges for security management, both in terms of con dentiality and integrity. For instance, the detailed internal design of a speci c component needs to be hidden to competitors who might supply a di erent component in the overall system, but needs to be revealed to certi cation authorities in order to obtain certi cation proofs and credits. On the other hand, there are highly critical aspects of the model that may only be modi ed by (or with approval from) specialists having the appropriate quali cations.
Capturing security policies on the storage ( le) level instead of the model level results in in exible fragmentation of models in collaborative scenarios; this can be solved by ne-grained access control, where each model element and its features can have its own set of permissions. On the other hand, large industrial models can have millions of model elements, thus explicitly assigning permissions for each of them, as well as maintaining the permissions after changes to the model, would be labor-intensive and error-prone, and would make it di cult to understand the system of privileges.
A rule-based approach for concisely de ning ne-grained
model access control policies has been proposed in [
However, due to this implicit nature, it is possible that several rules would be in direct con ict with each other, assigning contradictory nominal permissions for some model element. It is also possible for rules to con ict indirectly, if the fragment of the model revealed to a user in not consistent with itself, or with the allowed write operations.
In either case, the access control mechanism must resolve con icts in a deterministic way by deriving the e ective permissions from the nominal ones, to present a consistent and secure updateable view to each user. 1.2
The main objective of the paper is to propose a con ict resolution technique to support secure collaboration based id : EString frequency : EInt documentation : EString
ConfidentialSignal
Cycle
low
medium
high
on a rule-based ne-grained access control policy, as
proposed in [
In this paper, we propose a con gurable, multi-stage conict resolution approach that considers internal and external propertiesof rules, as well as dependencies among the assets they apply to, when determining their precedence. We demonstrate the applicability of the proposed approach on a case study.
Our con ict resolution concepts will be illustrated using
a simpli ed version of a modeling language for system
integrators of o shore wind turbine controllers, which is one of
the case studies of the MONDO EU FP7 project [
A sample instance model containing a hierarchy of 3 Composite modules with 4 Control units as submodules, providing 6 Signals altogether where two of them are Confidential Signals, is shown on Fig. 2. Boxes represent objects (with attribute values as entries within the box). Arrows with diamonds represent containment edges, while arrows without diamonds represent cross-references. Di erent type of lines, boundaries and letters in squares are related to the granted permissions that will be discussed later during the paper. 2.2
Designing wind turbine control units requires specialized knowledge. There are 3 kinds of control units, and each kind can only be modi ed by specialist users with the appropriate quali cation: heater, pump and fan control engineers. Specialist are not allowed to modify (and in some cases, read) parts of the model that would require a different kind of quali cation. For this purpose, the following security requirements are stated in relation with control unit specialists: R1 Each group of specialists shall be responsible for a speci c kind of control unit (owned control units).
R2 Specialists must see only those signals that are in scope for their owned control units, i.e. signals provided by a module that is either (a) a composite that directly contains an owned control unit, or (b) any submodule (incl. the owned control unit) contained transitively in such a composite.
R3 Specialists must be able to modify signals provided by their owned control units.
R4 Specialists must see which modules consume signals provided by their owned control units.
R5 Specialists must not able to see con dential signals. 3. 3.1
In our previous work [
Attribute facts are triples formed of a source EObject, an attribute name (EAttribute) and the attribute value, for each (non-default) attribute value assignment; e.g. attr(c1, vendor,B).
Reference facts are triples formed of a source EObject, a reference type (EReference) and the referenced EObject, for each containment link and cross-link between objects; e.g. ref(c1,consumes,s4).
Note that there are multi-valued attributes and references, where an EObject is allowed to host multiple attribute values (or reference endpoints) for that property. For such properties, each of these multiple entries at a source EObject will be represented by a separate attribute (or reference) model fact. Moreover, there are opposite references de ned as a pair of references where the existence of a relation depends on its pair. For example, the opposite of a containment reference eContainment is the container reference eContainer.
These model facts are the assets that the access control policy will protect; though there are a few deviations from one-to-one correspondence, such as a reference and its opposite reference (if exists) are considered a single asset. 3.2
Obfuscation is de ned as the process of "making
something less clear and harder to understand, especially
intentionally". The rst purpose of obfuscation in programming
was to distribute C sources in an encrypted way to prevent
the access to con dential intellectual property in the code
[
A model obfuscator such as VIATRA Model Obfuscator
[
Several publications [
In the context of access control, obfuscated data describes the existence of a model fact (e.g. a value is assigned to the attribute of an object), but the meaning of that fact remains secret. Additionally, when only the existence of object needs to be presented, its identi ers would be obfuscated while the other features are hidden (if the object is identi ed by a set of its attribute values e.g. in our example language Fig. 1, where each object is identi ed by an id attribute). Hence, the correspondences between the objects of the original model and its secure view remains. 3.3
In [
For example, Lst. 1 describes security rule permitControl
to ful ll security requirement R1. Here objectControl
represents a graph pattern in EMF-IncQuery [
pattern objectControl ( ctrl : Control ) { HeaterControl ( ctrl ); } rule permitControl allow RW to HeaterCtrlEng { query : objectControl }
Lst. 2 introduces rules that ful ll the remaining security requirements without a detailed description of the queries as it is out of the scope of this paper. Security requirement R2 is covered by rule viewSignal that would grant read permission for signals s3, s4, s5 and s6. Rule editSignal would allow the editing of signals s3 and s4 described in security requirement R3. Rule viewConsume would permit the readability of references ref(ctrl1,consumes,s3), ref(c1,consumes,s3) and ref(c1,consumes,s4) to satisfy security requirement R4. Finally, rule denyConfSignal denies the visibility of con dential signals s4 and s6 required by security requirement R3.
Listing 2 Rule De nitions for the Example rule viewSignal allow R to HeaterCtrlEng { query : ... } rule editSignal allow W to HeaterCtrlEng { query : ... } rule viewConsume allow R to HeaterCtrlEng { query : ... } rule denyConfSignal deny R to HeaterCtrlEng { query : ... } 3.4
An arbitrary set of model facts does not necessarily constitute a valid model; there may be internal consistency constraints imposed on the facts by the modeling platform to ensure the integrity of the model representation and the ability to persist, read, and traverse models. Goal G2 requires that secure models must be synthesized as a set of model facts compatible with all internal consistency rules.
We distinguish these low-level internal consistency rules from high-level, language-speci c well-formedness constraints. Violating the latter kind does not prevent a model from being processed and stored in the given modeling technology, as error markers can be placed on such violations. Thus only internal consistency is required for access control. Object Existence Attributes and references imply that the objects involved exist, having a type compatible with the type of the attribute or reference.
Containment Hierarchy Objects must either be root objects of the model, or be transitively contained by a root object via a chain of objects that are all existing. Opposite Features For reference types having an opposite, reference facts of the two types come in symmetric pairs.
We classi ed the con ict types into 3 category represented in Table 1 based on the asset on which the rules are applied and the operation (read,write) they want to grant or deny. Multiplicity Constraints Number of a speci c references of an object needs to satisfy the multiplicity constraints. 3.5
Fig. 2 contains markers to describe the ltered model presented to the heater control engineer. The user can modify the two objects marked with blue label and bold outline (ctrl3 and s3), and can additionally see the signal with orange label and dashed outline (s5). Objects with white label and dashed outline are hidden (ctrl2, s1, s2, s4 and s6) which implies that their attributes are unreadable and unmodi able. Objects (root, ctrl1, c1, c2, ctrl4) that contain other visible objects, but must themselves be unreadable, appear with identi ers obfuscated id (marked with an O in a square), and their other attributes hidden (marked with an H in a square). Dashed edges are hidden references, thin edges are readable, while thick edges are writable.
To meet goal G3, the policy language provides parameters to ne-tune the con ict resolution.
Default Read When none of the rules specify the read access of an asset, the default read value will be used. It can be allow, obfuscate, deny.
Default Write When none of the rules specify the write access of an asset, the default write value will be used.
It can be allow, deny.
Con ict Resolution For con ict resolution, the strategy should decide between a permissive or a restrictive resolution. In case of permissive resolution, rule that allows an operation takes precendence over a denial rule. But, the restrictive resolution prioritizes denying rules over allowing ones.
Moreover, these values shall be speci ed on global, user and root levels to de ne di erent type of rules for each user and model. Root level settings are the most speci c settings that associate the values with the root objects of a model. User level settings are connected to the current user and are applied when there are no root level settings for a root object. Finally, global level settings are the most general ones independent from the users and root objects and applied if there are no default values are speci ed. This means, global settings are mandatory, but user and root are optional.
For the running example, user speci c default values are set as follows: read and write operations are denied by default and a restrictive con ict resolution will be used. 5.1
Several rules can state contradict permission levels for the same assets. Moreover, the read and write operations of an asset may depend on other assets by consistency rules. These con icts have to be resolved in order to obtain the con ict-free e ective permissions which are actually enforced. Type I. A con ict of Type I. appears when two or more rules apply to the same asset and specify di erent permission levels for the same operation. For example, rule viewSignal allows the read operation of con dential signal s4, but rule denyConfSignal denies it. Type II. A con ict of Type II. appears when two or more rules apply to the same asset but on a di erent operation. For example, rule editSignal allows the write operation on con dential signal s4, but rule denyConfSignal denies the read operation on con dential signal s4.
Type III. A con ict of Type III. appears when two or more rules apply to di erent assets that depend on each other (see Sec. 3.4). For example, rule viewConsume allows to see the consumes reference from composite module c1 to con dential signal s4, but security requirement denyConfSignal denies the visibility of con dential signal s4.
An asset cannot both be readable and hidden; neither can it be both writeable and unmodi able at the same time. Naturally, when two or more di erent permission levels are applied to the same operation type (read/write) of the same asset, a con ict occurs.
Example. In our running example, rule viewSignal allows to read signal s4, but rule denyConfSignal denies to read it (depicted in Fig. 3).
In case of di erent operations, we have to discuss the conicting combinations of read and write permissions. As Table 2 shows, most of the cases are valid. On the other hand, if an asset is writable then it has to be readable while an unreadable asset cannot be writable. Moreover, giving write permission to an obfuscated asset is questionable. It should mean that the users are only allowed to set obfuscated values which is not common in practice. Our approach works well regardless whether this combination is allowed or not.
Example. Back to our example, rule editSignal allows to write object s4, but denyConfSignal denies to read it (depicted in Fig. 4). Note that when the former rule dominates both the read and write permissions are granted.
An object asset can be in con ict with its attributes and references. Moreover, we re ne the list of assets introduced in Sec. 3.3 with opposite, containment and identi er assets.
An opposite asset is a pair of reference facts that are each others opposites. Both of them must have the same permissions. Containment asset is also a special reference asset de ning parent and child relation between two objects. A chain of containment assets describes a containment hierarchy. Identi er asset is a set of attribute facts that identi es an object.
Read Dependency Readability of an object can be in con ict with one of its attributes when the attribute is readable/obfuscated but the object is unreadable.
In case of a reference, its source and target objects have to be taken into account. When a reference has to be readable, both of its source and target objects have to be readable too. Conversely, if either of the source and target object are unreadable references between them have to be invisible.
When an object asset o is readable its parent and the container reference have to be visible as well. This means that all the objects have to be visible in the containment hierarchy until o. Conversely, when a containment reference asset is invisible, none of its children should be visible.
In addition, if an object is visible all of its identi ers have to be visible, and conversely, if any of the identi ers is not visible, the object has to be invisible. Moreover, if an object is present in the ltered model solely to satisfy the dependencies of other assets (contained objects, reference links) and not because an explicit rule, it should be obfuscated.
If an object is explicitly obfuscated by the rules, or due to dependencies as explained above, its identi er attributes shall be obfuscated and other attributes need to remain hidden by default.
Finally, in case of a readable object, all of its features are also readable by default. However, this is merely a weak consequence: rules can speci cally override this default for each feature.
Example. Application of rule viewConsume makes the consumes reference between control unit ctrl1 and signal s3 visible (depicted in Fig. 5). Signal s3 is readable because of the application of rule viewSignal, but control unit ctrl1 which is the source of the reference is invisible by default. Internal consistency constraints demand to make ctrl1 visible. It also implies that the composite module root which is the container of ctrl1 needs to be visible. Write Dependency Write permission means that the asset can be modi ed. In case of a writable/unwritable object, all/none of its features are writable by default. Once again, rules can speci cally override this default for each feature.
When an object asset is writable it does not mean that it can be deleted. For that behavior, the containment reference that holds the object must also be modi able. When a containment reference is writable, all of its children can be deleted (if they themselves are writeable) or moved to under another containment reference (if the other containment reference is also writable).
If an identi er is modi ed, it is equivalent to an object being deleted and a new one created at the same place. This also means that a containment reference is deleted and a new one is created. Thus, if any of the identi ers is writable the containment reference has to be writable. And if a containment reference asset is unmodi able, none of the identi ers are writable.
Read vs. Write Dependency Writable assets have to be visible. Hence, we investigate con icts between readable assets associated with the same object asset. Thus read and write dependent con icts are special cases of resolving read dependencies.
Multiplicity Constraints The presented con ict resolutions handle the following internal consistency constraints: object existence, containment hierarchy, opposite features described in Sec. 3.3. Now, we investigate the multiplicity constraints. Multiplicity of a feature type de nes the number of possible target values or objects and consists of a lower and upper limit ([lower]::[upper]). However, not all type of multiplicity constraints are supported by our approach. 0..* If there are no multiplicity restrictions, the presented approach works well without further considerations.
0..m This type of multiplicity constraint de nes an unsettable feature (attribute or reference) may have up to m values per object, where m is a nite integer (typically 1). Applying read permissions may only decrease the number of model facts in the ltered model, thus this multiplicity constraint is met in the secure view regardless whether the value is readable, hidden or obfuscated. However, for a given object with one or more feature values that are invisible to the user (the security rules deny the read permission to the asset formed by the speci c feature value), write access control must prevent the user from adding new values to the feature (even if the security rules would allow write permissions for model fact formed by the new value) if, together with the hidden values, they would exceed the upper limit in the un ltered model.
1..1 This type of multiplicity constraint de nes a feature where a value must always be set. If the user is not allowed to read the associated model fact, then an obfuscated (and unmodi able) value must be provided so that the secure view is a consistent model. For instance, the identi er of a visible object cannot be hidden, only obfuscated.
k..m This rare type of multiplicity constraint de nes a feature with at least k 1 and at most m > 1 values per object, where m can be unlimited. It implies that at least k distinct values need to be visible to the user, but if fewer than that number are readable, there is no self-evident deterministic way for selecting a subset of hidden values for obfuscation. Therefore our approach is only applicable if no such feature values are hidden from the user when the host object itself is visible. 5.2
5.2.1
The set of priority classes is totally ordered using > , i.e. from any two classes, one of them has higher priority. Each rule is assigned an (external) priority class, but multiple rules can be in the same class; in fact, we expect to commonly nd policies where all query-based rules share the same priority class.
The permission levels for an operation are totally ordered according to permissiveness, i.e. LevelsW = fdenyW <W allowW g and LevelsR = fdenyR <R obf uscateR <R allowRg. In case further re nements to the permission model is necessary, it would be fairly easy to extend our approach so that the ordered set is replaced with a nite lattice.
Detecting con icts relies on the notion of Galois connections. For partially ordered sets A and B, a (monotone) Galois connection is an ordered pair hf; gi of monotone (orderpreserving) functions, the lower adjoint f : A 7! B and the upper adjoint g : B 7! A, with the property that f (a) > b , g(b) < a (or equivalently, f (a) b , g(b) a). Intuitively, f (a) puts an upper bound on B-values that are related to a in a certain way, while g(b) is a lower bound for A-values that have this same connection with b.
A key observation is that the compatibility matrix (see Table 2) between the read and write permissions of a single asset encodes such a Galois connection; this is a consequence of the fact that an incompatible pair of read and write permission levels can always be made compatible either by choosing a more permissive read or a more restrictive write level. In other words, for each read permission level pR 2 LevelsR, there is a corresponding write permission level dpRe such that pR is compatible with write permission level pW if and only if pW W dpRe. Dually, for each pW 2 LevelsW , there is a bpW c such that pW is compatible with a read permission level pR i bpW c R pR. Concretely, ddenyRe = denyW , dallowRe = allowW , bdenyW c = denyR, and ballowW c = allowR or obf uscateR (the adjoint of obfuscation is left open by the Table). This will be useful for resolving type II con icts. 5.2.2
In the context of determining permissions for a given user, we treat lower bounds (e.g. \this object must be visible, at least in an obfuscated form") and upper bounds (e.g. \this object must not be completely readable, it may be obfuscated at best") on a permission level as separate judgements.
We de ne a permission set as a set of judgments, where each judgment j is a tuple j = ha; o; p; ; i, where a 2 Assets is an asset, o 2 fR; W g is an operation (read or write) to be performed on the asset, p 2 Levelso is a permission level associated with the operation, 2 = f>; <g indicates whether the judgment puts that permission level as an upper respectively lower bound for the nal permission decision, and 2 is a priority class. A valid permission set is complete, i.e. for each asset and operation, it must contain at least one upper bound and one lower bound judgment, and by the ordering of permission levels, the lowest (strictest) upper bound must not be higher than the highest (strictest) lower bound.
The initial permission set is obtained from rules and defaults. For all assets and operations, default permissions are included as a pair of judgments (one upper bound, one lower bound, both with the same permission level), with a priority class that is lower than the priority of any query-based rule; this ensures completeness. For each match of the queries of security rules that apply for the user, a pair of upper and lower bound judgments are added; the asset is given by the pattern match, and the operation, priority class and permission level are determined by the rule header. While not discussed in this paper, it is possible to have rules that impose e.g. an upper bound only.
The goal is to derive the resolved permission set, where the highest (most permissive) lower bound is equal to the lowest upper bound for each asset and operation (thereby identifying a single permission level as the e ective permission), and there are no con icts (due to sanity or dependencies) between the judgments. Sec. 5.2.3 will discuss how con icts are formalized. 5.2.3
Con ict detection is the task of determining which judgments contradict which ones. For upper bound judgment j> and lower bound judgment j<, we denote their con ict by j> 6w j<. The symmetric relation j 6 j0 := j 6w j0 _ j0 6w j denotes a con ict where either of the two judgments can be the upper bound. Compatibility (the lack of con ict in either direction) is denoted by the symmetric relation j j0.
Con icts are detected in the following cases (excerpt), always between an upper bound and a lower bound judgment:
Type I. ha; o; p; >; i 6w ha; o; p0; <; 0i i p < p0; i.e. occurs if there are contradictory judgments for the same asset and operation.
Type II. ha; R; pR; >; Ri 6w ha; W; p0W ; <; W0 i i pR <R bp0W c (equivalently dpRe <W p0W by the identity introduced above); i.e. occurs if the read and write judgments for the same asset are incompatible.
Type III. ha; R; pR; >; Ri 6w ha0; R; p0R; <; R0i for a 6= a0 i one of the following cases is true: (A) a = obj(x; ) ^ a0 = ref (x; 0; y) ^ (pR = denyR ^ p0R 6= denyR); i.e. a reference link asset is visible, while its source endpoint isn't. (B) a = ref (y; ; x) ^ a0 = obj(x; 0) ^ (pR = denyR ^ p0R 6= denyR), where is a containment edge type; i.e. an object asset is visible, while the containment link that holds it isn't. (C) etc. (See for Sec. 5.1 informal description of all cases.)
Note that the permission-related conditions in cases III/A and III/B can be rephrased as (pR <R L(<a;o);(a0;o0)(p0R)), where the function L(<a;o);(a0;o0)(:) is de ned as
< L(a;o);(a0;o0)(p0R) = (denyR;
if p0R = denyR obf uscateR; otherwise L(>a0;o0);(a;o)(pR)), where The equivalence stands as there is no read permission level more restrictive than denyR, only the lower branch of the function de nition will lead to actual con icts. We can also reason about the dependent asset based on its dependency asset; the statement is further equivalent to (p0R >R > L(a0;o0);(a;o)(pR) = (denyR; if pR = denyR
allowR; otherwise Note that the two newly introduced functions are distinguished by having di erent ordering directions in their superscripts; and that the subscript identi es rst the assetoperation pair whose permission is restricted in that direction, and second the asset-operation pair whose permission level determines the threshold.
In this case, functions L(<a;o);(a0;o0)(:) and L(>a0;o0);(a;o)(:) play a similar role than b:c respectively d:e do in type II con icts. Thus for each dependency between asset-operation pairs, we have such a pair of functions that form a Galois connection.
For uniformity in case of type II con icts, let bp0c = L(<a;o);(a;o0)(p0) and dpe = L(>a;o0);(a;o)(p). Likewise, introducing L(<a;o);(a;o)(p) = L(>a;o);(a;o)(p) = p for type I conicts, we can treat all three kinds of con icts uniformly, using the mathematical foundation of Galois connections. Finally, for the cases where two assets have no dependency, L(<a;o);(a0;o0)(:) and L(>a0;o0);(a;o)(:) are de ned to take the most respectively least restrictive value, so that they will not indicate con ict for any permission levels.
Using this notation, the following three statements are equivalent: ha; o; p; >; i 6w ha0; o0; p0; <; 0i p < L(<a;o);(a0;o0)(p0) p0 > L(>a0;o0);(a;o)(p) Essentially, con ict occurs if and only if the upper bound judgment is too restrictive to be compatible with the lower bound one, or equivalently, the lower bound is too permissive to be compatible with the upper bound.
As a judgment imposes compatibility constraints on its dependencies, its consequences can be propagated and directly represented as additional judgments on foreign asset/operation pairs. Using the propagated consequence judgments, all con icts can be transformed into type I con icts.
For judgment j = ha; o; p; ; i of bound 2 = f> ; <g, with ha0; o0i as a dependency, the propagated strong consequence judgment is de ned as jha0;o0i := ha0; o0; l; ; i where l = L(a0;o0);(a;o)(p). By the equivalent forms of con ict stated above, it follows that for any j0 = ha0; o0; p0; 0; 0i, j 6 j0 i jha0;o0i 6 j0, where the latter is a type I con ict, expressed on the same asset and operation.
Extending the above notion, is also possible to propagate weak consequences that encapsulate a default e ect of a given judgement, not a necessary condition. For example, all contained elements of a visible object should also be made visible by default - unless another rule denies the read permission. A weak consequence does not inherit the priority of the original judgement, but is assigned a lower priority instead, and may be overridden by more dominant judgements without con icting with the original judgement. It can be formally captured as jha0;o0i := ha0; o0; l ; ; i with l = W(a0;o0);(a;o)(p) (where W(a0;o0);(a;o) is not necessarily a Galois connection). We propose to assign a priority class to these weak consequences that is lower than the priority of any user-speci ed rule, but higher than the priority of global defaults that such a weak consequence may override. 5.3
Computing the e ective permission requires us to resolve the con icts and provide a consistent secure view of the model. If there are con icts, it is inevitable that some rules will not fully apply to all assets identi ed by their query, but rather will be overruled by other, more dominant rules on some assets. There are two ways to compare rules in order to determine which one will dominate, as explained below.
External Priority Rules may be decorated with external priority information, where the policy engineer directly expresses which rule shall dominate over which one.
Internal Priority In case of two rules belong to the same priority class, we can still compare them based on the permission level they apply. Between the permission levels, we de ned a precedence order: deny < obfuscate < allow. Based on this precedence, either the most restrictive (min) or the most permissive (max) rule can be selected as dominant, as per preferences of the policy engineer.
Example. As we introduced in Sec. 3.3 a restrictive con ict resolution is used in the running example. In the con ict of Fig. 3, the deny permission level is more restrictive than allow, thus signal s4 remains hidden from the secure view. 5.4
5.4.1
Con icting rules may dominate each other either by external priority, or, if they share a priority class, by internal priority. Thus within each priority class for rules, either the more permissive or the more restrictive rule is considered dominant, by discretion of the policy engineer. For each priority class 2 , one of the bounds 2 = f>; <g is given to indicate dominance; e.g. if is >, restrictive judgments will dominate over permissive ones in the same equivalence class.
Thus using and the Galois connections discussed in Sec. 5.2.1, we can now introduce the following domination relation between two con icting judgment: if j 6 j0 for j = ha; o; p; ; i and j0 = ha0; o0; p0; 0; 0i, j j0 := ( >P 0) _ ( = 0 ^ = )
Observations: (a) the domination relation introduces a partial ordering among judgments, (b) two con icting judgment are related by this domination relation one way or the other, i.e. one of them is always dominant over the other.
A resolution step takes two judgments that are in a Type I con ict, compares them using the dominance relation, and modi es the dominated judgment to make it compatible with the dominant judgment. For j = ha; o; p; ; i and j0 = ha; o; p0; 0; 0i with j 6 j0 ^ j j0 the con ict resolution replaces j0 with j00 = ha; o; p; 0; 0i. Executing such a step transforms a permission set to a di erent one. Observations on the resolution step: j00 relaxes j0, i.e. upper bounds are raised when replaced, while lower bounds are lowered. j00
j is guaranteed by the construction.
The resolution step upholds the completeness of the permission set. 5.4.2
The resolution process (see Alg. 1) iterates over judgments in the order of domination, to propagate their consequences (also the weak consequences, unless contradicted by a previously processed judgement) and resolve any type I con icts they are in.
Algorithm 1 The resolution process in pseudocode
We have the following success criteria against the resolution process, derived from the goals stated in Sec. 1.2:
Correctness the process must yield a resolved permission set upon termination.
Con uence in order to work predictably and deterministically, the e ective permissions must be completely determined by the user in question, the model and of course the policy.
The presented algorithm is terminating, as (for given assets) there is a nite space of possible judgments, each of which is processed at most once.
Once a judgment j has been processed, it will not be removed from the permission set anymore, as all judgments that could potentially dominate it have already been processed, and neither propagation nor resolution would create such dominating judgments anymore. It will not enter into new con icts as the dominating party either, since all of its consequences have been propagated, so any judgment that would propagate a strong consequence that would be dominated by it, would never be processed, but would have previously been removed in a resolution step. Note that weak consequences are not propagated if they would create a con ict with an already processed judgement.
When a judgment is processed, its local (type I) con icts are resolved; as it cannot enter new con icts, there will be no more type I con icts when the process terminates. This also means that there are no more con icts of any type, since all strong consequences have been propagated. All the while the completeness of the permission set is maintained, thus the end result is a resolved permission set, and the process is correct.
Note that when processing a judgment, the associated propagations and resolutions yield deterministic results. Thus con uence requires that the end result is the same regardless of the order that judgments are selected for processing in chooseDominant(.). The process has free choice only between judgments that do not dominate each other; in this case they are of the same priority class and bound, so the end result will contain all of their transitive consequences (with no domination between them), and con icts will be con uently resolved to be compatible with the conjunction of all these judgments, independently of the order of steps. 5.5
The e ective permissions calculation on the running example works as follows.
Initialization Before all, the initial permission set is determined. The default judgements are assigned to the model assets, which deny read and write operations for each element, as described in Sec. 5.4.2. Then each query-based security rule in the policy is evaluated on the model, and judgments to override the default values are created for the assets that are identi ed by query results.
permitControl allows read and write operations for obj(ctrl3, Control). viewSignal allows read for obj(s3, Signal), obj(s4, CondentialSignal), obj(s5, Signal) and obj(s6, Con dentialSignal). editSignal allows write operation for obj(s3, Signal), obj(s4, Con dentialSignal). viewConsume allows read for ref(ctrl1, consumes, s3), ref(c1, consumes, s3) and ref(c1, consumes, s4). denyConfSignal denies read and write for obj(s4, CondentialSignal) and obj(s6, Con dentialSignal).
We place all the above query-based rules in a single priority class 1 (superior to both default permissions and weak consequences), and select the restrictive con ict resolution type speci ed in Sec. 3.3, i.e. 1 => so that upper bound judgements dominate.
As a result, judgements based on denyConfSignal take precedence above all other rules, and are picked rst for being processed. The viewSignal and editSignal judgements on s4 and s6 are in type I con ict with these more dominant denials, and are thus overridden - the con dential signals remain hidden.
The denial judgements are propagated to dependencies: since s4 and s6 are hidden, any provides or consumes references pointing to them must also remain hidden. These propagated strong consequences have the same priority class and are also upper bounds on permissions, so they dominate over e.g. viewConsume. Thus these con icts will be resolved next by relaxing the existing lower bounds, thereby hiding the references.
Next, judgements from the other ve rules (except where overridden by the denial) are selected as dominant ones, and they propagate strong consequences. For instance, the visibility of ref(ctrl1, consumes, s3) has not been overridden by the denial of con dential signals, so its starting point ctrl4 must be present at least in an obfuscated form, thus the propagated strong consequence is a lower bound judgement of the same priority class. Similarly, s5 remained visible, so its containing object ctrl4 must be at least obfuscated, which in turn will propagate as additional lower bounds on the visibility of c2, c1 and nally the root. These propagated strong consequences will override the default judgement of hiding these objects. And as a consequence of having these objects visible but obfuscated, the identi er attributes (such as the id of c2) will also be visible with obfuscation; non-identi er attributes such as vendor remain hidden.
At the same time, as read access was granted to objects ctrl3, s4 and s5 (and not overridden by denyConfSignal), they propagate their weak consequence of making all their attribute values, contained objects and outgoing references visible, unless precluded by any rule (e.g. in case of s4). As ctrl3 and s3 are also writable, their attributes are made writable by default as well.
Finally, the default judgements, where left intact, are processed. They neither override any judgements nor propagate meaningful consequences. For example, s4 kept the default permissions denyR and denyW .
We think that the properties of the resulted secure model is worth to discuss. In the example, the heater control engineer can see only control unit ctrl3, signals s3 and s5. The rest of the objects are obfuscated or hidden, thus no con dential information is presented to the user. Furthermore, control unit ctrl3 and its signal s3 are editable and removable. However, the user cannot delete these object in the current state of the model, because the consumes references pointing to s3 are only readable. Removing the control unit or the signal would also imply that the consumes references be removed from the model, but these operations are denied. Thus the specialist needs to collaborate with the other engineers and cannot delete on their own those elements from the model on which other users depend. On the other hand, our specialist can create a new heater control unit under composite c1, and the signal can be moved under this new unit (without deleting incoming references); this enables the specialist to delete the previous unit.
In addition, control unit ctrl3 does not consume any signals in the model. Because of the fact that the control unit and all of its features are editable, the heater control engineer has the permission to create new consumes references in the model. Currently, the signal s5 is visible in the model, which means that the specialist can create a ref(ctrl3,consumes,s5) reference. 6.
File-based Access Control. O -the-shelf le systems typically require resources ( les and folders) to be explicitly labeled with permissions that take the form of an Access Control List (ACL), or the simpli ed form user/group/others. An ACL consists of entries (judgements) regarding which user/subject is granted or denied permission for a given operation. Con ict resolution is usually priority-based ( rst entry applies) within the access control list, and restrictive among type II and type III con icts (e.g. contents of a hidden folder cannot be seen, regardless of ACLs inside).
File-based solutions can be directly applied to MDE, but cannot provide ne-grained access control, where di erent parts of a model le have di erent permissions. Our policies are ne-grained, use implicit rules (so that model elements do not have to be explicitly annotated with judgements, which is di cult to manually maintain as the model evolves), and respect the modeling-speci c challenges of consistency (such as permission dependencies of cross-references); all the while being more exible in the con ict resolution method.
Access Control for XML Documents. A number
of standards such as XACML [
Context-aware Access Control RDF Stores. Models
can be persisted into triples to store them in triple or quad
stores (Neo4EMF[
Collaborative Modeling Environments. Currently,
ne-grained access control is not considered in the state of
the art tools of MDE such as MetaEdit+[
In this paper, we have proposed formal foundations for describing the interpretation of rule-based access control policies in MDE. We have identi ed the necessary criteria (deterministic, con ict-free resolution) for successfully interpreting such policies. We have proposed a framework of con ict resolution processes that is guaranteed to meet these criteria, and yet be exible enough so that it can adapt to the preferences of the the policy engineer. We have demonstrated the problems and an example solution using a case study inspired by a real-world industrial domain.
As future work, we (i) plan to de ne a textual syntax for the proposed security policy language that includes the defaults, the query-based rules and also the con ict resolution options, and investigate (ii) preselected sets of policy options (such as the resolution strategies of XACML) and accompanying \design patterns" on how policies should be constructed. E cient incremental computation of the e ective permission set also remains a challenge for the future.