RU2534488C1 - System for controlling access to computer system resources with "initial user, effective user, process" subject - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: system for controlling access to computer system resources with an "Initial user, Effective user, Process" subject comprises a user authorisation unit; the input of the user authorisation unit is connected a user authorisation input, wherein the system further includes a unit for generating a table (array) of access rules, a unit for selecting rules from the table (array) of access rules, a unit for storing the table (array) of access rules for the "initial user, effective user, process" subject, a unit for analysing an access request and a unit for remembering the initial user.

EFFECT: broader functional capabilities of controlling access to resources.

2 dwg, 3 tbl

Description

The invention relates to the field of computer technology, and in particular to the field of protection against unauthorized access (unauthorized access) to information created, processed and stored in computer systems (CS).

One of the key tasks of protecting information processed in the CS is the implementation of access control (access control) to protected resources: file objects, OS registry objects, devices, network resources, etc.

An analysis of the literature allows us to note the following two key shortcomings of the known access control systems to the resources of the COP. Firstly, despite the fact that the urgent modern task of controlling access to resources is to implement a delimiting policy of access to resources not only for users, but also for processes (both system and applications), since processes carry an independent threat, and the magnitude NSD threats are different for different processes (applications), while all processes have access to protected resources with the rights of the user who launched the process, i.e. with the same rights for the same user, in practice, most access control systems for resources today involve the implementation of a delimiting policy of user access (accounts) to protected resources - the process in the delimiting policy is not used as an access subject, which does not allow for effective protection from NSD information processed in the COP in modern conditions.

Secondly, in known systems, the change of the user name is not controlled when accessing the resources of the COP. Let us explain the need for such control. For example, in widely used operating systems of the Windows family, security identifiers (SIDs) are used to identify entities performing various actions in the system. SIDs are available to users, local and domain groups, local computers, domains, and domain members. All processes and threads running in the system are executed in the security context of the user on whose behalf they were started, and an object called an access token is used to identify the security context of the process or thread. During the registration process, an initial marker is created in the system that represents the user who logs into the system and compares it with the shell process used to register the user.

The token can be the main one (identifies the process protection context) or personifying (used to temporarily borrow a different protection context - usually another user). Impersonation is a tool that is routinely used in the Windows security model, which allows an individual thread to be executed in a security context other than the security context of the process that generates it, i.e. act on behalf of another user. Impersonation, for example, is widely used in the client-server programming model. When borrowing rights, the server temporarily accepts a client security profile that accesses the resource. Then the server can work with the resource on behalf of the client, and the security system checks its access rights.

Typically, the server has a wider range of resources available than the client, and when impersonated, the server may lose some of the original access rights. Conversely, when impersonating a server, it may receive additional rights. Thus, impersonation services are the regular capabilities of modern operating systems that are potentially dangerous and can be used to expand privileges (expand the capabilities of the current user account to the capabilities of a more privileged account, for example, a superuser account, such as an administrator account or SYSTEM account), sufficient for unauthorized access to confidential data, bypassing the implemented delimiting access policy.

A similar possibility is present in the identification mechanism of Unix-like systems. There are two types of user identifiers in Unix: real and effective. The real user identifier of this process is the identifier of the user who started the process. The effective identifier is used to determine the access rights of the process to the resources of the COP. Usually the real and effective identifiers are the same, i.e. the process has the same rights in the system as the user who launched it. However, it is possible to give the process broader rights than user rights by setting the SUID bit when the effective identifier is assigned the value of the owner identifier of the executable file (for example, the root user). Thus, the process is performed on behalf of the user who owns the executable file, and the borrowing of rights occurs transparently (no additional authentication is required) for the user who launched the process.

As you can see, here, using impersonation services, completely legal services provided by modern OSs, it is possible to obtain the rights of another user, with the subsequent access to their resources to the CS bypassing the delimiting access policy.

Thus, we have two entities. The “initial” (or “Primary”) username is the name of the user on whose behalf (with whose rights) the process is started, and the “Effective” username. This is the name of the user on behalf of whom the process (more precisely, the thread generated by it) accesses the resource of the COP. It is this name that the access manager determines from the resource access request, i.e. it is this username that participates in the demarcation policy of access to resources.

However, despite the widespread attacks on privilege escalation today - changing the username when accessing resources (for this, in practice, not only impersonation services are used), modern control systems for accessing the resources of the COP do not control changing the username when accessing resources, which carries it poses a serious threat to unauthorized access to information processed in the Constitutional Court bypassing the delimiting policy of access to resources.

Currently, various control systems for access to the resources of the COP are known.

So, for example, in patent No. 2139931 (class H04L 9/32, G06F 12/14) a method for providing access to objects in the operating system is described, based on the assignment of security labels to subjects and access objects, in addition, for each object of the operating system in advance form and then stored in the memory signal of the label of the object. The user (account) is considered as the subject of access, control of changing the user name when accessing resources is not carried out.

In the system of access control for file objects, implemented in Microsoft Windows with the NTFS file system, which uses file attributes (in particular, Security Descriptor - this file contains information about file protection: ACL and the audit field, which determines what kind of operations on this file should be recorded), for each file object, you can specify which user (account) with which rights (read, write, etc.) can access this object [M . Russinovich, D. Solomon. Microsoft Windows internal device. - St. Petersburg: Peter, 2005 - 992 p. (Chapter 8, Fig. 8.5. An example of checking access rights)]. Here again, the essence of the process is not used in the delineation policy as the subject of access, and the change of the user name when accessing resources is not controlled.

Closest to the technical solution and chosen by the authors for the prototype is the System for restricting access to resources, Patent No. 2207619 (G06F 13/00).

The system is presented in figure 1. The system for restricting access to resources contains: a user authorization unit 1, a user access storage unit 2, a user access permission block 3, a process access storage unit 4, a process permission block for resources 5, an privileged process authority storage unit 6, a block for permitting access of a privileged process to resources 7, a block for permitting access to resources 8, the input of the authorization block of user 1 being connected to the authorization input of user 9; the output is with the first input of the user access rights storage unit 2, with the second input of the user access permissions block 3, the first input of which is with the output of the user access rights storage unit 2, the second input of which is with the input of the user access control permissions 10, the third the input of the permission block for user access to resources 3 - with the input of the request for access to the resource 11, the first input of the block for storing access rights of processes 4 is connected to the first input of the block for storing access rights for privileged processes 6, with the output m of user authorization block 1, the second input - with the input of the task of restricting access rights of processes 12, the output - with the first input of the block of process access permission to resources 5; the second input of which is with the identification input of the process that requested access to resource 14, with the second input of the access block of the privileged process access to resources 7, the first input of which is with the output of the privilege storage unit for privileged processes 6, the second input of which is with the input of the task of differentiation access privileged processes 13, the first input of the access permission block to resources 8 - with the output of the user access permission block to resources 3, the second input - with the output of the privileged access permission block process resources 7, the third input - to the output unit of the access permissions to resources is 5, the output - with output an access permission to the resource 15.

The system works as follows. In addition to the analysis of user access rights to resources carried out by blocks 1, 2, 3, the process access rights to resources are set and analyzed. The table of access rights of processes to resources (the identifier of a process is its name and the full path where the process is started from, as well as access parameters to the resource: full access, read, write, execute, etc.) is created by the administrator from entry 12 (after administrator authorization ) and is stored in block 4. From input 14, when requesting access to resources, block 5 from the OS receives the parameters of the process that requested the resource (name and full path of the process), the resource identifier and actions with the resource, block 5 compares the request with the access rights of the process ( from block 5) and generate There is (or not) a signal of permission to access a process from a resource that goes to block 8. It distinguishes a special class of processes, the so-called privileged processes, the request of which is processed by blocks 6 and 7. Their difference from the usual ones is that the access of these processes to resources is differentiated beyond the delimitation of access rights to user resources. Such processes may include systemic and other processes. For example, user access to the system drive (for example, drive C :) may be denied, but some processes must be granted this access, for example, system processes that write data to the registry, etc. It is necessary to open access to the system disk and application processes, for example, providing remote administration of a PC. Thus, privileged is understood to mean a process that is not subject to access restriction of the current user. These processes are processed in the same way as normal ones, by blocks 6 and 7. In block 6, the administrator after authorization by block 1 enters the access rights delimitation table, the access rights when requested are analyzed by block 7. Three permissive signals are received in block 8 - permission to access the user to the resource from block 3, the permission of the process to access the resource from block 5 and the privileged process access to the resource from block 7. Block 8 generates a permission signal to access the resource to exit 15 upon receipt of permission or from the exit ka 7, or simultaneously permissions from the outputs of blocks 3 and 5, i.e. skips authorized requests of privileged processes, authorized requests of other processes within the access permissions of the current (registered in block 1) user.

Thus, this system allows to provide differentiation of access to resources not only for users, but also for processes (programs) launched by a user to access resources.

The resources to which access by this system can be delimited can be not only file objects, but also OS registry objects, devices connected to the CS, including file, network addresses and host services of the local and global networks, etc. This is due to the fact that access rules are not physically tied to resources in any way - they are stored in a separate table (for example, in a separate file).

The prototype has the following fundamental disadvantages that limit its functionality.

1. Control (delimitation) of access to resources for the subject user and for the subject, the system process is carried out independently of each other. For each of these entities, the administrator sets his own access table (matrix). Access is permitted only if it is allowed to both the user (in accordance with his rights) and the process (in accordance with his rights). The system also has the ability to set access rights for exclusive processes - when controlling access to the resources of these processes, user access rights are not taken into account.

Consider what the implementation of this solution leads to. Let two users X1 and X2, two processes U1 and U2, two access objects Z1 and Z2 participate in the delimiting access policy. Suppose that it is required to allow user X1 to access object Z1 by process U1 and object Z2, to prohibit access to object Z2 by process U2, and to allow user U2 to access object Z2 by process X2. Consider the emerging contradiction. User X1 needs to allow access to both object Z1 and object Z2, then it will be necessary to deny access to object Z2 to process U2. But in this case, the X2 user will not be able to access the user X2. We also cannot establish privileged access (excluding user access rights) to the Z2 object for the U2 process, because for user X1, access by process U2 to object Z2 must be denied, and for user X2 it must be allowed. We see how limited the functionality of the system is - even such a simple differentiating access policy as the one considered in this example cannot be implemented.

2. The key opportunity in the implementation of access control (delimitation) based on the access table (matrix) (access rights of subjects to objects are located in separate blocks (for example, in files), and are not included as access attributes in objects), is the use of masks and environment variables for setting subjects and access objects in the delimiting policy (in the access table). Examples of using masks when defining subjects and access objects are given in Table 1.

Table 1 Examples of specifying subjects and access objects in a delineation policy using masks Example The job of the subject of access process Defining an Access Object one C: \ Windows * C: \ Windows * 2 C: \ Program FilesMntemet Explorer \ * D: \ 1 * 3 * .exhe C: \ Wmdows * .exe

The task of the access subject process and access object using masks are no different, because a process, as an access subject, is specified by the full path name (in this case, a mask) of its executable file. The advantage of implementing this method (using masks) of setting a delimiting policy of access to resources is determined by the fundamental simplification of the administration task, because with one entry in the delineation policy (in the access table), you can immediately “cover” the set (some group) of subjects or objects and set access rules for a group of subjects or a group of objects, respectively. At the same time, this (the use of masks when setting access rules) is also connected with the introduction of fundamental contradictions into the access control system. For example, consider the subject of access as a process defined by the full path name of its executable file, let C: \ Program FilesMntemet Explorer \ iexplore.exe. This is how this subject of access will be identified by the access manager from the access request. Suppose that in the delimiting policy (in the table) of access, different access rights are set for two subjects defined by masks: C: \ Program FilesMntemet Explored * and C: \ Program Files \ *. Exe. With both of these masks, the subject name of the process identified by the access manager from the access request C: \ Program FilesMntemet Explorer \ iexplore.exe is “covered”. The question arises, the rule for which subject (how a given subject) and on what basis to choose the access manager when processing this request. Naturally, you need to select from the table the rule that most accurately describes the subject identified from the access request. It is easy to justify that the rule C: \ Program FilesMntemet Explored * should be selected, but how does the well-known resource access control system (prototype) “know” about it? It does not provide for the possibility of choosing the required rule from the access table (matrix) in the event that the table contains several rules suitable for access request. Another problem is due to the fact that masks with varying degrees of accuracy in the access table can describe both subjects and access objects. An example of a contradictory task of two access rules when implementing access control to file system objects is given in Table 2.

table 2 An example of setting conflicting access rules using masks The rule Access Subject Assignment Defining an Access Object Access rights one C: \ Program FilesMntemet Explorer \ iexplore.exe D: \ 1 \ * Sn / th 2 C: \ Program Files \ * D: \ 1 \ User1 \ 1.doc Th

In the first rule, the subject of access is more precisely defined, in the second - the access object, and the access rights of the subject to the object in these rules are different. Let the C: \ Program FilesMntemet ExplorerMexplore.exe process ask the access manager to write to the file D: \ 1 \ User1 \ 1.doc. Which of the two rules should be accepted by the dispatcher (choose from Table 2 to analyze the access request) - whether to allow access requested in the request or not?

Based on the foregoing, the following conclusions can be made - the use of masks and / or environment variables in the access control policy for identifying access subjects and objects, which radically simplifies the administration task, introduces contradictions related to the choice of the required rule from the access table (matrix) when processing the request access. These contradictions are due to the fact that the same access request for identifying the subject and the access object can simultaneously fall under several rules (be “covered” by several rules at the same time), providing different access rights for the subject to the object (identified from the access request). The choice from the set of rules suitable for the analyzed access request defined in the access table (matrix) is not implemented in the known system. This significantly limits its functionality, since it generally does not allow the use of masks and environment variables to specify access subjects and objects in a delimiting access policy, i.e. the key functionality of access control implemented on the basis of the access table (matrix) cannot be implemented.

3. Control of the change of user name when accessing resources is not carried out. When implementing a delimiting policy of access to the resources of the COP, only the effective username is used.

In the present invention, the tasks of expanding the functionality of access control to resources through the use of an access subject are solved: “Original user, Effective user. Process".

To achieve a technical result, a system containing a user authorization block, the input of the user authorization block connected to the user authorization input, is additionally introduced: a block for creating a table (matrix) of access rules, a block for selecting a rule from a table (matrix) of access rules, a table storage unit ( matrices) of access rules for the subject “source user, effective user, process”, access request analysis unit, source user storage unit, the first input of the formation unit I of the table (matrix) of access rules is connected to the output of the user authorization block, with the second input of the rule selection block from the table (matrix) of access rules, the second input of the block for generating the table (matrix) of access rules is connected to the input of the job of the rule of creating the table (matrix) of access rules , the third input - with the input of setting the rules of access to the subject’s resources “source user, effective user, process”, the exit - with the input of the storage block table (matrix) of access rules for the subject “initial user, effec “user, process”, the output of which is with the first input of the rule selection block from the table (matrix) of access rules, the third input of which is with the input of the rule for selecting the rule from the table (matrix) of access rules, the fourth input is with the input of the subject’s access request a resource, with the second input of the access request analysis unit, the first input of which is with the output of the rule selection block from the table (matrix) of access rules, the output is with the permission / prohibition output of the requested access to the resource, with the first input of the source user storage unit, Torah input of which - with a third input of the selection rules from a table (matrix) of access rules, yield - a fourth input of block selection rule table (matrix) access rules to a third input of access request analysis unit.

New in the present invention is the provision of a system for restricting access to resources with a block for generating a table (matrix) of access rules, a block for selecting a rule from a table (matrix) of access rules, a storage unit for a table (matrix) of access rules for the subject “initial user, effective user, process” , an access request analysis unit, a source user storage unit and their relationships.

As a result of the analysis of the prior art by the applicant, including a search by patent and scientific and technical sources of information and identification of sources containing information about analogues of the claimed technical solution, no source was found characterized by features identical to all the essential features of the claimed technical solution. The determination from the list of identified analogues of the prototype as the closest in terms of the totality of the features of the analogue made it possible to establish the set of distinctive features pertaining to the applicant’s technical result of the distinguishing features of the claimed system for controlling access to computer system resources with the subject “Original user. Effective User, Process. " Therefore, the claimed technical solution meets the criterion of "novelty."

An additional search carried out by the applicant did not reveal known solutions containing features that match the distinctive features of the claimed system for controlling access to computer system resources with the subject “Original user. Effective User, Process. " The claimed technical solution does not follow for the specialist explicitly from the prior art and is not based on a change in quantitative characteristics. Therefore, the claimed technical solution meets the criterion of "inventive step".

The set of essential features in the present invention allowed for the expansion of the functionality of access control to the resources of a computer system.

As a result, we can conclude that

- the proposed technical solution has an inventive step, because it does not explicitly follow from the prior art;

- the invention is new, since the prior art on available sources of information did not reveal analogues with a similar set of features;

- the invention is industrially applicable, as it can be used in all areas where implementation of access control (access rights delimitation) to computer system resources is required.

The invention is illustrated by the drawing shown in Fig.2.

The inventive system of access control to the resources of a computer system with the subject "Original user. Effective user, Process ”contains: user authorization block 1, block for creating a table (matrix) of access rules 2, block for selecting a rule from a table (matrix) of access rules 3, storage unit for a table (matrix) of access rules for the subject“ user, process ”4 , an access request analysis unit 5, a storage unit for the original user 6, the input of the authorization unit of user 1 being connected to the authorization input of user 7, the first input of the unit for generating the table (matrix) of access rules 2 connected to the output of the authorization unit p user 1, with the second input of the rule selection block from the table (matrix) of access rules 3, the second input of the formation of the table (matrix) of access rules 2 is connected to the input of the rule for the formation of the table (matrix) of access rules 8, the third input is with the input of the rules access to the resources of the subject “source user, effective user, process” 9, exit - with the input of the storage unit table (matrix) of access rules for the subject “source user, effective user, process” 4, the output of which is with the first input of the block selecting a rule from the table (matrix) of access rules 3, the third input of which is with the input of the job of the rule for selecting the rule from the table (matrix) of access rules 10, the fourth input is with the input of the subject’s access request to resource 11, with the second input of the access request analysis block 5 whose first input is with the output of the rule selection block from the table (matrix) of access rules 3, the output is with the permission / prohibition output of the requested access to the resource 12, with the first input of the source user storage unit 6, the second input of which is with the third input of the selection block rule la from the table (matrix) of access rules 3, the output is with the fourth input of the rule selection block from the table (matrix) of access rules 4, with the third input of the access request analysis block 5.

Consider the operation of the access control system to the resources of a computer system with the access subject “Original user, Effective user, Process”.

An administrator setting up a differentiation policy of access to computer system resources, after identification and authentication from input 7 in block 1, gets access to blocks 2 and 3. From input 9, the administrator sets access rules, indicating in each rule which subject to which object which access rights It has. When defining rules, the administrator can use masks and environment variables. It is fundamentally important here that the subject of access is defined by one entity - “Original user. Effective user, Process ”(for storage of access rules one table (matrix) of access is used, block 4). In this case, access rights to objects are set for this entity, which has the following physical meaning: "such and such an effective user has the right to such and such access to such and such a process that was launched by such and such source user."

Examples of setting resource access rules, using the example of file system objects, are shown in Table 3.

Table 3 An example of setting resource access rules The rule Access subject “source user, effective user, process” Access object Access rights one User1, User1, C: \ Program FilesMntemet Explorer \ iexplore.exe D: \ 1 \ * Sn / th 2 User1, User1, C: \ Program FilesMntemet Explorer \ iexplore.exe D: \ * Th 3 *, *, C: \ Program FilesMntemet Explorer \ iexplore.exe * - four Useri, Useri, * D: \ 1 \ User1 \ * Sn / th 5 Useri, Useri, * D: \ * Th 6 Useri, System, * * -

Comment. The type of table (matrix) can be any, it is important that the appropriate fields are present: access subject (defined by the entity “source user, effective user, process”), access object (the way of setting depends on the type of resource), subject's access rights to the object (record , reading, executing, deleting, etc., the set of access rights depends on the type of resource).

Comment. In the access rules, in general, both allowed and prohibited access rights can be indicated, as well as their combinations (such-and-such right is allowed, for example, recording (Зп), such-and-such is prohibited, for example, (Th)).

The proposed technical solution is universal in the sense that, depending on the task of the access subject using masks, it can be used to differentiate access rights for both the entity “initial user, effective user, process” (main purpose), and only for users ( in the subject, the process is indicated by the mask “*” (All), see rules 4 and 5 in Table 3, while the change of user when accessing resources can be controlled or not), and only for processes (in the subject, users specify are marked with the mask “*” (All), see rule 3 in Table 3). As users, both interactive and system users can be set, respectively, as processes, both system processes and applications.

From input 8, the administrator sets the rule for creating a table (matrix) of access rules. This rule is interconnected with the rule for selecting a rule from the table (matrix) of access rules set by the administrator in block 3 from input 10. The table (matrix) of access rules formed from the rules set by the administrator from input 9 according to the rule specified by the administrator from input 8 is written in block 4, where it is stored during the operation of the computer system.

The subject’s access request to the object enters the system from input 11 to blocks 3, 5, and 6. This request contains the user name (effective), the full path name of the process executable file, the resource name (for example, the full path name of the file object to which access is requested, if access rights are delimited to files) and the requested access right is write, read, execute, delete, rename, etc.

Comment. The user can be identified in the system by both the name of the account and its identifier in the system (SID), in the separation policy (in the rules) and in the access request, they must be identified identically, preferably SID.

According to the rule set by the administrator from the gathering 10, block 3 from block 4 selects the access rule that most accurately (in accordance with the selection rule) corresponds to the access request received at input 11. This rule is passed to block 5, which evaluates the consistency of the requested and allowed a delimiting policy of access rights of the subject to the object, as a result of which it allows or rejects access requested from input 11 from system output 12.

If access to file execution is requested from input 11 (process start), and this right is allowed from output 12, block 6, which also receives an access request from input 11 containing the full path file name (in this case, the executable) and the name of the user requesting access (in this case, the start of the process), and from the output of block 5, access permission (in this case, the permission to start the process by the user), which user remembers which process was started, is recorded (or updated if the process was started earlier alsya another user) the original user name to the executable process.

When requesting access from input 11, block 6 identifies the process (by the full path name of its executable file) requesting access. When the access request from the input 11 by the block 6 is saved, which is relevant for this process, it is issued in blocks 3 and 5. As a result of this, an access request is generated in blocks 3 (to select a rule) and 5 (to analyze the request for compliance with the selected rule), defined as the original user (coming from block 6), the effective user, the process (coming from input 11).

Now about the rules for creating a table (matrix) of access rules and selecting a rule from a table (matrix) of access rules. As noted, they are interconnected. These rules can be established in various ways. Let's look at a few examples. The rule for creating a table (matrix) may consist in ordering the location in the table of rules set by the administrator according to the accuracy of descriptors of subjects and access objects in the rule, for example, from top to bottom. An example of such ordering is given in Table 3. In this case, the selection rule from the table consists in sequentially analyzing the rules from the table (from top to bottom) with the definition of the first matching rule for the query (“covering” the query). This rule will be selected by block 3. For example, see Table 3, if User1 requests access to the file D: \ 1 \ User1 \ Test.doc by the Word editor launched by User1, block 3 will be selected from the rules table rule 4, and in block 5 they will be given the following access rights allowed for the analyzed request - Sn / Th. In the simplest case, the administrator can arrange the rules when creating the table manually (then the system does not require the use of input 8, the rules will be generated in block 4 by block 2 in the order they were received from input 9), or automatically by block 2. In this case, from input 8, they must the rules for creating a table (matrix) of access rules (the rules for ordering access rules in block 2 when creating a table stored in block 4) are set.

You can not order the rules in the table (matrix) when it is created (enter the rules in the table as they are set by the administrator), in this case you will not need to use block 2. But this will require, when analyzing the access request, to select all the rules from the table, “ covering "the analyzed request, and then select from them the rule characterized by more accurate descriptors of the subject and access object determined from the request in the rule. In this case, this task should already be solved by block 3 in the analysis of each access request, which will have a much greater impact on the loading of the computing resource than in the case of ordering the rules in the table (matrix) of access rules.

It is also possible to arrange access rules in a table by applying the “weights” of access rules. Depending on the accuracy of the descriptors of the subject and the access object in the rule, block 2 is assigned the “weight” (a certain numerical characteristic, for example, the more accurate the descriptor of the subject and object in the rule, the higher the “weight” of the rule). In this case, the actual ordering of the rules by block 2 in the table is not performed. When access is requested by block 3 from the table, all the rules are selected that "cover" the analyzed request, from which the rule with the maximum "weight" is selected - the procedure for choosing a rule is simplified compared to the previous method.

Other options are possible. A criterion for their effectiveness is to minimize the computational complexity of the choice problem solved by block 3, since the selection of a rule from the table should be carried out with each access request.

Now about the rules for ordering the rules in the access table (matrix). Here are some basic rules (in general, they may differ, which is determined by the administrator when configuring the system from input 8, if necessary and / or from input 10).

Let us consider an example of rules for ordering rules in a table (matrix) of access as applied to file objects (when controlling access to other resources, the rules, in terms of determining the accuracy of setting the access object, may differ). These rules also apply when ordering the names of processes in an access subject (defined by the full path names of their executable files). The basic rules are as follows:

1. A more accurate (long — the length is determined by the number of “\” characters in the name of the file object specified in the delimiting policy) is detected; the file object descriptor. For example, D: \ 1 \ User1 \ * the descriptor is more accurate, because it is longer than the descriptor D: \ 1 \ *.

2. For the same length of the descriptor, the priorities of the accuracy of setting the object are used — these are (by priority) the exact file indication, file mask, exact directory designation, catalog mask, mask. For example, the D: \ 1 \ User1 \ Test.doc descriptor is more accurate than the D: \ 1 \ User1 \ Test * descriptor (specifying the file and mask).

Now, regarding the ordering between the determinants of the elements of the access subject - user names (initial and effective) and the name of the process (access subject contains two elements). Since the name of the process is a qualifying element of the access subject, designed to lower or increase user rights when working with a specific process (application), the more accurate pointer to the element of the access subject is higher than the more accurate pointer to the element of the access subject. For example, in Table 3, rule 3 has a more accurate access subject index than rules 4 and 5.

Regarding the ordering between the determinants of the access subject and access object. Since the entire delimiting access policy is ultimately implemented between the access entities - the access rights of subjects to objects created by such an entity are differentiated (indirectly, through the assignment of access rights to file objects), the more precise priority in the delimiting access policy is pointer of the access subject, compared with the pointer of the access object. For example, in Table 3, rules 1-3 take precedence over rule 4.

These are the basic rules. Using the basic rules and the initially specified selection rule by block 3 from block 4 (for example, based on the ordering of access rules in the table) allows you to not use inputs 8 and 10 in the system, however, in general, for specific protection tasks, the basic rules can be modified by the administrator , therefore, in general, inputs 8 and 10 should be included in the system.

Let us evaluate the achievement of the goal - the solution to the problem of expanding the functionality of access control to resources through the use of the access subject: “Original user, Effective user, Process”.

1. There are no contradictions present in the prototype — any differentiation policy can be correctly implemented by setting access rights for the subject “Initial User, Effective User, Process” (and not separately for the subject user and the subject process, as in the prototype). Let us illustrate what has been said with the example considered earlier. Let two users X1 and X2, two processes U1 and U2, two access objects Z1 and Z2 participate in the delimiting access policy. Suppose that it is required to allow user X1 to access object Z1 by process U1 and object Z2, to prohibit access to object Z2 by process U2, and to allow user U2 to access object Z2 by process X2. To solve this problem, it is enough to allow subject X1, U1 to access object Z1 and object Z2, subject X1, U2 to deny access to object Z2, subject X2, U2 to allow access to object Z2. There are no contradictions.

2. Labels and environment variables can be used to set a delimiting policy of access to resources, since the claimed system provides the ability to correctly select a rule from a variety of rules that "cover" the same access request located in the access table (matrix).

3. The change of user is controlled when accessing the resources of the COP. This problem is solved in the general case, since the fact of changing the user when accessing the resource is controlled and fixed by the system, regardless of the implemented method of changing the user, including using the avatar services provided by modern OSs. This allows you to implement protection against attacks on privilege escalation, aimed at circumventing the delimiting policy of access to the resources of the COP.

The invention is industrially applicable in terms of the possibility of technical implementation of the blocks included in the system.

The technical implementation of all units of the system is based on standard solutions for storing and processing data, for processing data (including their selection), stored in tables.

This decision was tested by the applicant when building a prototype of a means of protecting computer information.

All used blocks are technically feasible and their implementation is achieved by standard means.

Thus, in the present invention solved the problem of expanding the functionality of access control resources, through the use of the access subject: "Original user identifier", "Effective user identifier", "Process".

The resources to which access by this system can be delimited can be not only file objects, but also OS registry objects, devices connected to the CS, including file, network addresses and host services of the local and global networks, etc. This is due to the fact that access rules are not physically tied to resources in any way - they are stored in a separate table (for example, in a separate file).

Given the current level of development of computer technology, it is technically feasible.

Claims (1)

A system for controlling access to resources of a computer system with the subject “Initial User, Effective User, Process”, comprising a user authorization unit, the input of the user authorization unit being connected to the user authorization input, characterized in that it additionally includes: table (matrix) generating unit access rules, a block for selecting a rule from a table (matrix) of access rules, a storage unit for a table (matrix) of access rules for the subject “initial user, effective user, process”, b access request analysis lock, initial user storage unit, the first input of the access rule table (matrix) generating unit connected to the output of the user authorization block, the second input of the rule selection block from the access rule table (matrix), the second input of the table (matrix) generating unit access rules is connected to the input of the task of creating the table (matrix) of rules of access, the third input - with the input of the rule of access to the resources of the subject “source user, effective user, process”, you od - with the input of the storage block table (matrix) of access rules for the subject “source user, effective user, process”, the output of which is with the first input of the rule selection block from the table (matrix) of access rules, the third input of which is with the input of the job of the selection rule rules from the table (matrix) of access rules, the fourth input - with the input of the subject's access request to the resource, with the second input of the access request analysis block, the first input of which is with the output of the rule selection block from the table (matrix) of access rules, the output is with the exit decision / prohibition of the requested access to the resource, with the first input of the storage unit of the original user, the second input of which is with the third input of the rule selection block from the table (matrix) of access rules, the output is with the fourth input of the rule selection block from the table (matrix) of access rules, with the third input of the access request analysis block.

Images