RU2543556C2 - System for controlling access to files based on manual and automatic markup thereof - Google Patents

Abstract

FIELD: physics, computer engineering.

SUBSTANCE: invention relates to protecting information generated and stored in computer systems from unauthorised access. The system for controlling access to files based on manual and automatic markup thereof comprises a decision unit, an automatic file markup unit, a file access rule storage unit, a manual file markup unit, a file markup control unit, a file attribute storage unit, wherein the first input of the decision unit is connected to the first input of the system, the first input of the automatic file markup unit, the second output is connected to the output of the system, the second input of the automatic file markup unit is connected to the third input of the system, the first output is connected to first input of the file markup control unit, the second input of which is connected to the first output of the manual file markup unit, the second output of the automatic file markup unit is connected to the third input of the file markup control unit, the fourth input of which is connected to the second output of the manual file markup unit, the fifth input is connected to the output of the file attribute storage unit, the first input of which is connected to the third output, and the second input is connected to the fourth output of the automatic file markup unit, the first output of the file markup control unit is connected to the third input of the automatic file markup unit, the second output is connected to the third input of the manual file markup unit, the first input of which is connected to the fourth, and the second is connected to the fifth input of the system, the third output of the automatic file markup unit is connected to the first input of the file access rule storage unit, the second input of which is connected to the second input of the system, the third input is connected to the second output of the decision unit, the second input of which is connected to the output of the file access rule storage unit.

EFFECT: high efficiency of controlling access to files.

2 dwg, 5 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 and stored in computer systems (CS).

One of the key tasks of protecting information processed in the CS is the implementation of access control (delimiting access policy) to file objects, which can be designed both for storing information processed on a computer - created files, and for storing system objects - executable files and files OS and application settings - system files.

Analysis of literary sources allows us to note the following. Despite the fact that the most urgent modern task of access control is to implement a delimiting policy of access to information between access entities (the access subject is generally determined by the user’s account information and the process name (the full path name of the process executable file), in practice, the access of subjects to objects is differentiated. .e. the primary object when assigning access rights delimitation in known access control methods is an object, access rights of subjects are delimited to it. The main contradiction in such decisions consists in the following: there are simply no files created when the administrator defines a differentiated access policy, they are created subsequently during the system’s functioning, the question arises: how to differentiate access if they are not already in the CS? those objects (primarily files), which, in the first place, need protection against unauthorized access, since it is they that contain the protected information processed in the CS.

In known methods, the implementation of access control to static and to created file objects does not differ. In any case, access control is implemented to static (created prior to the system administration - assignment of access rights to subjects' objects) objects by assigning attributes to an object (access rights of subjects to objects). There are two possibilities for assigning rights. The first one consists in solving the task of setting access rights to the created object indirectly by including in the system at the time of setting the differentiation policy of access the corresponding static including objects - folders (a kind of “containers”), access to which is differentiated by the administrator, including creating them new objects. At the same time, the user is “forced” to create new file objects (files) only in those folders (containers) that are specially created for these purposes by appropriate delineations. The created file objects inherit access control from the corresponding inclusive objects.

As you can see, in this case access to the created objects (files) is not carried out as such, the file generally “disappears” as an entity from the delimiting access policy - it uses two entities - the access subject and the specially created container - the access object (folder). This approach implies the additional creation by the administrator of an inclusive object (with the assignment of access rights to subjects for it) for each subject (group of equal subjects) of access, which in itself is a complex administrative task. The task of administration is complicated many times if the subject of access should be not only an account, but also the process (application) itself, without which effective protection cannot be created in modern conditions. In this case, ultimately, the task of access control is to implement a differentiating policy of access between subjects of access to information processed on a computer, and not to set a differentiating policy of access of subjects to objects (objects are an additional (redundant) link in the access control scheme, the use of which limits the functionality of the access control system and dramatically complicates the administration task).

The second possibility is to use the “Ownership” entity in the access control policy provided by modern universal operating systems, the essence of which is that the user who created the object (the “Owner” of the object) is empowered to differentiate access rights to this object for other users. In this case, despite the fact that, again, access rights in the form of attributes are ultimately assigned to a static object (the owner of the file after its creation - only after the creation of the file, the owner can assign access rights to this file), in a certain sense, you can talk about access control to the created files, since access rights to the created file are assigned by the owner user after the administrator sets the delimiting policy of access to objects. This is achieved due to the fact that the administration scheme itself is being changed, directly the way to set a differentiating policy - continuous administration is being implemented during the functioning of the system.

However, the administration functions are no longer assigned to the administrator, but directly to the user, which is unacceptable when building secure CAs in modern conditions, when an authorized user (insider) carries the most likely threat of unauthorized access to information processed on the CS.

Currently, various file access control systems are known.

So, for example, in application EPO N 0192243 (CL G06F 12/14, 1986) a method for protecting system files is described in which information defining the access rights of system users remains all the time in a secure processor.

Patent No. 2134931 (class H04L 9/32, G06F 12/14) describes a method for providing access to objects in the operating system based on the assignment of security labels to subjects and access objects, while for each object of the operating system they are formed in advance and then stored in memory signal label of the object, i.e. access rights to objects assigned in the form of security labels must again be assigned by the administrator to static objects (folders). In the delimiting access policy, there are two entities - the subject and the access object, security labels must be assigned by the administrator and the subjects and access objects.

Closest to the technical solution and chosen by the authors for the prototype is a file access control system implemented in Microsoft Windows with the NTFS file system, which uses file attributes to store file permissions (ACLs) (in particular, Security Descriptor - this attribute contains information on file protection: ACL access list and audit field, which determines what kind of operations on this file should be registered) [M. Russinovich, D. Solomon. Microsoft Windows internal device. - SPb .: Peter, 2005 - 992 pp. (Chapter 8, Fig. 8.5. An example of checking access rights)].

The system is presented in figure 1. The file access control system contains a deciding unit 1, a file attribute storage unit 2, the first input of the deciding unit being connected to the first input of the system 3, the second input to the output of the file attribute storage unit 2, the first output to the first input of the file attribute storage unit 2 , the second output is with the output of system 4, the second input of the file attribute storage unit 2 is connected to the second input of system 5.

The system works as follows. The administrator or the “Owner” (the user who created the file) from the second input of the system 5 (from the input of setting the file access attributes) to the file attribute storage unit 2 sets the attributes (rights) of access to the files (to objects) of the entities in which for each file It indicates which entities have the right to access and which they are allowed to access the file (read, write, execute, rename, delete, etc.). When requesting access, which contains the name of the subject (the name of the user (account) and the name of the process requesting access, as well as the requested access rights - reading, writing, etc.) to the file, access request from the first input of system 3 ( from the input of the file access request) goes to the decisive block 1. To process the access request, the decisive block from the first output requests the file attributes storage block 2 for the attributes of the file to which access is requested, receives them at the second input, and compares the requested file permissions with permitted ravami access to the file specified in the file attributes. As a result of the comparison, the decisive unit issues a control signal to the output of system 4 (to the control output of the access permission / deny), allowing (if the request does not contradict the permissions) or rejecting the access requested from the system from the first input of system 3.

The disadvantage of the prototype is that it allows you to implement a delimiting policy of access to static objects (to objects created by the administrator before assigning access rights to folders), to files created in them only indirectly through static objects - folders. The entire demarcation policy is implemented for two equal entities - the subject and the access object - access rights to the objects of the subjects are established. The practical ability to assign access rights to the files created by them by the owners does not allow building a secure CS; as a result, it should not be used in modern CSs - the user should be excluded from the administration (assignment of rights) file access rights scheme. All this limits the functionality of the file access control system and significantly complicates its administration.

The present invention solves the problem of expanding the functionality of controlling access to files and simplifying the task of administering an access control system by eliminating the entity “object” from a delimiting file access policy.

To achieve a technical result, a file access control system containing a decision block, a file attribute storage unit, the first input of the decision block is connected to the first input of the system, the second output to the system output, an automatic file markup block, an access rules storage block are added files, a manual file marking unit, a file marking control unit, the first input of the deciding unit being connected to the first input of the automatic file marking unit, the second input of which is connected to the third input system, the first output is with the first input of the file markup control unit, the second input of which is with the first output of the manual file markup unit, the second output of the automatic file markup unit is connected to the third input of the file markup control unit, the fourth input of which is with the second output of the manual markup unit files, the fifth input is with the output of the file attribute storage unit, the first input of which is with the third output and the second input is with the fourth output of the automatic file marking unit, the first output of the file markup control unit s is connected to the third input of the automatic file marking unit, the second output to the third input of the manual file marking unit, the first input of which is the fourth and second to the fifth input of the system, the third output of the automatic file marking unit is connected to the first input of the access rule storage unit to files, the second input of which is with the second input of the system, the third input is with the second output of the decisive block, the second input of which is with the output of the file access rules storage block.

New in the present invention is the provision of a file access control system with a file access rule storage unit, an automatic file markup unit, a manual file markup unit, a file markup control unit and their associations.

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 analogue in terms of the totality of features made it possible to establish the combination of the distinguishing features of the claimed file access control system based on their automatic marking relative to the technical result perceived by the applicant. Therefore, the claimed technical solution meets the criterion of "novelty."

An additional search conducted by the applicant did not reveal known solutions containing features that match the distinctive features of the claimed file access control system based on their automatic marking. 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 to expand the functionality of access control to files and simplify the task of administering an access control system by eliminating the entity “object” from the delimiting policy of access to files.

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 files is required.

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

The inventive access control system for files based on their automatic markup contains: a decisive unit 1, an automatic file markup unit 2, a file access rule storage unit 3, a manual file markup unit 4, a file markup control unit 5, a file attribute storage unit 6, the first input of the decision block 1 is connected to the first input of the system 7, with the first input of the automatic file marking unit 2, the second output is with the output of the system 8, the second input of the automatic file marking unit 2 is connected to the third input of the system 10, the first output one - with the first input of the file markup control unit 5, the second input of which is with the first output of the manual file markup unit 4, the second output of the automatic file markup unit 2 is connected to the third input of the file markup control unit 5, the fourth input of which is with the second output of the manual block file markup 4, the fifth input with the output of the file attribute storage unit 6, the first input of which with the third output, and the second input with the fourth output of the automatic file markup 5, the first output of the file markup control unit 5 with the third input of the automatic file marking unit 2, the second output with the third input of the manual file marking unit 4, the first input of which is the fourth 11 and the second with the fifth 12 system input, the third output of the automatic file marking unit 2 is connected to the first input of the block storing file access rules 3, the second input of which is with the second input of system 2, the third input is with the second output of the deciding unit 1, the second input of which is with the output of the file access rules storage block 3.

First, we consider the operation of the access control system for files created during the operation of the system based on their automatic markup using various practical examples of its use. Here, access to files created during the system’s work is delimited. The delineation policy consists in setting the access rights of subjects to files created by other entities.

Example 1. Discretionary (selective) control of access to created files

1.1. Differentiation by users (for accounts). From input 10 to block 2, the administrator sets access to files created by which entities (under which accounts), it is necessary to control (delimit), for example, let it be User1 and User2 (let 4 users be created on the computer - User1, User2, User3, User4). All files created by these users (User1 and User2) will be automatically marked out by the system when they are created - the credentials of the user (SID or name) that created the file will automatically be recorded in the attributes of the files they create (in block 6) when they are created. If these users modify previously created files (not yet marked) or files created by User3, User4 (access to them is not controlled - these files are not marked), they will also be marked in block 2 in the same way. From input 9 to block 3, the administrator sets access rules for marked up (created) files, for example, in the form of a table (or matrix) of access, see Table 1. As you can see, the entity “object” is excluded from the delimiting access policy; all delimitations to the created files are set between access entities, in the considered example by users, see Table 1.

Table 1 An example of a demarcation policy of user access to created files Access rule The user who created the file (these files are automatically tagged) The user who has the right to access the created (marked up) file Permitted access rights to the created (marked up) file one User1 User1 Read, write 2 User2 User2 Reading, writing 3 User1 User2 Reading four User1, User2 User3, User4 Access denied

Upon receipt of file access request system 7 (the request contains the user name, process name and the requested access right — write, read, etc.), upon request from the first output of block 2 to the first input of block 5, from the output of block 5 of block 6, the access attributes of the file to which access is requested are requested (the markup of the file created by block 2 is the accounting information of the person who created this file), arriving (under control of block 5) to the third input of block 2. This data, or information about the absence of file attributes subject information (file was not previously marked) who created the file, block 2 is transferred to the unit 3 - the first input. If the file to which access is requested was not previously marked (its attributes do not contain the accounting information of the subject that created it), or a new file is created, and the access request (to create an entry leading to file modification) comes from the controlled subject, then from the second output of block 2, the file to which access is requested is automatically marked out under the control of block 5 - the account information of the person who created / modified the previously unallocated file is recorded in its attributes from the second input of block 6.

In block 3, the first input from the third output of block 2 receives the name of the access subject defined by block 2, who created the file to which access is made, or information that the file is not marked, i.e. access to it is not controlled. Based on this information, block 3, using the column of the access table (matrix): “The user who created the file (these files are automatically marked out)”, see Table 1, selects the appropriate access rules for the markup file to which access is requested. Upon request, from the first output of the decision block 1 by block 3 to the second input of block 1, the appropriate access rules selected by him or the information that the requested access (access to the requested file) is not controlled are issued.

Comment. There can be several suitable rules in the general case, including due to the possibility of using masks and regular expressions. An example of setting rules using the "All" mask (denoted by "*") is given in Table 2.

table 2 An example of a demarcation policy of access to created files using the mask “All” (“*”) Access rule The user who created the file (these files are automatically tagged) The user who has the right to access the created (marked up) file Permitted access rights to the created (marked up) file one User1 User1 Reading, writing 2 User1 * Access denied

In Table 2, the two rules completely isolate the work of User1. Only he will be able to access the files he creates. No other user (which is specified by the "*" mask) has access rights to files created by User1.

As can be seen from Table 2, both of the specified rules relate to the rules related to files created by User1. In this case, both of these rules will be transferred to the second input by block 3 upon request of the decisive block 1.

An access request is received at the first input of the decisive block (the request contains the user name, process name and the requested access right — write, read, etc.), and the second input contains access rules for the file to which access is requested. The decisive block 1 for a more accurate description of the subjects in the fields of the access table (matrix) is in the columns: “The user who created the file (these files are automatically marked out)” and “The user who has access to the (created) marked-up file”, see Table. 1, the rules passed to him, selects the rule that most closely relates to the request. For example, see Table 2, if the request made by User1 is to a file created by User1, then the first rule will be selected as a decisive block (the first rule according to the subject descriptor more closely matches the access request), if it asks for access to such a file user User2, then the second rule will be selected.

After choosing a rule, the decisive unit 1 analyzes the conformity of the access request to the file specified for it to the selected access rule and, as a result of this analysis, generates a control signal to output 8 (from the second output) that allows or rejects the access requested from the system.

As you can see from this example, the system administration steps are simple. The administrator sets once (during the installation of the system) rules in the form of a table (matrix) of access, which apply to all files created during operation, wherever (in which folders) they are created. Those. delimitations are established at the moment of the absence of created files and apply to all files created during the operation of the CS. The access object is excluded from the administration scheme - all distinctions are established exclusively between the subjects.

1.2. Process separation

The operation of the system almost completely coincides with the work described earlier (where the user - the account acted as the subject of access). The difference in this case is that the process is already defined as the subject of access, defined in the system by the full path name of its executable file. The full path name of the process executable file also acts as accounting information automatically recorded in the file attributes. The table (matrix) of access changes accordingly.

Let us consider the operation of the system as an example of solving an extremely urgent modern protection task - protection against attacks on Internet browsers. Most of these attacks are aimed at introducing and launching malware into the CS, stealing (confidentiality violation) of information processed in the CS, violating its availability (deletion) and integrity (unauthorized modification).

For example, let’s use the Internet Explorer browser, the executable file of which has the following full path name: E: \ Program Files \ Internet Explorer \ iexplore.exe.

An example of a delimiting policy for accessing processes to created files is given in Table 3.

Consider what protection features can be implemented by the delineation policy presented in Table 3. Firstly, as you can see, all files created during the operation of the CS are marked (this follows from the second rule - you need to control the files created by all processes, - the mask “All”, respectively “*” is set) - as subjects in the attributes of the created files when marking up the created files, the processes (full-path names of their executable files) that create the file are indicated.

Table 3 An example of a delimiting policy of access of processes to created files Access rule The process that created the file (these files are automatically tagged) The process that has the right to access the created (marked up) file Permitted access rights to the created (marked up) file one E: \ Program Files \ Internet Explorer \ iexplore.exe E: \ Program Files \ Internet Explorer \ iexplore.exe Read, write 2 * E: \ Program Files \ Internet Explorer \ iexplore.exe Access denied 3 E: \ Program Files \ Internet Explorer \ iexplore.exe * Reading, writing

As can be seen from Table 3, the browser can only access files created by it, while it cannot execute them (protection against malicious programs being launched by the browser), and cannot access files created by other applications. All other access subjects also cannot run (execute) files created by the browser (protection against launching malicious programs created by the browser).

As you can see, all the most relevant modern protection tasks listed above are solved in full.

This example confirms a significant expansion of the functionality of the file access control system; many relevant modern protection tasks can be solved due to the possibility of isolating the work of applications with the files they create.

Regarding the ease of administration, the entire delimitation policy is set by three lines in the access table (matrix), see Table 3.

1.3. Differentiation by users and processes

The first two examples (1.1 and 1.2) illustrate how to isolate the work of users or processes on the CS with the simplest settings (with the specified rules for their interaction with each other). In the general case, the access request received at the first input of the system 5 contains both the user name (account) and the process name. Accordingly, it is possible to isolate the work of individual users with individual processes. The access subject in this case is determined by two entities “user, process”. Two entities, the user (account), and the process (full path name of the process executable file) act as the accounting information automatically recorded in the attributes of the file being created (modified if there is no markup in it).

An example of a differentiating access policy with this method of determining the access subject is given in Table 4.

The delimitation policy is analyzed by analogy with how in previous cases, taking into account the task of the subject of access by two entities - the user and the process. As you can see, the functionality of the file access control system is expanding even more significantly, with virtually no complication of system administration.

Table 4 An example of a delimiting policy of access of subjects “user, process” to created files Access rule The subject (user, process) that created the file (these files are automatically marked out) The subject (user, process) having the right to access the created (marked up) file Permitted access rights to the created (marked up) file one User1, E: \ Program Files \ Internet Explorer \ iexplore.exe User1, E: \ Program Files \ Internet Explorer \ iexplore.exe Reading, writing 2 User1, E: \ Program Files \ Internet Explorer \ iexplore.exe User2, * Access denied 3 User1, E: \ Program Files \ Internet Explorer \ iexplore.exe User2, E: \ Program Files \ Internet Explorer \ iexplore.exe Reading

Example 2. Mandate (authorized) access control to created files

Mandatory access control in the general case is understood as a method of processing requests for access to file objects based on a formal comparison, in accordance with specified rules, of security labels (credentials) assigned to subjects and access objects (in general, groups of subjects and objects). Security labels, as a rule, are elements of a linearly ordered set M = {M1, ..., Mk} and serve to formalize any properties of subjects and objects.

Access control is implemented based on the rules that define the linear order relation on the set M, where for any pair of elements from the set M one of the types of relations is defined: greater, less, equal (in practice, the choice is made of a subset of M isomorphic to a finite subset of natural numbers - such the choice makes arithmetic comparison of security labels natural). Rules for comparing labels are also assigned from any properties of subjects and objects as applied to the task of protecting information.

The widest practical use of the credential method has been found to be the practice of secret paperwork in computer processing of information. The basis for the implementation of the processing of categorized information is the classification of information by level of confidentiality. Object security labels reflect the confidentiality category of information that can be stored in the respective objects. The security labels of the subjects reflect the powers (by analogy with the admission form) of the subjects in terms of access to information of various levels of confidentiality.

We assume that the higher the subject’s authority and the level of confidentiality of the object, the lower their sequence number in the linearly authorized sets of subjects and objects - C = {C1, ..., Ck} and O = {O1, ..., Ok}), the smaller the value of the security label Mi, i = 1, ..., k is assigned to them, i.e.: M1 is less than M2, less than M3, less ..., less than Mk.

Thus, as the accounting information of subjects and access objects, in addition to their identifiers - names, each subject and object is assigned security labels from the set M.

We introduce the following notation:

- Ms - security label of the subject (group of subjects) of access;

- Mo - security label of the access object (group of objects).

In practice, the following access control rules are widely used for mandatory access control, which is used to protect against information privacy violations:

1. Subject C has access to object O in the "Read" mode if the condition is met: Ms is not more than Mo.

2. Subject C has access to object O in the "Record" mode if the condition is met: Ms is Mo.

3. In other cases, access of subject C to object O is prohibited.

However, other rules are also possible, for example, rules for completely isolating the processing of information at various levels of confidentiality or when users perform various roles in the CS (non-hierarchical labels):

1. Subject C has access to object O in the "Read", "Write" mode if the condition is met: Ms is Mo.

2. In other cases, access of subject C to object O is prohibited.

As you can see, the access rights of subjects to objects are also differentiated here, while security labels must be assigned to both subjects and access objects.

A distinctive feature of the access control method implemented in the claimed technical solution is the exclusion of the entity “access object” from the delimitation policy. Differentiation is carried out exclusively between the subjects of access, and not indirectly through the object.

As controlled objects, files created during the operation of the system are considered, which directly contain the protected information. The task of a delimiting access policy when implementing mandatory access control here consists solely in assigning security labels to MS entities.

Access control is as follows. When a subject creates a new file, the file inherits the access subject's accounting information - its security label Мс (we denote the inherited label МСО, when creating the file МСО is taken equal to Мс of the subject creating the file). When requesting access to any file, the presence is analyzed, and if there is, the actual value of the MCO security label inherited by this file. If the MCO file has a label, this label is compared with the label of the subject who requested access to the file. Mc - analyzes the implementation of specified access control rules. As a result of the analysis of this information, taking into account the implemented access control rules, the access to the file requested by the subject is either allowed or denied.

The rules aimed at protecting against downgrading the category of processed information with regard to the use of the claimed technical solution (security labels are assigned only to access entities) are as follows:

1. Subject C has access to object O in the "Read" mode if the condition is met: Мс not more than МСО.

2. Subject C has access to object O in the "Record" mode if the condition is met: Ms is equal to Mso.

The system, in fact, works in this case in the same way as in the previously considered example 1.1. Consider only the differences, which are as follows. From input 9 in block 3, correspondence of security labels to access subjects is set (security labels are assigned to MS entities, and only to those entities whose access to the created files should be controlled). In addition, in block 3, the rules for comparing the labels Мс and Mco are defined on the relation: more, less, equal. In block 2, from the input 10, access subjects are set, access to the created files of which should be controlled by assigning them security labels Мс. When creating a file or when modifying a previously unallocated file by block 2 (under the control of block 5), the Ms mark is entered into the file attributes, which at the same time becomes the Mso mark of the marked file. When accessing the marked-up file by block 2, the label of the MCO file to which access is requested is read from the file attributes stored in block 6, or information that the file is not marked (no label). The label of the subject who requested access, Ms, the label of the file to which access is requested, MCO come from block 2 to block 3, from where they are transmitted, together with the specified label comparison rule, to decision block 1. The decision block 1 compares the labels in accordance with the specified rule, on the basis of which it outputs to output 8 the corresponding control signal for permission / prohibition of the requested access.

Now about the merits of the described technical solution for implementing mandatory access control.

1. Ease of administration. It is enough for the administrator to assign security labels (credentials) only to access entities (usually users), and then only to those users whose access to the files created will be controlled, and assign rules for comparing labels on the relation: more, less, equal. And that’s all! No objects are required to be assigned labels, which in practice is an extremely difficult task, since all objects, including system ones, that do not fit into the categorization scheme of information processed in the CS, are required to assign security labels.

2. The correctness of the implementation of the access control policy based on security labels in the general case. The point is as follows. In the system and in applications there are resources (folders) that are not shared between users. As a rule, for such an application to work, it is necessary to allow write access to such a folder to all users who can be assigned various labels. Firstly, it immediately nullifies the whole access control scheme (there is no need to talk about the correctness of the implementation), secondly, how to do this if the object can be assigned only one security label (it cannot be several privacy categories at once - information either secret or open)? When using the claimed technical solution, files are directly marked up automatically when they are created, in whatever folders (shared or not) they are not created, which removes the controversy and allows you to correctly implement a differentiating access policy based on security labels!

Now some examples for solving private security problems.

Example 3. Protection against the launch of malicious programs on a protected COP.

Part of the solution to this protection problem we reviewed earlier.

The relevance of this protection task in modern conditions does not cause any doubt. The solution to this problem in relation to the claimed access control system is extremely simple and consists in preventing the launch (execution) of files created during the operation of the system.

When implementing discretionary access control, see example 1.1 (similarly, you can implement it in the framework of example 1.2), the access table (matrix) for solving this problem will be the simplest, see Table 5.

Table 5 An example of a delineation policy that prevents the execution of created files Access rule The user who created the file (these files are automatically tagged) The user who has the right to access the created (marked up) file Permitted access rights to the created (marked up) file one * * Reading, writing

As you can see from Table 5, any created file (a file created by any user) to any user (all this is assigned with the mask “*”) can only be read and written - cannot be executed. That's all! With such distinctions, it is impossible to run an unauthorized file created on the CS (a malicious program installed on the computer during the operation of the CS)! And what is important, no signature and behavioral analyzes, no definitions of the executable object by extension or otherwise incorrect way. The executable object is determined solely from the request — in this case, from the request to execute the file.

For this example, the accounting information that is automatically recorded in the file attributes when it is created can be simplified - just indicate the sign that it is created (was created during the operation of the CS), which should be written (and read accordingly) by block 2 to / from block 6 when creating the file. The rule that is written in block 2 is a ban on the execution of the created (marked up when creating / modifying previously unallocated) file.

That's all, and what is the most urgent task of protection is being solved, while virtually no system administration is required.

Example 4. Protection against unauthorized modification of executable objects

In the examples above, we considered the implementation of access control to created files, however, the claimed technical solution allows access control to static (system) files based on their automatic layout.

Consider this as an example of protection against unauthorized modification of executable files (OS and applications).

The idea of protection is that the executable file should not be modified during the operation of the system (by the way, a lot of existing attacks, including those related to errors in Internet browsers, are aimed at unauthorized modification of executable files, first of all). This is the access control rule that is recorded in block 3. The markup rule is written in block 2 - those files that are requested access to execution are automatically marked (marked as executable). The solution is as follows. When accessing the file for execution (the executable file is identified precisely from the request received at the system input 7, which prevents false positives), the file is marked up (if it has not been previously marked) - the attribute of the executable is entered in its attributes from block 2 to block 6. Here again, as accounting information, we can limit ourselves to writing only the attribute of the executable into the file attributes. In subsequent calls to the marked-up file in accordance with the rule recorded in block 3, block 1 will prevent the possibility of modifying executable files (including deletion and renaming).

By implementing the combination of protection methods discussed in examples 3 and 4, it is possible to prevent both modification of executable files (static files of the OS and applications created before the system was launched), and the possibility of running unauthorized (including malware) programs on a protected computer in system operation process. In this case, two features should be used when marking up the files - created (at its creation), executed (at its execution). Executable can be a file that is not marked as being created (that is, it was not created during the operation of the system) or marked as executable - these files cannot be deleted or modified. The file created during the operation of the system (marked as created) or unmarked as executable (could not be launched by the system and applications during the operation of the system) can be modified. Here is an effective solution to protect against malware and modify executable files of the OS and applications.

As in the examples discussed above, illustrating the functionality of the claimed technical solution in relation to the protection of the generated files, in the example illustrating the functionality of the claimed technical solution in relation to the protection of system files, only special cases (for solving individual protection problems) of applying the claimed technical solution are considered. For example, in order to protect system (static) files that will be automatically allocated by the system, it is possible to prevent applications (or interactive users) from modifying all files used by system processes by system users. There are a lot of similar urgent protection tasks using the claimed technical solution, here are just a few examples of using the system.

Now we will consider the operation of the access control system for static files (present in the system at the time the administrator set the access control policy) based on their manual markup (since the files are present at the time of system administration, they can be marked up). The delineation policy in this case also consists in setting the access rights of the subjects to files created by other entities, but not created during the system’s operation, but before its administration (these files were not marked up initially).

This problem is being solved in order to include in the delimiting access policy based on the markup of files, static files.

Marking of static files is carried out by block 4. Just like block 2, block 4 can write or read file attributes to / from block 6. Block 5 controls writing / reading of attributes - multiplexes the operation of block 5 with block 2 or with block 4 in depending on which of these blocks a request was received to access the file attributes. The request to manually create / modify / mark up a file attribute (with the full path name of the file or folder, if you need to set the same markup for all files in the folder, including deleting markup in all files of the folder) to block 4 is issued by the administrator from the system 12. , if necessary (if you want to write the attributes of the file / files in the folder), from the input of system 11, the administrator sets the account information of the access subject (username, process name, at the same time username and process name - for the subject KTA "user process" safety mask etc., see. examples above), which will be recorded in the attributes of the file (s) when the manual layout. As a result of this, the selected files are manually marked up - the subject information set by the administrator is recorded in their attributes. At the same time, the accounting information is in no way connected with which user (administrator) and which process the file is accessed to - the marking of the file is the information that is set by the administrator from system input 11. Similarly, if necessary, the administrator can delete (change, modify) the markup of files created automatically by block 2.

The system for processing a request for access to a file when manually marking up a file works the same way as described above. In block 3, the administrator sets the rules for access to the marked-up files (it doesn’t matter which way - automatically or manually), similarly, block 2 does not share how the files were marked out when processing the request for access to the file.

Thus, in contrast to the well-known system (prototype), the administrator in block 6 sets not the access rules for the subjects to the file as attributes of the file, but the accounting information of the person who created this file (or the accounting information of some other access subject, at the administrator’s discretion) .

Here, as in the case of access control to created files, it is possible to solve various protection tasks, but already static files, based on their manual markup by the administrator. For example, you can manually mark all the files in the Windows and Program Files folders, indicating in the markup that they were created by the administrator. After that, in the delimiting access policy, only the administrator should be allowed to modify (delete) files created by the administrator, thereby preventing their unauthorized modification / deletion by other interactive users (protection against attacks on compromising system files). You can allow access to the system files used by a particular application only to this application (here you will need to use the name of the corresponding process as the access subject’s information used by the administrator when manually marking files), etc. Other examples of security tasks that can be solved using manual marking of static files are possible.

Thus, the examples considered are not a complete list of the technical solution’s capabilities, but at the same time they clearly illustrate the achievement of the goal - the solution to the problem of expanding the functionality of access control to files and simplifying the task of administering the access control system by excluding the entity “object” from the delimiting access policy to files, which is illustrated by practical examples of protection against the most relevant modern threats.

The invention is industrially applicable in terms of the possibility of technical implementation of the automatic file markup block included in the system, the file access rules storage block, the manual file markup block, the file markup control block.

The technical implementation of the file access rules storage unit is a fairly typical solution for storing and processing data (access tables (matrices)), the file markup control unit is also a typical solution for request and response multiplexing.

The technical implementation of the automatic and manual file markup blocks depends on which file system and how the claimed solution interacts. Consider an example of a technical implementation when the system works with the Microsoft Windows NTFS file system (other technical implementations are possible here).

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

In order for the claimed system not to conflict with the delimitation policy implemented by the OS, the system does not directly use the attributes used by the OS to store data for automatic file marking. To store the file attributes created by the system that are used by the system to implement access control (for automatically writing / reading file markup credentials), the so-called "alternative data streams" are used.

An alternative stream is a memory area that is “rigidly” attached to a specific file and into which you can write, respectively, from which information can be read. An alternative stream can be deleted and deleted when the file for which it is created is deleted.

NTFS implemented and documented (described the native OS feature) support for alternative data streams (Alternate Data Streams) - it was added to NTFS for compatibility with the Macintosh HFS file system, which used a resource stream to store icons and other file information. Using alternative streams allows you to store data about the file discreetly from the user and inaccessible by conventional means. Explorer and other applications work with a standard stream (file) and cannot read data from alternative streams.

Creating alternative threads is a documented opportunity. You can create them, for example, as follows from the command line. First you need to create a base file to which the stream will be attached. Create a file: C: \> echo Just a plan text file> sample.txt

Next, using the colon as the operator, create an alternative stream:

C: \> echo You can't see me> sample.txt: secret.txt

You can use the following commands to view the contents:

C: \ more <sample.txt: secret.txt

or

C: \ notepad sample.txt: secret.txt

If everything is done correctly, then we will see the text: You can't see me, when you open it from the explorer, this text will not be visible.

An alternative stream allows you to write an unlimited amount of information into it, while it is "rigidly" connected to the base file (to which the stream is attached) - it can be deleted and will be deleted only when the file is deleted.

Comment. Alternative data streams can be attached not only to a file, but also to a folder.

Thus, an alternative stream is a memory area that is “rigidly” connected with a specific file and can be written to, from which information can be read (by known, described methods), while data recorded in an alternative stream is stored secretly from the user and is not available by conventional means.

As a result, this documented feature - the described ability to create an alternative stream (protected from users) for a file with the ability to store service information in it (for the inventive system - for storing file markup data) is described, technically feasible and can be used to implement the claimed technical solution , which was tested by the applicant when creating a prototype of a means of information protection.

All used blocks are technically feasible and their implementation is achieved by standard means, which was tested by the applicant during the construction of a prototype information security tool.

Thus, in the present invention, the tasks of expanding the functionality of file access control and simplifying the task of administering the access control system by eliminating the entity “object” from the delimiting file access policy are solved. Given the current level of development of computer technology, it is technically feasible.

Claims (1)

A system for controlling access to files based on their manual and automatic marking, containing a decision block, a file attribute storage unit, the first input of the decision block being connected to the first input of the system, the second output to the output of the system, characterized in that it additionally includes: automatic file markup, a block for storing file access rules, a manual file markup unit, a file markup control unit, the first input of the deciding unit being connected to the first input of the automatic file marking unit, the second input to of which is connected to the third input of the system, the first output is with the first input of the file marking control unit, the second input of which is with the first output of the manual file marking unit, the second output of the automatic file marking unit is connected to the third input of the file marking control unit, the fourth input of which the second output of the manual file marking unit, the fifth input - with the output of the file attribute storage unit, the first input of which is with the third output and the second input - with the fourth output of the automatic file marking unit, the first output the file marking control unit is connected to the third input of the automatic file marking unit, the second output is to the third input of the manual file marking unit, the first input of which is the fourth and the second to the fifth input of the system, the third output of the automatic file marking unit is connected to the first input of the block storing file access rules, the second input of which is with the second input of the system, the third input is with the second output of the decisive block, the second input of which is with the output of the file access rules storage block.

Images