TLA+ based access control model specification

. The article describes TLA+ access control model specification for computer systems, ensuring compliance with the mandatory integrity and confidentiality monitoring requirements with considering memory-based covert channels. The distinctive feature of the model is taking into account the characteristics of the lifecycle of electronic documents and their operating procedure. To specify the access control model, Lamport's Temporal Logic of Actions language was chosen (TLA+). Its notation seems to be the closest to generally accepted mathematical notation and its expressive capabilities and tools allow describing and verifying systems specified as finite automata. The following actions are defined in the model: create/delete a subject, read, write, append (blind write), create/delete an object, grant/remove access rights, include an object, exclude a nested object, approve an object (document), archive an object (document), cancel an approved object (document), copy an object (document). The following invariants are also defined: the type invariant (includes checking the compliance of all fields of the object, the compliance of the subject type, the uniqueness of the subject and object identifiers) and the safety invariant (includes checking the confidentiality and integrity labels of the interacting subjects and objects, the correctness of rights assignment procedures).


Introduction
The problems of ensuring information security become more acute when information technologies are developing and penetrating in all spheres of life. The complexity and amount of software being developed and used are constantly increasing, which leads to the emergence of new threats and vulnerabilities. It should be noted that some vulnerabilities are caused not by typical errors when programming, but by errors when designing software systems in general. Such defects are quite difficult to detect and to correct during the operation phase.
One of the possible solutions to solve this problem is the modeling and verification of the algorithms being developed for compliance with specified properties. It is especially important to model the protection mechanisms of computer systems. For example, "The Information Security Requirements for Operating Systems" by FSTEC of Russia and developed on the basis of these requirements and according to GOST R ISO/IEC 15408 protection profiles and security targets contain the requirements of the ADV_SPM.1 functional component to present a formal security policy [1,2]. In scientific studies, the formal description of security policies and access control models in operating systems is also given special attention [3][4][5][6]. There are a number of formal languages and relevant software tools providing the ability of the formalized description of a mathematical model [7]: Alloy [8], B [9], Event-B [10,11], VDM [12], Z [13], TLA + [14][15][16][17].

Problem Formulation
Access control systems in computer systems provide mechanisms for controlling and restricting access for users or processes (subjects) to a variety of objects. As part of the research, the task was to develop a model for controlling access to computer system resources, which would ensure that the requirements of mandatory integrity and confidentiality monitoring are met, taking into account information flows by memory [18]. The distinctive feature of the model is taking into account the characteristics of the lifecycle of electronic documents and their operating procedure. To specify the access control model, Lamport's Temporal Logic of Actions language was chosen (TLA+). Its notation seems to be the closest to generally accepted mathematical notation and its expressive capabilities and tools allow describing and verifying systems specified as finite automata [19][20][21]. Also, in some research works, this notation was used to solve the problem of verifying access control models [22,23].

Model Specification
The extension of temporal logic [24] is Lamport's Temporal Logic of Actions. It allows describing interacting and open-loop systems. Unlike predicate logic, temporal logic of actions has the following operators [14]: "always in the future" operator; "always in the past" operator; ◯ "next-time" operator; "at one point in time" operator; "once in the future" operator; "once in the past" operator; "until" binary operator;   "since" binary operator. The basic relations between the operators can be represented as follows:

Definition of Model Variables
Variable values may change after the execution of action predicates: VARIABLES , , , , , .
 set of current (happened) access events,  set of objects,  set of subjects,  "equal by definition" symbol.

Creating Data Types Describing Objects and Subjects of the Model
TLA + does not have strong typing (only embedded types are checked by default); however, checking of invariants of types is an integral part of the specification, because the verification is performed by the ModelChecking method [25]. A number of values specified in the model are model for reducing the resourceintensiveness of the verification process, but they do not affect the generality and adequacy of the model as a whole. Description of the type that specifies the objects:   .

Rights
GrantedRights sid SubjectIDs r Rights For electronic documents in electronic document management systems, there is the separation of rights of access to meta information and the content of a document [26]. This opportunity was also taken into account in the developed model:

Initialization of Initial Values
The set of current access events is empty at the initialization stage. The set objects can also be empty at this stage. However, the set of subjects in this case must contain at least one subject. For example, the values of the sets of subjects and objects are initialized with model values: The model provides actions to create and delete subjects and objects; therefore, the values presented in (2) only allow modeling possible states and finding errors faster.

Predicates of Actions
The following possible actions are specified in the model: , ReadD  read, WriteD  write, AppendWD  write at the end ("blind" writing), CreateObjectD  create an object, DeleteObjectD  delete an object, GrantRightsD  assign access rights, RemoveRightsD  remove access rights, IncludeObjectD  include an object to an object, ExludeObjectD  exclude an included object, ApproveObjectD  approve an object (document), ArchiveObjectD  archive an object (document), CancelObjectD  cancel the action of an approved object (document), CopyObjectD  copy an object (document).
Taking the example of the action presented in (3)  . . It is also possible that the subject is the owner of the object ; in this case, the requirement to have a right in the set of access rights to the object is not imposed; the owner has full rights ( . . o owner s sid  ). Consider also the action to create a copy of the CopyObjectD object in (4 The ( , , ) CopyObject s o id is performed by (subject) in relation to (object). As a parameter, the identifier is also passed for the object being created, the selection of which is carried out taking into account the requirement for the unique identifiers of all objects ( : :

ReadD
. id ObjectIDs oo O id oo oid      ). In this action, a new object is added to a set of objects possessing the attributes of the original object with the exception of the copy field, in which it is indicated which object is a copy of this object. It also adds the current access to the set of access events and indicates that the set of subjects does not change when performing this action. The CopyObjectD imposes requirements to account all possible states of the model ( :

Model invariants
In addition to specifying the pre-and post-conditions in the model, it is possible to set invariants for global properties, which are mandatory for all states of the model. The basic and generally accepted invariant is an invariant of types in (5). It verifies that all fields match all objects and also checks the conformity of the type of all subjects, as well as it checks the uniqueness of all identifiers of subjects and objects. );  if the object is in the "archived" or "canceled" state, then it is forbidden to assign the right to "record" to any of the subjects ( The execution of invariants for all states of the model provides the proof of the following theorem (7) regarding the specification of the model (1) and the invariants (5), (6):

Model verification
The significant limitation of the approach to the verification based on the ModelChecking method is the need to check all possible model states. That is, if one specifies any conditions for countable sets, for example, sid Nat  or oid Nat  , the verification process does not end, because the number of model states will also be countable. Therefore, in the specification, model values were used to reduce the time required for model verification. The verification of the developed model was performed using the TLC2 tool version 2.13 [27]. Thus, the time spent on verification was about 2835 minutes (more than 47 hours) on the server with the Ubuntu 16.04 operating system, Intel Xeon E5-2620 v2 24 cores 2.10 GHz and 32 GB of RAM. 16,284,800,554 states were verified with the average system performance of 5,743,616 states per minute.