1 INTRODUCTION

Modern operating systems (OSes) are used to manage very complex heaps of information, have branchy hierarchies of user roles, and implement rich sets of heterogeneous functions. In such a situation usual discretionary access control (DAC) mechanism seems to become unsuitable for security administration and hard to support accurate analysis of information flows if one needs strict control over them. A mechanism more scalable for security administration and preserving much of DAC flexibility is role-based access control (RBAC) [1]. More strict guarantees of information isolation and simplification of administration tasks are provided by multi-level security (MLS) mechanism. Another established technique for information isolation and reduction of intrusion damage is mandatory integrity control (MIC).

All these mechanisms in various combinations are used in modern OSes. RBAC and MLS are implemented in SELinux [2], a well-known security framework for Linux. SELinux is also used in mobile OS Android starting from version 5.0 [3]. The advanced MIC implementation is used by Microsoft in latest Windows OS [4]. A specific implementation of MIC is provided by macOS [5].

Each of these mechanisms has formal models establishing its strict semantics and security properties. The famous Bell-LaPadula model (BLP) [6] provides semantics for MLS, Biba model [7] gives semantics for MIC. Various models for RBAC are described in [1].

To the best of our knowledge, there is no formal model stating explicitly security properties of an OS implementing all RBAC, MIC, and MLS. The work [8] describes how to simulate MLS and/or MIC with the help of RBAC extended with specific constraints, but the technique presented there is not convenient for administration in terms of integrity or confidentiality. Classical models are not sufficient for this task, because they do not cope well with the complexity of modern OSes, where there are many kinds of data objects with different requirements to access control. The second problem is that a mechanical composition of several security mechanisms may make possible indirect information flows breaking key security properties of those mechanisms. For example, unexpected information flows can arise when special roles are used to manage high-confidentiality information, because analysis of their permissions may be accessible for low-confidentiality users.

We present in this paper a formal model called hierarchical integrated model of access control and information flows (HIMACF, its previous version was referenced as MROSL DP-model [9, 10]). Our model integrates accurately RBAC, MIC, and MLS with preservation of their key properties. By key properties here we mean the main design decisions of a security mechanism – allowing access only for subjects having appropriate role for RBAC, allowing reads only for subjects on higher-or-equal level and writes only for subjects on equal level for MLS, etc. The model also supports the complex structure of data under control in modern OSes. It is constructed in a formal language Event-B [11] and is formally verified with the help of the Rodin toolset [12], all its security properties are represented as invariants and are formally proved. The representation of the model is hierarchical or multi-level, where each level corresponds to a separate security mechanism. Such a structure helps to present mechanism-specific properties in a more clear way, and also makes analysis and verification of model properties more easy, because the properties proven on lower levels can be reused on the higher ones. The model is designed as a security policy model for operating systems, a security component required by Common Criteria standard [13, 14] for systems on high levels of trust. It is partially implemented in a Linux-based OS Astra Linux Special Edition [15], for now the conformance between the model and the OS cannot be demonstrated thoroughly, but we are conducting research and development carrying forward to this goal.

The paper structure is as follows. The next section considers RBAC, MLS, and MIC mechanisms, some of their modifications, and their formal models presented in the literature. General description of HIMACF is given in Section 3. Detailed and formal presentation of certain model elements is provided by Section 4. Section 5 depicts the model verification, and the last section concludes the paper and concerns some extensions of the model, which are under development now.

2 PRELIMINARIES

In this section, we recall some details of well-known RBAC, MIC, and MLS models. We also use some concepts and notation from those models in our model presented in next sections.

Further we call OS processes, which can access data, subjects or sessions (the term used in the original model presentation is preferred) and denote them \(S.\) All the data that can be accessed we consider to be contained in objects, the set of objects is denoted as \(O.\) All the models concerned impose some rules to control access of a subject to objects or other subjects.

2.1 Role-Based Access Control Models

Role-based access control [1] restricts session access to objects with the help of roles \(R\) and permissions \(P.\) Each role has a set of permissions determined by a relation \(PA \subseteq R \times P\) called permission assignment. One permission is a right to have access of certain kind (to read, to write, to execute, etc.) to certain set of objects. The users of the system under consideration are modeled as a set \(U.\) Each user has a set of roles determined by a relation \(UA \subseteq U \times R\) called user assignment. Each session is linked to a specific user with a function \(user:S \to U\) and has a set of roles given by a function \(roles:S \to {{2}^{R}}.\) There is a partial order on the set of roles \(RH \subseteq R \times R,\) which defines hierarchy of role inheritance, a role \(r\) inherits \(r{\kern 1pt} '\) if and only if \((r,r{\kern 1pt} ') \in RH.\) Role hierarchy is a mean to organize roles responsibilities; a session having a role also has permissions of all roles inherited by this role. The set of session roles should be included in the set of roles of its user extended by inheritance, i.e., \(s \in S \Rightarrow roles(s)\) ⊆ \({\text{\{ }}r|\exists r{\kern 1pt} '(r,r{\kern 1pt} ')\, \in \,RH\, \wedge \,(user(s),r{\kern 1pt} ')\) ∈ UA}. The state of the system is the tuple \((U,R,P,S,UA,PA,RH\), user, roles).

The ARBAC model [16] extends RBAC with administrative roles \(AR,\) which can have permissions to modify \(UA,PA,\) and \(RH.\) The set of such administrative permissions is denoted as \(AP.\) It is supposed that \(AR \cap R = AP \cap P = \emptyset .\) Relation between administrative roles and permissions is denoted as \(APA \subseteq AR\) × AP. Assignment of administrative roles to users is \(AUA \subseteq U \times AR.\) There is also the administrative hierarchy \(ARH \subseteq AR \times AR,\) a partial order on administrative roles. Assignment of roles to sessions \(roles\) is redefined as \(roles:S \to {{2}^{{R \cup AR}}},\) and \(s \in S \Rightarrow roles(s)\) ⊆ \({\text{\{ }}r|\exists r{\kern 1pt} '(r,r{\kern 1pt} ') \in RH \cup ARH \wedge (user(s),r{\kern 1pt} ') \in \) UA ∪ AUA}. The system state is the tuple (U, R, AR, P, AP, \(S,UA,\) \(AUA,PA,APA,RH,ARH,user,roles).\)

Detailed RBAC model with rules, imposing constraints on possible state transitions, can be found in ANSI RBAC standard [17].

2.2 Bell-LaPadula Model

The first and most famous MLS model is proposed by Bell and LaPadula [6, 18]. It considers the sets of subjects \(S,\) objects O, and access attributes A. Objects may participate in a hierarchy relation H. To control accesses it uses security levels \(L,\) ordered with some partial order. The security level of an object is defined with a function \({{f}_{o}}:O \to L,\) maximum possible security level of a subject is defined with \({{f}_{s}}:S \to L,\) and the current security level of a subject is defined with \({{f}_{c}}:S \to L.\) It is supposed that \({{f}_{c}}(s) \leqslant {{f}_{s}}(s)\) for all \(s \in S.\) The access rights are defined with access matrix \(M:S \times O \to {{2}^{A}}.\) Current accesses of all subjects to objects are defined by the relation \(B \subseteq S \times O \times A.\) A system state is modeled as a tuple \((B,M,{{f}_{s}},{{f}_{c}},{{f}_{o}},H)\) and is called secure if it obeys the following three rules.

• Simple security rule (or ss-rule) requires that a subject \(s\) can have observation (read) access to an object \(o\) only if \({{f}_{s}}(s) \geqslant {{f}_{o}}(o).\) The same should be true for write access (considered as allowed both to read and to modify).

• Star-rule (or \( * \)-rule) requires that a subject \(s\) can have read access to an object \(o\) only if \({{f}_{c}}(s) \geqslant {{f}_{o}}(o),\) and s can have alternation access (can do modifications without reads) to an object o only if \({{f}_{c}}(s) \leqslant {{f}_{o}}(o).\) If write access (both read and modify) is considered, then \({{f}_{c}}(s) = {{f}_{o}}(o)\) is required.

Fig. 1.
figure 1

HIMACF Structure.

Full size image

• Discretionary security rule (or ds-rule) requires that a subject s can have access a to an object o only if \(a \in M(s,o).\)

The system is called secure if all its possible states are secure. The work [6] formulates some conditions on transitions that are sufficient for a system to be secure if it has secure initial state and each transition satisfy those conditions.

2.3 Biba Model

The most well-known model for MIC is the Biba model [7]. It uses integrity levels \(I\) and a function \(i:O \cup S \to I\) assigning integrity level for each object and subject. The model considers various policies on system state transitions. The most known is the strict integrity policy, which prescribes preservation of integrity levels of objects and subjects and fulfillment of the following three rules.

(1) A subject \(s\) can have observe access to an object \(o\) only if \(i(s) \leqslant i(o).\)

(2) A subject \(s\) can have modify access to an object \(o\) only if \(i(o) \leqslant i(s).\)

(3) A subject \(s\) can have invoke access to a subject \(s{\kern 1pt} '\) only if \(i(s{\kern 1pt} ') \leqslant i(s).\)

In modern OSes the ring policy is usually implemented, which requires to fulfill rules 2 and 3.

2.4 Elaboration of MLS Concepts and Information Flows Analysis

In this subsection, we give a short review of models elaborating MLS and MIC concepts and making it more close to practical use in complex OSes. Elements of these models are used in the HIMACF.

The propagation of information during system operation is not captured well by access control actions only. It is better modeled with the help of information flows, as it is done in the Take-Grant model (TGM) [19, 20]. This model considers possible indirect accesses of subjects to data objects and other subjects that can be achieved through a sequence of reads/writes, so it can help to analyze more accurately possible propagation of information between security levels. TGM calls usual access constraints de jure rules and introduces de facto rules for information flows that can be derived from accesses and other information flows. A read information flow from an entity (object or subject) \(x\) to an entity \(y\) abstracts any possible way of information propagation from \(y\) to \(x,\) starting from a read access of a subject \(x\) to an object \(y.\) It is considered to be equivalent to a write information flow from \(y\) to \(x.\)

• Post rule: if a subject \(x\) has read access/flow from an entity (object or subject) \(z\), and a subject \(y\) has write access/flow to \(z,\) then \(x\) gets read flow from \(y.\)

• Pass rule: if a subject \(y\) has read access/flow from an entity \(x\) and write access/flow to an entity \(z,\) then read flow exists from \(x\) to \(z.\)

• Spy rule: if a subject \(x\) has read access/flow from a subject \(y\) having read access/flow to \(z,\) then \(x\) gets read flow from \(z\) too.

• Find rule: if a subject \(z\) has write access/flow from a subject \(y,\) which has write access/flow from an entity \(x,\) then \(x\) gets read flow from \(z.\)

These rules are in effect equivalent to creating read flow on each read access, creating an inverse read flow on each write access, and extending read flows by transitivity.

The complexity of data managed by a security system was addressed in the Military Message System (MMS) model [21]. This model considers containers that can include objects (data blocks/files) or other containers with different security levels assigned and defines a set of rules for controlling access to such containers and their contents. MMS requires that a container should have the security level greater or equal to the maximum level of its contents. It allows different access modes for containers – some allow contents to be accessed only by users with level greater or equal to the level of the container itself (and so of all its contents), others permit users of level \(l\) to access contained data having not-greater level even if the level of the container itself is greater than \(l.\) The containers of the first kind are marked with container clearance required flag (CCR). In addition, MMS allows a user to access a file through references if user’s level allows direct access to that file. In MMS, a user may have a set of roles with different permissions. The model explicitly requires that only the security officer role has permissions to change user roles and role permissions, and introduces special downgrader role permitted to lower levels of data objects if they are required to be sent to lower levels. However, MMS does not specify other rules to administrate users, roles, objects, and containers.

2.5 SELinux Overview

Security-Enhanced Linux (SELinux) [2, 22] is a security framework implemented in Linux kernel using Linux Security Modules (LSM) infrastructure. LSM infrastructure provides a set of hook functions, which can implement access control checks, additional to usual Unix DAC. Calls of these hooks are dispersed in the Linux kernel code in such a way that an appropriate hook is always called when the corresponding access operation is performed (of course, this is a matter of trust to the Linux kernel developers, who should insert those calls in all proper places). SELinux provides the implementation of several security mechanisms, namely, RBAC, MLS, and type enforcement (TE) – a mechanism based on an assignment of certain types to objects and processes and checking access control rules formulated in terms of types of participating entities.

SELinux does not implement any specific access control restrictions; it provides a generic policy checking mechanism and a policy specification language, in which one can formulate rules implementing specific RBAC or MLS policy. The policy language has constructs to write restrictions based on entity labels, representing their roles, types, levels, and categories. OS-related entities are divided into about 50 classes: processes, files, directories, sockets of various types, interprocess communication objects, etc. For a class, SELinux usually supports a dozen or two operations, and for each operation, access constraints can be defined in a policy along with certain rules of label assignment and transformation.

In addition, SELinux can implement access control for applications, which manage their internal data objects and can perform operations on them that are not controlled by OS. Examples of such applications are database management systems (DBMS) and various middleware. For now, SELinux has specific set of classes for entities related with DBMS (mostly PostgreSQL [23]), D-Bus [24], and X Window System [25].

SELinux policy language is rather expressive and allows mixing up elements of RBAC, MLS, and TE in constraints in almost arbitrary expressions. Therefore, analysis and validation of SELinux policies are very complex. There exist some tools for policy correctness checking [26], but they are not sufficient for rigorous analysis to verify specific security properties. Several works consider the task of SELinux policy formal modeling and further analysis of the resulting models.

The work [27] presents a formal language for policy description with formal semantics for TE and RBAC, but not for MLS. The paper [28] uses this language to propose tool and algorithms for security property analysis of policies.

In [29] SELinux access control mechanisms are mapped into Harrison-Ruzzo-Ullman security model [30], but results of such a mapping are not very useful, because configuration reachability analysis of the latter model is undecidable.

The work [31] proposes a formal model for analysis of SELinux policies including MLS constraints. It uses two kinds of constraints: a constraint of the first kind restricts access of a subject to objects, a constraint of the second kind restricts modification of object’s MLS-related labels by a subject. The model proposed supports some kinds of analysis of information flows between different levels defined by MLS policy part and uses Prolog for such analysis.

The review [26] reports on SELinux policy language properties concerning general language clarity considerations presented in work [32]. A policy language is called safe if a request with less information will lead to a weaker decision (according to a partial order on decisions) than a request with more information. A policy language has the independent composition property if the result taking into account all rules in a policy is the same as the result combined (in a definite way) from results given by each rule in isolation. A policy language is monotonic if adding a rule in a policy does not change the combined decision from “grant access” to “do not grant access”. It occurs that SELinux policy language has the independent composition property, but is both non-safe and non-monotonic.

3 DESCRIPTION OF HIMACF MODEL

The HIMACF model integrates RBAC, MLS, and MIC mechanisms. It also includes TGM-like information flow propagation rules helping to analyze consequences of covert channels or possible attacks and provide guarantees of security systems robustness even in the case of intrusions on the low-integrity level. The model is formalized in the Event-B formal language and has four modules corresponding to basic mechanisms described. The first module (or the base level) of HIMACF model describes RBAC, the second one – MIC, the third one – MLS, and the fourth one – information flows. Each next module refines the previous one.

Event-B [11] describes a modeled system as a state machine with the help of state variables (types of variables can be defined using usual set theory), operations or events corresponding to state transitions (which can change state variables), and invariants formulating properties of state variables that are preserved by transitions. An event is defined by its name, parameters, precondition, and postcondition. Precondition and postcondition together form an event contract. Precondition formulates constraints on parameters and state variables that should hold when the event is executed (one such constraint is called a guard). Postcondition formulates changes of state variables values as a result of event execution (one such change rule is called an action).

Refinement means that state variables, invariants, events, and event contracts of the refined module are inherited by the refining module. New state variables, invariants, and events can be added, inherited event postcondition may be strengthened by adding actions changing new variables (not old ones), and inherited event precondition may be strengthened by adding guards. Correctly implemented refinement means that invariants verified for the refined module hold in the refining one too, because their proofs in the refined module are still valid for the refining one.

3.1 Main Ideas

The role-based mechanism in HIMACF is similar to the ARBAC model [16]. It uses sets of users, subjects (representing OS processes), entities (representing any objects of access control, including files, sockets, devices, queues, semaphores, etc.), and roles. Entities can be simple objects (entities that cannot contain other entities) or containers, which may contain other entities. Containers and objects do not intersect. Roles can be ordinary or regular, having permissions on regular access kinds (read, write, execute, own), and administrative, having permissions on role assignment, displacement, and modification of role permissions. The sets of regular and administrative roles do not intersect.

Rights to have some kind of access or ownership are represented as regular permissions. An owner of an entity is a role, which has permissions to change access rights to this entity. Ownership is modeled with special access right \(own.\) There can be no more than one owner of an entity. Administrative permissions represent the assignment of a role (regular or administrative) to a subject or right to change role permissions. A subject having (trough an administrative role) \(read\) access to a role can use its permissions (this models assignment of a role to a subject), a subject having \(write\) access to a role can modify its permissions.

Each container has a name that is represented by a string. Objects also have names, but they can belong to several containers (in a usual Unix file system), so an object may have different names in different containers. Name within a container is unique. Hierarchy of entities is acyclic, i.e., a container cannot be contained directly or transitively in itself. There is only one root of the hierarchy – the root container, which is not included in any container.

Subjects also have their hierarchy, a subject may have a single parent subject, modeling the corresponding relation of Unix processes. This hierarchy is also acyclic but can have several roots. For each subject an owner role exists, having permissions on all operations on the subject.

A role may have several parent roles. A subject assigned to a role has also permissions of all its parents and further ancestors. Hierarchies of regular and administrative roles do not intersect. Hierarchy of roles is acyclic and may have several roots. Roles also have string names; a role name is unique among all role names. There is a set of special administrative roles, such a role cannot be created or deleted, change permissions or name. Special administrative roles include certain roles capable to perform administrative operations on users, entities, subjects, and roles (and may include security officer role). In addition, the model specifies special user roles, intended to store rights on operations specific for a user, and common roles, intended to store rights on operations that can be performed by (almost) every user.

The system state described in the RBAC module consists of the sets of users, entities, subjects, and roles; assignments of (regular and administrative) permissions to subjects; entity, subject, and role hierarchy relations; ownership map of subjects to users, and current (regular and administrative) accesses of subjects to entities and roles.

The RBAC module defines Event-B events to create and delete users, entities, subjects, roles, to add an existing entity into a container (creation of a hard link, creation of a new entity also requires a container as a parameter), to rename entity or role, to modify the set of roles assigned to a subject, to modify permissions assigned to a role, to give a subject regular access of some kind to an entity or an administrative access to a role.

The main constraint of this module is that a subject should have the proper role assigned to get access to something. Getting each kind of access to an entity for a subject requires having read access to a role having permission for this kind of access to that entity. Modification of role permissions by a subject requires having write access to this role. These constraints are written in preconditions of the corresponding events, they cannot be proven as invariants, because a subject can lose a role without losing access obtained through permissions of this role or the role can lose those permissions while the subject is active.

The module modeling MIC contains the definition of integrity levels (low and high) and adds to the system state a map of all the users, entities, subjects, and roles to integrity levels. High integrity users can activate both high and low integrity subjects, low integrity users can activate only low integrity subjects. Also, a low integrity subject can be a parent of low integrity subjects only.

Special roles are created for each user – regular and administrative roles with low integrity with permissions for all operations that user can perform as a low integrity user, and, if the user has high integrity, a regular and administrative roles with high integrity with permissions for all operations it can perform as a high integrity user. So, no operation can be performed without using a role with the corresponding permission. This solution helps to preserve the key security property of RBAC.

The MIC module adds new operations to manage integrity levels of anything. It also refines all existing operations adding guards that require to have high integrity level to be able to get access to modify properties of anything with high integrity level.

The main constraint of this module is a necessity for a subject to have high integrity level to get write access to something of high integrity. Since all the things – entities, subjects, users, and roles – have integrity level marks, both direct and indirect trials to violate this constraint can be traced and prevented.

The module modeling MLS adds a partially ordered set of confidentiality levels and mapping of users, entities, subjects, and roles to their levels. We consider confidentiality level as a composite label, containing all the data for confidentiality control, so in usual terms, it contains both the sensitivity (or classification, or clearance) level and a set of compartments or categories. Users can activate subjects on each level less or equal to the level of the user. Special regular and administrative roles are created for each combination of confidentiality and integrity levels accessible for a user with permissions to all operations the user can perform being on that level and having that integrity.

Main constraints of this module is a necessity for a subject to have greater or equal confidentiality level to get read or execute access to anything, and a necessity to have equal confidentiality level to have write access to anything.

The last, fourth module adds variables and events for information flows definition – analogs of take, pass, find, and spy rules. It also provides rules to define authority control (maybe indirect) of a subject over another subject. A subject controls itself and can get control over another subject if it has write flow to its executable files. Such a control expands transitively – if a subject \(s\) has control over a subject \(q,\) which has control over a subject \(p,\) then \(s\) can get control over \(p\) too. So, the module provides a framework for information flows analysis and analysis of covert channels influence. It also helps to prove that indirect information flows cannot break basic security properties even in case of successful intrusion on low integrity level, i.e., when some low-integrity subjects (but no high-integrity one) are controlled by an intruder.

3.2 Formal Presentation of the Model

In this section, we provide a part of the formal representation of the base level of the HIMACF model describing RBAC mechanism. We also present here examples of event specifications and invariants of higher-level modules to demonstrate various model features.

An Event-B model has static part (called context), representing basic types (called sets), constants, and axioms describing typing of constants and other restrictions on them. Another part of an Event-B model (called machine) describes model dynamics as a state machine. It contains definitions of variables, invariants, and events.

The base level context of HIMACF contains the definition of the following sets.

• \(UserType\) represents type of users.

• \(SubjectType\) represents type of subjects.

• \(EntityType\) represent type of entities.

• \(RoleType\) represents type of roles.

• \(Names\) represents possible names of entities and roles.

• \(Accesses\) represents possible accesses of subjects to entities or roles.

• \(AccessRights\) represents possible permissions of roles.

The constant \(Root \in EntityType\) is specified, it is the entity hierarchy root that cannot be deleted. The set of special administrative roles \(SpecialAdmRoles\) is also defined as a constant, it contains separate roles for administration of entities, subjects, users, regular roles, and administrative roles. The property partition(SpecialAdmRoles, {EntitiesAR}, {SubjectsAR}, {UsersAR}, {OrdRolesAR}, {AdmRolesAR}) holds. The construct \(partition(U,A,B,C)\) means in Event-B that U = \(A \cup B \cup C\) and \(A \cap B = A \cap C = B \cap C = \emptyset ,\) this construct can have any number of arguments greater than two with obviously inferred semantics. Axioms also include statements partition(Accesses, {ReadA} {WriteA}) and \(partition(AccessRights\), {Read}, {Write} {Execute}, {Own}) specifying possible access kinds and access rights.

The base level machine of HIMACF has the following variables (main typing constraints are mentioned here near the corresponding variable, not as separate invariants as they are presented in Event-B).

• \(Users \subseteq UserType\) is the set of existing users.

• \(Subjects \subseteq SubjectType\) is the set of active subjects.

• \(Entities \subseteq EntityType\) is the set of existing entities.

• \(Roles \subseteq RoleType\) is the set of all existing roles (both regular and administrative).

• \(Objects\) is the set of existing objects (entities that cannot contain other entities).

• \(Containers\) is the set of containers (entities that may contain other entities). \(partition(Entities,Objects,\) \(Containers)\) holds, also \(Root \in Containers.\)

• \(RegRoles\) is the set of existing regular roles.

• \(AdmRoles\) is the set of all existing administrative roles. \(partition(Roles,\) \(RegRoles,AdmRoles)\) holds. Also \(SpecialAdmRoles \subseteq AdmRoles.\)

• \(EntityNames\, \in \,(Entities{\backslash \{ }Root{\text{\} }})\) → (Containers ↔ Names) is the mapping of an entity to pairs of its name and container, where this name is used.

• \(RoleName \in Roles \to Names\) is the mapping of a role to its name.

• \(Parent \in (Containers{\backslash \{ }Root{\text{\} }}) \to Containers\) is the mapping of a container to its parent container. For containers hard links are prohibited, so a container can be placed only in one other container. Objects can have several parents that can be extracted from \(EntityNames\) mapping.

• \(SParent \in Subjects \nrightarrow Subjects\) is the partial mapping of a subject to its parent subject.

• \(RParents \in Roles \to \mathcal{P}(Roles)\)Footnote 1 is the map of a role to its parents (it can have several parents).

• \(RoleRights \in Roles \to (Entities\) ↔ AccessRights) is the mapping of roles to their permissions.

• \(RoleAdmRights \in AdmRoles \to (Roles\) ↔ AccessRights) is the mapping of administrative roles to their permissions.

• \(SubjectUser \in Subjects \to Users\) is the mapping of a subject to the user who activated that subject.

• \(SubjectOwner \in Subjects \nrightarrow Roles\) is the partial mapping of a subject to its owner role.

• \(SubjectAccesses \in Subjects \to (Entities\) ↔ Accesses)is the mapping of a subject to its current accesses to entities.

• \(SubjectAdmAccesses \in Subjects \to (Roles\) ↔ \(Accesses)\) is the mapping of a subject to its current administrative accesses to roles.

In addition to typing constraints, some invariants represent correctness constraints of the system state. \(EntityNames\) and \(Parent\) mappings should obey the following constraints.

• \(\forall e\, \cdot \,e\, \in \,dom(EntityNames)\) ⇒ \(EntityNames(e)\) ≠ ∅. Each entity except for \(Root\) is placed in some container.

• \(\forall e1,e2 \cdot {\text{\{ }}e1,e2{\text{\} }}\) ⊆ dom\((EntityNames) \wedge e1 \ne e2\) ⇒ \(EntityNames(e1) \cap EntityNames(e2) = \emptyset .\) Names of entities within containers are unique.

• \(\forall c1,c2 \cdot c1 \in Containers \wedge c1 \ne Root \wedge \) c2 ∈ dom\((EntityNames(c1)) \Rightarrow c2 = Parent(c1).\) A non-root container is placed in only one container, which is its parent.

(1) \(\forall C \cdot C\) ⊆ dom\((Parent)\, \wedge \,C\, \ne \,\emptyset \) ⇒ C\Parent[C] ≠ ∅. Containers hierarchy has no cycles.

Some constraints are imposed on subjects and roles hierarchy.

• \(\forall r \cdot r \in RegRoles \Rightarrow RParents(r) \subseteq RegRoles.\)

• \(\forall r \cdot r \in AdmRoles \Rightarrow RParents(r)\) ⊆ \(AdmRoles.\) Regular and administrative roles have nonintersecting hierarchies.

• \(\forall R \cdot R \subseteq Roles \wedge R \ne \emptyset \) ⇒ \((\exists r \cdot r \in R \wedge R\) ∩ RParents(r) = ∅). Roles hierarchy has no cycles.

• \(\forall S \cdot S\) ⊆ \(dom(SParent) \wedge S \ne \emptyset \Rightarrow \) ⇒ \(S{\backslash }SParent[S]\) ≠ ∅. Subjects hierarchy has no cycles.

No more than one owner is allowed for an entity (or a role). \(\forall r1,r2\), \(e \cdot r1 \in Roles \wedge r2 \in Roles \wedge (e\) \( \mapsto \) Own) ∈ \(RoleRigths(r1) \cap RoleRights(r2) \Rightarrow r1\) = r2.

Administrative \(read\) right is spread from parent roles to children. \(\forall a,r,p \cdot a \in AdmRoles \wedge r\) ∈ \(Roles \wedge p\) ∈ \(RParents(r)\) \( \wedge (p \mapsto Read)\) ∈ RoleAdmRights(a) ⇒ \((r \mapsto Read) \in RoleAdmRights(a).\)

The list of model operations (Event-B events) on the base model level is the following.

• User management: create_user, delete_user, get_user_attr.

• Access management: access_read_entity, access_write_entity, delete_access_entity, access_read_role, access_write_role, delete_access_role.

• Permission management: grant_rights, remove_rights, set_entity_owner, set_subject_owner, grant_admin_rights, remove_admin_rights.

• Entity management: create_object, create_container, delete_entity, create_hard_link, delete_hard_link, rename_entity, get_entity_attr, read_container, set_entity_labels, set_container_attr.

• Role management: create_role, create_hard_link_role, delete_role, delete_hard_link_role, rename_role, get_role_attr.

• Subject management: create_first_subject, create_subject, delete_subject, get_subject_attr.

The specification of \(access\_write\_entity\) event on the base model level looks as follows.

event access_write_entity

   any

      subject

      entity

   where

      @grd1 subject ∈ Subjects

      @grd2 entity ∈ Entities

      @grd3 ∃r ⋅ r ∈ RegRoles ∪ AdmRoles

∧ r \( \mapsto \) ReadA ∈ SubjectAdmAccesses(subject)

∧ entity \( \mapsto \) Write ∈ RoleRights(r)

      @grd4 ∃E, c ⋅ E ⊆ dom(Parent) ∧ ((entity = Root

∧ E = ∅) ∨ (entity ≠ Root

∧ c ∈ dom(EntityNames(entity))

∧ Parent[E] ∪ {c} = E ∪ {Root}))

∧ (∀o ⋅ o ∈ E ∪ {entity} ∪ {Root} ⇒

(∃r ⋅ r ∈ RegRoles ∪ AdmRoles

∧ r \( \mapsto \) ReadA ∈ SubjectAdmAccesses(subject)

∧ o \( \mapsto \) Execute ∈ RoleRight(r)))

   then

      @act1 SubjectAccesses(subject) :=

SubjectAccesses(subject) ∪ {entity \( \mapsto \) WriteA}

end

Here the parameter \(subject\) denotes the subject getting the access and \(entity\) denotes the entity to which the access is requested. The first two guards impose type constraints on the parameters. The third guard says that to get the read access the subject should be assigned to a role \(r\) having the right to write to the entity. The fourth guard says that to get the access the subject should have \(Execute\) access to all the members of some chain of containers embedded into each other, starting with Root and ending with a container containing the entity (such a chain without Root is denoted as \(E\) here).

Below we show how the specification of this event is extended in other modules. In the second module of the model MIC mechanism is specified, so the set of integrity levels \(Integrity\) is added to types, \(LowI\) and \(HighI\) constants are added to denote the minimum and maximum possible integrity levels. The maps \(EntityInt:Entities\, \to \,Integrity\) and SubjectInt : Subjetcs → \(Integrity\) mapping entities and subjects to their integrity levels are added to the state variables. The map \(CCRI\) : \(Containers \to BOOL\) maps containers to their CCRI flags. If such a flag is TRUE then container allows write access to embedded entities only for subjects with integrity level not less than the container’s integrity level, else no additional constraints are imposed on access to embedded entities. The module adds \(set\_user\_labels\) and \(set\_role\_labels\) events to change integrity levels of users and roles. Most events of the first module are refined by adding integrity related parameters and integrity constraints checks.

Invariant representing the key security property of MIC mechanism looks as follows.

@SubjectAccesses1

    ∀s, e ⋅ s ∈ Subjetcs ∧ (e \( \mapsto \) WriteA) ∈

    SubjectAccesses(s) ⇒ EntityInt(e) ≤ SubjectInt(s)

The following two guards are added to access_write_entity event specification in the second module.

event access_write_entity extends access_write_entity

  where

     @grd5 ∃E, c ⋅ E ⊆ dom(Parent) ∧ ((entity = Root

∧ E = ∅) ∨ (entity ≠ Root

∧ c ∈ dom(EntityNames(entity))

∧ Parent[E] ∪ {c} = E ∪ {Root}))

∧ (∀o ⋅ o ∈ E ∪ {entity} ∪ {Root} ⇒

(∃r ⋅ r ∈ RegRoles ∪ AdmRoles

∧ r \( \mapsto \) ReadA ∈ SubjectAdmAccesses(subject)

∧ o \( \mapsto \) Execute ∈ RoleRight(r))

∧ (EntityInt(o) ≤ SubjectInt(subject)

∨ CCRI(o) = FALSE))

     @grd6 EntityInt(entity) ≤ SubjectInt(subject)

end

The fifth guard specifies that there exists such a chain of embedded containers from Root to the one containing the accessed entity that the subject, in addition to having a role with \(Execute\) access to any container in the chain, should have integrity level greater or equal than the integrity level of the container, or the container should have CCRI flag cleared. The sixth guard says that to get Write access to the entity the subject should have integrity level greater or equal than the integrity level of the entity.

The third module describes MLS mechanism, so it adds the type of confidentiality levels Cnf, which is specified as the power set of some non-empty set

\(Confidentiality.\) Since each finite partially ordered set can be isomorphically embedded into the lattice of subsets of some finite set, we do not specify levels and categories of confidentiality separately, just considering all their possible combinations as some subsets of \(Confidentiality\) set.

The maps \(EntityCnf:Entities \to Cnf\) and \(SubjectCnf:Subjects\) → Cnf mapping entities and subjects to their confidentialities are added to the state variables. The map \(CCR:Containers\) → BOOL maps containers to their CCR flags. If such a flag is TRUE then container allows access to embedded entities only for subjects with confidentiality level not less than the container’s one. Again, most events are refined in this module to add confidentiality related parameters and MLS constraints checks.

Invariants representing the key security properties of MLS mechanism look as follows.

@SubjectAccesses2

   ∀s, e ⋅ s ∈ Subjects ∧ (e \( \mapsto \) ReadA) ∈

   SubjectAccesses(s) ⇒ EntityCnf(e) ⊆ SubjectCnf(s)

@SubjectAccesses3

   ∀s, e ⋅ s ∈ Subjects ∧ (e \( \mapsto \) WriteA) ∈

   SubjectAccesses(s) ⇒ EntityCnf(e) = SubjectCnf(s)

The following guards are added to access_write_entity event specification in the third module.

event access_write_entity extends access_write_entity

   where

     @grd7 ∃E, c ⋅ E ⊆ dom(Parent) ∧ ((entity = Root

         ∧ E = ∅) ∨ (entity ≠ Root

         ∧ c ∈ dom(EntityNames(entity))

         ∧ Parent[E] ∪ {c} = E ∪ {Root}))

         ∧ (∀o ⋅ o ∈ E ∪ {entity} ∪ {Root} ⇒

         (∃r ⋅ r ∈ RegRoles ∪ AdmRoles

         ∧ r \( \mapsto \) ReadA ∈ SubjectAdmAccesses(subject)

         ∧ o \( \mapsto \) Exucute ∈ RoleRights(r))

         ∧ (EntityInt(o) ≤ SubjectInt(subject)

         ∨ CCR(o) = FALSE)

         ∧ (EntityCnf(o) ⊆ SubjectCnf(subject)

         ∨ CCR(o) = FALSE))

     @grd8 EntityCnf(entity) = SubjectCnf(subject)

end

The seventh guard specifies that for any container in some chain of embedded containers from the Root to the one containing the accessed entity, in addition to having a role with \(Execute\) access and correct relation of integrity levels, the subject should have confidentiality level greater or equal than the confidentiality level of the container, or the container should have CCR flag cleared. The eighth guard says that to get Write access to the entity the subject should have confidentiality level equal to the confidentiality level of the entity. We have to repeat constraints from guard 4 in guards 5 and 7, because we require all these properties to hold for the same chain of containers.

The last module providing a framework for information flow analysis defines information flows between entities and subjects. Namely, four variables \(EEMFlows\) Entites → \(\mathcal{P}(Entities),\) \(ESMFlowsEntities\) → \(\mathcal{P}(Subjects),\) \(SEMFlowsSubjects\) → \(\mathcal{P}(Entities)\), and \(SSMFlowsSubjects\) → \(\mathcal{P}(Subjects)\) represent write information flows from entities to entities, from entities to subjects, from subjects to entities, and from subjects to subjects. It also has a variable representing indirect control relation between subjects, modelled as the map \(DeFactoOwn\) : \(Subjects \to \mathcal{P}(Subjects).\) TGM find_rule is transformed into two events, \(find\_entity\) and \(find\_subject.\) The first of them is specified as follows.

event find_entity

    any

        x

        y

        z

    where

       @grd1 x ∈ Subjects

       @grd2 y ∈ Subjects

       @grd3 z ∈ Entities

       @grd4 y ∈ SSMFlows(x)

       @grd5 z ∈ SEMFlows(y)

    then

       @act1 SEMFlows(x) := SEMFlows(x) ∪ {z}

end

4 MODEL VERIFICATION

The complexity of the HIMACF model makes its validation without specialized tools rather complex task. It has a traditional textual description, but its size is approaching to 300 pages and is growing, since the model is being developed and extended with new features continually. Some numerical characteristics of model complexity are provided in Table 1, each row except for the last one contains numbers for the corresponding module. The second column shows the number of original events, specified in the corresponding module. The third column shows the number of events specified in refined modules and elaborated with additional guard or action in the corresponding one.

Table 1. HIMACF Model Complexity
Full size table

So, we used the Rodin [12] framework to verify it in an automated way. The total number of proof obligations (statements concerning type correctness of variables or invariant preservation after modifications provided by an event, etc.) generated by Rodin is about 3600. 75% of them are proved automatically and the rest require about a man-month of interactive proving. Note, that these numbers apply to the current structure of the model and staff that is used to work with it. The first version of the model [10] did not use refinement (different security mechanisms were specified in a single module) and required about 2 man-years to be developed in Event-B from the initial textual description and verified. Now it is decomposed in four modules and becomes much more suitable for human comprehension and developing various extensions, while the total laboriousness of proving invariants after a minor change remains almost the same [33].

5 CONCLUSION AND FUTURE WORK

The paper presents results of development and verification of an integrated model of role-based access control, mandatory integrity control, multi-level security, and information flows called HIMACF (hierarchical integrated model of access control and information flows). The model is specified in the Event-B formal language and is formally verified, all its properties are proved with the help of the Rodin framework supporting Event-B.

The model is designed in such a way that key security properties of all integrated mechanisms are preserved. To make this feature more visible and to make verification less difficult, it is composed of several modules, which are organized in a sequence of refinements. Each module specifies a separate security mechanism; the first one describes RBAC, the second one – MIC, the third one – MLS, and the fourth module describes information flows. Briefly speaking, the key property of the RBAC is that access to some operation is provided to a subject only through the assignment of a role having a right to perform the corresponding operation. MIC requires that a subject getting write access to an entity should have integrity level greater or equal to the level of this entity. MLS requires that a subject getting read or execute access to an entity should have confidentiality level greater or equal to the level of this entity, and to get write access to an entity it should have confidentiality level equal to the level of this entity. These constraints are preserved by means of using special user-related roles to perform all operations a user can do on certain levels of confidentiality and integrity, and by assigning integrity and confidentiality levels to all roles, which helps also to control strictly information flows between levels.

The model is rather complex, which is a consequence of an intention to specify accurate integration of several security mechanisms and to make it applicable to modern OSes controlling rather complex structures of data and processes. Nevertheless, formal verification of the model is achievable due to the use of a specification language supported by an automated interactive proof environment.

Because of the comprehensible hierarchical model structure using Event-B refinements, it is not hard to extend the model and incorporate new minor features in it when necessary, providing quick verification of extended versions. We already have a version of the model including indirect security labels (labels set not on a file itself, but on the file system containing that file and mounted in some container), special entities with weakened access restrictions (modeling special Unix devices like dev/null, which cannot be used to store information) forbidding roles (roles, which assignment forbids some operations for a subject) and more complex integrity levels structure (adding intermediate integrities to usual low and high and making possible incomparable integrities). We are also developing a significant extension of the model for PostgreSQL security, also structured in several modules.

It is also important to notice that the HIMACF model is (partially) implemented in a Linux-based OS Astra Linux Special Edition [15] using Linux Security Modules (LSM) infrastructure. Presence of the formal HIMACF model helps to develop a specialized formal model of LSM interface operations and to perform formal deductive verification of their implementations in C language using Why3 [34] tool. This work is not yet finished now, report on its progress can be found in [35]. We plan to finish it, getting, in the end, an implementation of an OS access control mechanism with formally verified conformance to a formal model.