RU2777302C1 - System and method for controlling the delivery of messages transmitted between processes from different operating systems - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to computer technology. A method for controlling the delivery of interprocess communication messages transmitted between processes from different operating systems is described, in which a proxy process is created in the first OS using the process creation tool, designed to exchange messages between at least the first process from the first OS and the second process in the second OS and having a program interface corresponding to the program interface of the second process, at the same time, the first OS and the second OS are operating systems installed in different computing environments; with the help of the policy assignment tool, at least one security policy is assigned to the created proxy process to control the delivery of messages associated with the proxy process, where messages are transmitted through a specified program interface; with the help of the generated security monitor, the delivery of messages is controlled between at least the first and second processes by controlling the delivery of messages associated with the proxy-process, based on security policies.

EFFECT: increase in the security of operating systems when exchanging interprocess communication messages transmitted between the first and second processes from different operating systems.

22 cl, 11 dwg

Description

Technical field

The invention relates to the field of information security.

State of the art

Modern operating systems (hereinafter referred to as OS) are complex information systems with a lot of installed software (hereinafter referred to as software) to perform a wide variety of functions. At the same time, software developers are constantly working on fixing bugs and expanding the functionality of the software. However, such a quantity and variety of software entails significant information security risks due to the presence of vulnerabilities in the software, as well as the possibility of unauthorized installation of malware. The first level of protection against the mentioned threats are the features of the OS architecture, as well as the protection tools built into the OS, because it is the OS that provides the mechanisms for processing and controlling inter-process communication (IPC), which can be implemented, in particular, by exchanging messages between processes.

Many popular operating systems (for example, Windows 9x, Linux, Android, etc.) use a monolithic kernel, which has a number of advantages, such as performance, as well as ease of interaction between drivers. But due to the large number of kernel software modules and, as a result, the high probability of errors in the code, it is difficult to ensure the reliability and security of an OS with a monolithic kernel. Thus, if there is a vulnerability in the OS, the delivery of some unwanted or malicious messages between processes can be allowed by means of processing and controlling interprocess communications. An example of such a malicious message between processes is a message containing a request to access a protected area of memory. Another type of OS kernel is a microkernel (for example, the kernel of KasperskyOS, Symbian, etc.), which provides a minimal set of elementary process control functions and abstractions for working with hardware. The microkernel (English microkernel) architecture of the OS is characterized by a small size of the microkernel and a trusted computing base. This contributes to a higher level of reliability and security of the microkernel architecture of the OS, since a small amount of microkernel code is easier to check for correctness. But at the same time, such an OS architecture has, as a rule, lower performance. There are also operating systems with hybrid kernels (English hybrid kernel, for example, MacOS X, Windows NT, etc.), which allow the operating system to take advantage of the well-structured microkernel architecture of the OS, while maintaining the performance of a monolithic kernel.

For operating systems, the task of ensuring the reliability and security of interprocess communications implemented by exchanging messages between processes is relevant. An even more difficult task is to ensure the security of inter-process communications between the first and second processes, where the second process is executing in an environment that is hardware or software isolated from the first execution environment in which the first process is executing. For example, the second process may run on a second computer connected to the first computer over a network, in a virtual machine, or in other execution environments. In this case, a technical problem arises, which consists in the difficulty of monitoring the delivery of interprocess communication messages between processes from different operating systems for compliance with the security policy.

From the prior art patent US8336050B2 is known, which describes a method for interprocess communication between virtual machines using virtual synchronization and shared memory.

However, known technologies do not allow solving the claimed technical problem, since they do not allow controlling the delivery of interprocess communication messages between processes from different OS for compliance with the security policy. Therefore, there is a need for a technology capable of solving the stated technical problem.

Disclosure of the essence of the invention

The present invention is intended to control the delivery of messages passed between the first and second processes running on different operating systems.

The first technical result consists in increasing the security of the OS when exchanging interprocess communication messages transmitted between the first and second processes from different OS by creating a proxy process for sending and receiving messages from the second process, which has a programming interface for the proxy process, as well as adding a policy security to control the delivery of messages associated with said proxy process.

The second technical result consists in increasing the control of delivery of interprocess communication messages transmitted between the first and second processes.

In an embodiment, a method is used to control the delivery of interprocess communication messages (hereinafter referred to as messages) transmitted between processes from different operating systems (OS), in which: using the process creation tool, a proxy process is created in the first OS, designed to exchange messages between at least as the first process from the first OS and the second process in the second OS and having a programming interface corresponding to the programming interface of the second process, while the first OS and the second OS are operating systems installed in different computing environments; using the policy assigner, assigning at least one security policy to the created proxy process to control the delivery of messages associated with the proxy process, where the messages are transmitted through a given programming interface; using the generated security monitor, control the delivery of messages between at least the first and second processes by controlling the delivery of messages associated with the proxy process based on security policies.

In one particular implementation, message delivery control includes at least allowing or denying delivery of the message.

In another particular implementation, the messages include at least one of: a request to start a process, a request and response to interprocess communication, a process request to a security monitor.

In another particular implementation, the second OS is one of at least the following: a guest OS running on a virtual machine running the first OS on the computer; a guest OS running on a virtual machine, wherein the first OS is a second guest OS running on a second virtual machine and associated with the first virtual machine via a hypervisor; a second OS on a second computer that is connected to the computer running the first OS via a network.

In one particular implementation, the security monitor is generated for the first OS using a generation tool.

In one of the private implementation options, a security monitor is formed taking into account the architecture features of the first OS, in particular, taking into account the created proxy process, as well as taking into account the security policies assigned to the proxy process from the policy base.

In another particular implementation, a security monitor is formed by creating a security monitor code that includes one of: source code, intermediate code, executable code.

In one of the private implementation options when controlling message delivery, the security monitor uses the proxy process API to determine the allowed messages for the proxy process, while using the policy assigner, the list of allowed messages is additionally set in accordance with the API and the security policy is assigned, which prohibits the delivery of messages from the proxy process if the security monitor has detected an attempt to deliver messages that are not in the list of allowed messages.

In another particular implementation, when controlling message delivery, the security monitor uses the proxy process API to determine the list of processes with which the proxy process is allowed to exchange messages, while using the policy assigner, an additional security policy is assigned that prohibits the exchange of messages between the proxy process. process and processes not in the process list, wherein the process list includes at least the first process.

In yet another particular implementation, a proxy process is created for at least two second OS processes if there is a messaging API between said second OS processes.

In one of the private options for implementing security policies use at least one of the following models: basic operations; finite state machine; temporary machine; role-based access control; mandatory integrity control; regular expressions; discrete events; mandate links; temporal logic.

In an embodiment, a system is used to control the delivery of messages transmitted between processes from different OS, implemented by a computer that includes memory and is functionally associated with memory at least one processor, configured to implement the following means: a process creation tool designed to create a proxy process in the first OS, designed for messaging between at least the first process in the first OS and the second process in the second OS and having a programming interface corresponding to the programming interface of the second process, while the first OS and the second OS are operating systems installed in different computing environments ; a policy assigner for assigning at least one security policy to the created proxy process to control the delivery of messages associated with said proxy process, where the given API is used to transmit said messages, said policies being stored in a security policy database, which stored in memory; a generated security monitor for monitoring the delivery of messages between at least the first and second processes by monitoring the delivery of messages associated with said proxy process based on security policies from the security policy database.

In one particular implementation, message delivery control includes at least allowing or denying delivery of the message.

In another particular implementation, the messages include at least one of: a request to start a process, a request and response to interprocess communication, a process request to a security monitor.

In another particular implementation, the second OS is one of at least the following: a guest OS running on a virtual machine running the first OS on the computer; a guest OS running on a virtual machine, wherein the first OS is a second guest OS running on a second virtual machine and associated with the first virtual machine via a hypervisor; a second OS on a second computer that is connected to the computer running the first OS via a network.

In one of the private implementation options, the system further comprises a generating tool for generating a security monitor in the first OS.

In one of the private implementation options, the generation tool is designed to generate a security monitor taking into account the architecture features of the first OS, in particular, taking into account the created proxy process, as well as taking into account the security policies assigned to the proxy process from the policy base.

In another particular implementation, the generation tool is designed to generate a security monitor by creating a security monitor code, including one of: source code, intermediate code, executable code.

In one particular implementation in message delivery control, the security monitor is designed to use the proxy process API to determine the allowed messages for the proxy process, while the policy assigner is additionally designed to set the list of allowed messages according to the API and assign the policy security that prohibits the delivery of messages from a proxy process if the security monitor has detected an attempt to deliver messages that are not on the allowed list.

In another particular implementation, when controlling message delivery, the security monitor is designed to use the proxy process API to determine the list of processes with which the proxy process is allowed to exchange messages, while using the policy assigner, an additional security policy is assigned that prohibits the exchange of messages between a proxy process and processes not in the process list, wherein the process list includes at least the first process.

In yet another particular implementation, the process creator is designed to create a proxy process for at least two second OS processes if there is a messaging API between said second OS processes.

In one of the private options for implementing security policies use at least one of the following models: basic operations; finite state machine; temporary machine; role-based access control; mandatory integrity control; regular expressions; discrete events; mandate links; temporal logic.

Brief description of the drawings

Additional objects, features and advantages of the present invention will become apparent from reading the following description of an embodiment of the invention with reference to the accompanying drawings, in which:

On FIG. Figures 1a-1e show diagrams of interprocess communication using a security monitor using an operating system with a microkernel architecture as an example.

On FIG. 2a shows the security monitor generation system.

On FIG. 2b shows a delivery control system for interprocess communication messages passed between the first and second processes.

On FIG. 3a shows an embodiment of the present invention using a second OS as a guest OS running on a virtual machine running the first OS on the computer.

On FIG. Figure 3b shows an example of creating proxy processes for a virtual machine and guest OS security domains.

On FIG. 4 shows a method for controlling the delivery of messages passed between the first and second processes.

Fig. 5 represents an example of a general purpose computer system.

Implementation of the invention

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, but may be embodied in various forms. The gist of the description is nothing but specific details provided to assist the person skilled in the art in a thorough understanding of the invention, and the present invention is defined within the scope of the appended claims.

Glossary

Process (English process) - a sequence of operations when executing a program or part of it, along with the data used, includes one or more threads (English thread) and system resources associated with them.

Inter-process communication (IPC) is a set of methods for exchanging data between multiple threads in one or more processes. Processes can run on one or more computers connected by a network. IPC methods are divided into messaging, synchronization, shared memory, and remote call methods.

An operation is an elementary action performed within the framework of the process under consideration (for example, an API function can act as an operation).

Modern operating systems use both synchronous and asynchronous operations when exchanging data between two processes using interprocess communication methods.

A security domain is a part of an automated system that implements the same security policies.

Finite State Machine (FSM) is a discrete device model characterized by states and transitions from one state to another. Each state of the finite automaton characterizes one of the possible situations in which the finite automaton can be.

On FIG. 1a-1c are diagrams of inter-process communication using security monitor 120 using an OS 100 with a microkernel architecture as an example. Shown in FIG. 1a , OS 100 includes isolated processes 131 - 132 of OS 100 applications that interact with each other through interprocess communication, as well as with the OS kernel 110 through program interfaces by exchanging messages 140 (also interprocess communication messages, IPC messages, are indicated by an arrow in the figure, starting with a dot). Messages 140 include the following: a request to start 141 a process 131 , a request 142 from a process 131 or a response 143 from another process 132 (for example, process 131 calling a method of process 132 ), a process 132 request to a security monitor 120 (security request 144 ). It is worth noting that messages 140 in the present invention refers to inter-process communication messages in the general case, allowing communication between various OS processes 100 , including processes 131 - 132 . Security monitor 120 is an OS component 100 designed to monitor the delivery of said messages 140 . Details of the implementation of the security monitor 120 will be disclosed later in the text. Also, messages 140 may include an error notification from the OS kernel 110 in response to messages 140 from processes 131-132 . At the same time, the mentioned interfaces implemented by processes are data structures with methods declared in them that implement the functionality of the corresponding process.

The interfaces mentioned are statically defined, and the allowed interactions between processes are predetermined.

The sending and receiving of messages 140 by processes 131 - 132 occur through OS kernel system calls 110 .

System calls may include the following:

• call() is used by process 131 to send a request 142 to process 132 and receive a response 143 for interprocess communication;

• recv() - used by process 132 to receive request 142 ;

• reply() is used by process 132 to send a reply 143 to process 131 .

In a particular implementation, the reply() system call is made on the same process thread as the recv() call.

The security monitor 120 is implemented to run on the processor of the computer running the OS 100 (an example of a general purpose computer 20 is shown in FIG. 5 ). The security monitor 120 monitors the delivery of messages 140 based on decisions 150 based on the security policies in the policy base 121 . The policy base 121 is stored on the machine-readable medium of the computer (memory) on which the OS 100 is installed, such as on disk 27 of the computer 20 (see FIG. 5 ). The delivery control of the message 140 includes allowing or denying the delivery of the message 140 and, accordingly, allowing or denying the execution of an interaction carried out using the specified message 140 . The decision 150 on how to control the delivery of the message 140 indicates the permission or prohibition of the transmission of the message 140 when the security policy is enforced. Solution 150 is used by security monitor 120 or its components to perform said delivery control of messages 140 (see FIG. 2a ). Based on the security policies from the policy base 121 , a decision 150 can be made using the data of the message 140 (eg, the name of the process being started or the actual arguments of the process method being called).

Also, the decision 150 on how to control the delivery of the message 140 may depend on the correctness of the structure of said message 140 . Thus, if message 140 has an invalid structure, transmission of said message 140 may be prohibited. In this case, valid message structures 140 can be defined using the declarative description of the interface of the receiving process of message 140 . The referenced structure may contain a message size 140 , valid arguments and other valid message options 140 .

In one particular implementation, the security monitor 120 may be part of the OS kernel 110 or a separate application running on the computer's processor. In another particular implementation, the security monitor 120 runs on the computer's processor in privileged mode of the OS kernel 110 .

In a particular implementation, the OS 100 further includes an audit service 133 for logging the results of message delivery control 140 . At the same time, the control of message delivery 140 additionally includes performing an audit using the audit service 133 . In yet another particular implementation, the security monitor 120 monitors the delivery of messages 140 in addition to the current status of the audit service 133 . This status indicates the readiness of the audit service 133 to receive and store messages 140 . For example, if process 131 makes a request 142 to a protected resource (through process 132 ), where information about access to a protected resource should always be logged, but the status of the audit service 133 indicates that the audit service 133 is not currently saves messages 140 , then such a request 142 will be denied by the security monitor 120 according to the security policy.

In yet another particular implementation, OS 100 includes a security monitor context 122 , wherein security monitor 120 monitors the delivery of message 140 further based on said context 122 , where context 122 contains security policy parameter values. In another particular implementation, the security monitor 120 is further configured to change the context 122 based on the decisions 150 based on the security policies from the policy base 121 . In a particular implementation of security policies, a state machine model, a mandatory integrity control model, or other models are used to implement security policies. More details about these models will be discussed later in the description of FIG. 2a . Depending on the security policies used by these models, context 122 may contain various security policy settings. For example, for security policies based on the mandatory integrity control model, context 122 will contain the values of integrity levels and access levels to securable objects. For state machine-based security policies, context 122 will contain the current state machine state value and the state machine transition table. On FIG. 1b shows an example of monitoring the delivery of a permitted request 142 from process 131 to process 132 using security monitor 120 . Process 131 can call a process interface method 132 , for this process 131 sends a request 142 containing the input arguments of the called method. The process 131 sends a request 142 through the OS kernel 110 , which in turn passes the request 142 to the security monitor 120 for verification. The security monitor 120 makes a "allowed" decision 150 based on the security policies and passes that decision 150 to the OS kernel 110 . Thereafter, the kernel 110 passes the request 142 onward to the process 132 based on the decision 150 .

In this example, process 132 then sends a response 143 (reverse order of messages 140 not specified) to process 131 , where response 143 contains the output arguments of the method being invoked. The method for sending response 143 is similar to the method for sending request 142 , but in reverse order, from process 132 to process 131 . That is, the process 132 sends a response 143 via the OS kernel 110 , which in turn passes the response 143 to the security monitor 120 for verification. The security monitor 120 makes a new "allowed" decision 150 based on the security policies and passes said new decision 150 back to the OS kernel 110 . Thereafter, the core 110 , based on the new decision 150 , forwards the response 143 to the process 131 .

On FIG. 1c shows an example of monitoring a denied request 142 from process 131 to process 132 in which security monitor 120 controls the delivery of request 142 by denying delivery of request 142 . The process 131 sends a request 142 through the OS kernel 110 , which in turn passes the request 142 to the security monitor 120 for verification. The security monitor 120 makes a "forbidden" decision 150 based on the security policies and passes the said decision 150 to the OS kernel 110 . The kernel 110 then sends an error notification to the process 131 based on the decision 150. In this case, the request 142 will not be passed to the process 132 .

On theFig. 1g an example of the interaction of the first process is presented134running in the first OS100, with the second process161performed in the second OS160, through a communication channel170, which is not controlled by the security monitor120. For simplicity of presentation, hereinafter, the first OS is the OS100(cm.Fig. 1a). It should be noted that the second OS160 can be any OS whose architecture is known from the prior art, including the operating system100, the architecture of which is shown inFig. 1a. So the first OS100 and second OS160 can be both different OS (that is, not having the same OS architecture) or the same OS, and the key difference is that the first OS100 and second OS160 installed in different computing environments. So in exemplary implementations, the first OS100 and second OS160can be installed on different computers, virtual machines or in software or hardware isolated from each other computing environments, which in turn are implemented with the ability to execute on a computertwenty(cm.Fig. 5). One example of a technology for isolating computing environments is the TrustZone technology.

Thus, the interaction of the first process 134 with the second process 161 is carried out using a communication channel 170 , such as a computer network, a virtual machine transport mechanism (for example, VirtIO paravirtualization extensions) and another communication channel depending on the computing environments on which the first OS 100 is installed and second OS 160 . However, this way of interaction of the first process 134 with the second process 161 has a number of disadvantages, since the delivery of messages 140 transmitted between the mentioned processes over the communication channel 170 cannot be monitored by the security monitor 120 for compliance with the security policy from the policy base 121 . This entails reducing the security of the first OS 100 in the exchange of messages 140 passed between the first 134 and the second 161 processes. Thus, the example of interaction between the first 134 and the second 161 processes shown in FIG. 1d does not solve the stated technical problem. In this regard, the claimed invention can be used to solve this technical problem.

On FIG. 1e shows an example of a secure interaction of the first process 134 in the first OS 100 with the second process 161 in the second OS 160 according to the claimed invention. It is worth noting that, in general, the second process 161 may interact with multiple processes in the first OS 100 , one of which is represented in the figure as the first process 134 . However, for simplicity, only the first process 134 interacting with the second process 161 will be discussed below. As in the previous example shown in Fig. 1d , the first OS 100 is connected to the second OS 160 via a link 170 that is not controlled by the security monitor 120 . The second OS 160 may be any OS whose architecture is known in the art, including operating system 100 as shown in FIG. 1a . The first OS 100 and the second OS 160 may be installed on different computers, virtual machines, or in software or hardware isolated computing environments from each other, which in turn are implemented to run on the computer 20 (see FIG. 5 ). However, the second process 161 interacts with the first process 134 not directly, but through a pre-created proxy process 135 . At the same time, the proxy process 135 is present in the first OS 100 (but is not present in the second OS 160 ), is designed to exchange messages 140 with the second process 161 over the communication channel 170 and has a program interface corresponding to the program interface of the second process 161 . In a particular implementation, when monitoring the delivery of messages 140 , the security monitor 120 uses the proxy process 135 API to determine allowed messages 140 for the proxy process 135 . At the same time, at least one security policy is predefined in the policy base 121 , which prohibits the delivery of messages 140 from the proxy process 135 if the security monitor 120 detected an attempt to deliver messages 140 that are not on the allowed list. At the same time, the list of allowed messages 140 and the corresponding security policies are predetermined by the policy assigner 290 when generating the security monitor 120 (see Fig. 2a-2b ). Thus, the first process 134 communicates with the proxy process 135 by sending inter-process communication messages 140 and under the control of the security monitor 120 , while the proxy process 135 communicates with the second process 161 over a communication channel 170 , while the security monitor 120 does not control communication channel 170 .

In the preferred embodiment, in the second OS 160 , each second process has its own separate proxy process. For example, the second process 161 corresponds to the proxy process 135 , and the third process 162 corresponds to a second proxy process (not shown in the figure) other than the proxy process 135 . In addition, in the preferred embodiment, processes 161 and 162 are unrelated.

However, in a private implementation in the second OS 160 , the second process 161 may be associated with the third process 162 via a messaging API 140 . In this example, one proxy process 135 can be used, which is the same for both mentioned processes 161 - 162 . Thus, the processes 161 - 162 form a single security domain, interaction with which occurs through a single proxy process 135 , which also allows you to control the interaction between the second 161 and third 162 processes of the second OS 160 . It is worth noting that said security domain including processes 161-162 may also include more second OS 160 processes not shown in the figure. Otherwise, when several different security domains can be allocated in the second OS 160 , each of which includes at least one second process, then a separate proxy process in the first OS 100 will be defined for each said security domain.

The use of the presented system of interaction between the first 134 and second 161 processes allows solving the specified technical problem and achieving the stated technical results, namely, increasing the security of the OS when exchanging interprocess communication messages 140 transmitted between the first 134 and second 161 processes from different OS by creating a proxy process 135 to send and receive messages 140 from a second process 161 having an API for the proxy process 135 , as well as adding a security policy to control the delivery of messages 140 associated with said proxy process 135 , as well as to increase control of the delivery of messages 140 of inter-process communication, transmitted between the first 134 and second 161 processes. More details about the embodiments of the present invention, in particular about creating a proxy process 135 and assigning security policies to the created proxy process 135 will be described below.

On FIG. 2a shows the security monitor generation system 200 . The security monitor generation system 200 is used to improve the security of the OS 100 when exchanging messages 140 , as well as to control the delivery of said messages 140 to recipients. Thus, the security monitor 120 can be used by software developers in various operating systems 100 , as well as in any other computer systems in which messages 140 are exchanged, in particular in databases and in application software. An example of such use has been shown previously in FIG. 1a-1c . For each OS 100 , a security monitor 120 is formed, taking into account the OS 240 architecture, as well as the security requirements for this OS 100 , which are expressed in security policies. It should be noted that for various software and hardware-software systems of the developer based on OS 100 (hereinafter referred to as the developer's system), the main objects of the OS 240 architecture can be common, for example, processes, services, applications, drivers responsible for the operation of the OS 110 kernel and other components OS 260 . At the same time, other objects of the OS architecture 240 responsible for the functionality of the developer's system will be different for each of these systems. Consequently, the security policies used to control the delivery of messages 140 will also differ. The developer's systems may include software, as well as software and hardware systems.

The system 200 includes a policy base 121 for storing the security policies needed to control the delivery of messages 140 . System 200 also includes at least one configuration tool 220 , which is configured to configure its corresponding checker 221 based on the security policies received from generator 210 . The verification module 221 is designed to make a decision 150 on how to control the delivery of the message 140 (hereinafter referred to as the decision) at the request of the security monitor 120 when executing the security policy. System 200 also contains an architecture description of OS 240 , which in turn includes OS architecture objects such as OS 100 processes and applications. In a particular implementation, said OS architecture objects further include OS 100 developer system objects. In yet another particular implementation, OS architecture objects further include:

• a service-providing process that includes at least one software component designed to implement the programming interface of said process, while interaction with said process occurs through said interface (for example, such a service can be an application that broadcasts a stream of external events and requests for the processing process events);

• a list of programming interfaces for each process, while the corresponding methods of the interfaces that implement the functionality of the corresponding process can be specified.

In another particular implementation, the object of the OS architecture is additionally a resource driver - a process that manages resources and access to them. A resource is, in particular, a file, a port, or a process. For example, the file system is a resource driver, and the files themselves are resources that the file system can provide access to other processes.

In addition, the system 200 includes a generator 210 intended for the analysis of security policies, where the analysis consists, in particular, in determining the processes for which said security policy is used. In a particular implementation, this analysis takes into account OS architecture objects 240 that include the processes and applications mentioned. Creator 210 is also operative to select security policies from policy base 121 for respective customizers 220 and to pass at least one selected security policy to the respective customizer 220 . The builder 210 is also configured to build the security monitor 120 using the customized checkers 221 received from each builder 220 based on the results of the analysis. In a particular implementation, generator 210 generates security monitor 120 by generating code for security monitor 120 . Here, said code may be source code, intermediate code, or executable code. In addition, code generation of the security monitor 120 may also include code optimization and code analysis for errors. Thus, generator 210 may be a compiler that generates said code.

The OS architecture 240 , the policy base 121 , as well as the configuration tools 220 may be configured in advance using the development tool 250 . To do this, the development tool 250 may provide a set of APIs (application programming interface) or ready-made modules for software development. In this case, the interface is further understood as the interface of the processes described earlier, and the abbreviation API will be used for the application programming interface. In a private implementation, at least part of the architecture of the OS 240 , part of the security policies from the policy base 121 , and part of the configuration tools 220 can be common (template) for different OS 100 . In this case, the developer using the development tools 250 can configure the configuration tools 220 , the OS architecture 240 and the security policies from the policy base 121 by adding to the said template the security policies missing in the template, in the OS architecture 240 , as well as the customization tools 220 necessary to reflect features of OS 100 , or OS 100 - based developer 's system , and security requirements for OS 100 , or OS 100 - based developer 's system , for which said developer generates security monitor 120 . In addition, part of the data from the above template can be removed if it is not needed in the OS 100 or, respectively, in the developer's system based on OS 100 . For example, some security policies and applications may be removed.

The generated security monitor 120 , along with other components of the OS 260 , is further included in the operating system 100 . This inclusion of the security monitor 120 and components of the OS 260 can be carried out by methods known from the prior art, for example, at the stage of compiling the OS 100 using the OS 100 compiler or by installing the security monitor 120 in the OS 100 . As previously mentioned, security monitor 120 may be part of the OS kernel 110 or a separate OS 100 application. The security monitor 120 runs in privileged OS kernel mode 110 . An OS 270 installation image may also be created for OS 100 to install OS 100 on end user computing devices. The OS installation image 270 may be, for example, an archive, an executable file, or an installation package. The installation package is an archive file that includes OS 100 files, control files, and optional files for customizing the OS 110 installation process. In addition, the installation package may include developer system files based on OS 100 . The mentioned files may be present in source code, in intermediate code, or in executable code.

Description of security policies

In a particular implementation of the security policy, at least one of the following models is used:

basic operations;

finite state machine;

temporary machine;

role-based access control;

mandatory integrity control;

regular expressions;

discrete events (English Discrete Event Systems, DES);

mandate links;

temporal logic (temporal logic; English temporal logic).

Security policies from the policy base 121 can be defined using a specification language such as PSL (policy specification language). In the PSL example, the mandatory integrity control is defined by the policy class Mandatory_integrity_control. A class (family) of security policies defines a set of rules that correspond to the rules of the model used in the security policy. The specification of the security policy defines the correspondence of these rules and interactions in the system, which can be implemented by the exchange of messages 140 between processes. On each interaction attempt, that is, when the security monitor 120 checks the messages 140 , the security monitor 120 executes the rules to determine whether the specified interaction is acceptable (delivery of the message 140 ). To use a policy class, a policy object is created based on it, for which the configuration is specified.

In a particular implementation, the analysis of security policies and architecture objects of OS 240 includes at least one of the following types of analysis: lexical analysis, parsing, semantic analysis. As a result of this analysis of security policies, objects of the OS architecture 240 are determined, in particular, the processes involved in the exchange of messages 140 for which the said security policy is applied. That is, a correspondence will be determined between certain objects of the OS 240 architecture and the security policy applied to said objects. For example, if a security policy allows a request 142 from process 131 to process 132 , then the analysis of this security policy will determine the specified processes 131 - 132 and information about the allowed request 142 . It is worth noting that as a result of this analysis of security policies, other objects of the OS architecture 240 can additionally be determined, which check in the specified security policy, for example, methods of the process interfaces, when the message 140 is addressed to the specified method and will be transmitted over the specified process interface. In this case, the security policies will check the condition that the exchange of messages 140 between certain processes uses the specified process interfaces and specified methods of the interfaces.

Using the example of PSL, which can be used to set security policies in the policy base 121 , the process 131 that is the source of the request 142 can be referenced in the scr variable. An indication of the process 132 that is the recipient of the request 142 may be contained in the variable dst. Accordingly, it is the mentioned analysis of the security policy written in the PSL language that will make it possible to determine the specified objects of the OS architecture for which the specified security policy will be applied.

In another particular implementation, the analysis of security policies also includes checking the types of OS architecture objects 240 , as well as analyzing for errors in security policies.

The results of said analysis are taken into account in the formation of the security monitor 120 . For example, in the security monitor 120 , the conditions for applying security policies can be recorded - a list of OS architecture objects 240 , in particular, processes, and corresponding to the specified list of security policies, as well as check modules 221 . Therefore, when message 140 is received from the OS kernel 110 , the generated security monitor 120 determines the OS architecture objects 240 participating in the message exchange 140 and then determines the security policies applicable to said OS architecture objects 240 . The security monitor 120 then passes the messages 140 to the validators 221 corresponding to the specified security policies to decide how to control the delivery of the message 140 .

In yet another particular implementation, parsing is performed by constructing a parse tree for the code of the security monitor 120 , wherein the code of the checkers 221 generated by at least one customizer 220 is included in the parse tree.

Security policies can use basic operations that allow or deny transmission of message 140 , provided that the parameters of message 140 (for example, the name of the process to be started or the actual arguments of the method being called) match the data specified in the security policy. For example, a security policy may specify that process 131 may receive any messages 140 , but that process 131 is prohibited from sending messages 140 .

Security policies may also use a state machine, where the security policy determines whether message 140 is allowed or denied delivery depending on the state of the state machine and according to the state machine's state transition table.

The Timed automata model, and in particular the ERA (Event-recording automata) type time machine, is a special case of finite automata. In this model, in addition, for each message 140 , a time parameter (timer) is set equal to the time since the last receipt of this message 140 . For example, a transition from one state of the state machine to another state can be performed if the message 140 was received after the time specified by the timer.

The Mandatory integrity control model is used to allow or deny message delivery 140 . According to the model of mandatory integrity control using a security monitor, 120 OS architecture objects 240 participating in message transmission 140 , for example, processes 131 - 132 , are assigned two numbers, called the Integrity level and the access level. At the same time, to allow the delivery of message 140 from one object to another, security policies are used based on mandatory integrity control, that is, using the values of integrity levels and access levels of objects. For example, a security policy may be used, according to which one object is allowed to access another object if the value of the access level of the first object is not lower than the value of the integrity level of the other. In the PSL specification language, integrity levels and access levels are specified for the mandatory integrity control model. Thus, to set integrity levels, an integrity policy object is defined, which is an instance of the Mandatory_integrity_control class:

In the integrity policy object configuration, three levels of integrity will be set: LOW (low), MEDIUM (medium) and HIGH (high) - in ascending order. That is, LOW < MEDIUM < HIGH.

The object capability model is based on the principle of least privilege. This principle of organizing access to resources implies granting to the subject (process or user) only those privileges that are absolutely necessary for the successful completion of the task. For example, a user who wants to view the contents of a file should only be granted read access to the file, and only for the duration of the file's use.

To set security policies based on temporal logic, security properties (requirements) are formulated using a temporal logic formula and using temporal operators. Using the security monitor 120 , the objects of the OS architecture 240 participating in the transmission of the message 140 , such as the processes 131-132 , are assigned their state events from a predetermined set of events.

As an example, the application of security policies based on temporal logic for the process of installing software from a software image is considered. Several components (which are processes 131 - 132 ) may be involved in the installation process, such as a checker and an installer. The software installation process may include verifying the integrity of the software image with a checker and then installing the software from the software image with the installer if the integrity of the software image is not compromised. The integrity of the software image determines the consistency, completeness, and integrity of the data in the software image. Checking the integrity of the software image can be carried out by checking the digital signature. For the mentioned software image, the set of events can include the following: {seal, verify, apply}, where seal is the event of "sealing" the software image, verify is the event of checking the integrity of the software image, apply is the event of installing software from the software image. The security properties are formulated, for example, as follows:

Feature 1 : Whenever a software image integrity check is performed, it must be guaranteed that after the software image integrity check process, said software image will not be modified. This property can be written as a formula:

G (verify => P seal),

where G is the "always in the future" temporal operator, P is the "at least once in the past" temporal operator. Property 1 means that whenever a past integrity check is performed on a software image, it must be guaranteed that no further data can be written to the software image.

Property 2: Installing software from a software image is possible only if the integrity of the software image is confirmed. This property can be written as a formula:

G (apply => P verify).

Creating a policy class object that implements access control based on temporal logic can be implemented in PSL as the following construct:

It should be noted that other formulations of properties are also possible. For example, property 2 could be set as follows: the software image is not applied until the integrity of the software image is verified:

!apply U verify,

where U is the temporal operator "until the given event occurs".

A policy based on the temporal logic model, when installing software, associates an apply event with this interprocess communication and checks the validity of the formula specified in the policy object configuration. If the formula is true, the policy allows the interaction; if it is false, it denies it.

The discrete event model-based policies are set using the policy-corresponding checker 221 . The mentioned security policies can also be described in the PSL specification language. The mentioned security policies can be applied to developer systems that consist of a large number of components. For the said system, the discrete event model is the resulting finite state machine, which is specified by combining a set of finite state machines, each of which describes a separate component of the system. For each finite state machine, a set of their states and transitions between them when certain events occur. The state of the resulting finite state machine is determined by combining the states of the state machines of the system components. This combination is carried out, for example, by synchronous or asynchronous product of finite automata. For the resulting state machine, a list of allowed transitions, a list of allowed states, and a list of forbidden states of the resulting state machine are also specified. Accordingly, using security policies, they check the transition of the said finite automata of the system components and the resulting finite automaton to the initial state specified in the configuration of the corresponding finite automaton, the transition between states when a certain event occurs, the presence of the corresponding finite automaton in one of the specified states.

In yet another particular implementation, different settings 220 are selected for security policies using different models. For example, security policies can be grouped into policy classes. A security policy class is a set of semantically related policies that implement a particular security policy model. The first class of policies may consist of security policies using a state machine, and the second class of policies may consist of security policies using mandatory integrity control. In this example, for security policies from the first class, configuration tool 1 will be selected , while for security policies from the second class, configuration tool 2 will be selected. one class. In addition, adding a new security policy to the policy base 121 will use the existing configuration tool 220 without the need to modify it or add a new configuration tool 220 .

In another particular implementation, using the generator 210 , the context of the security monitor 122 is additionally included in the security monitor 120 , while the security monitor 120 controls the delivery of the message 140 additionally taking into account the mentioned context 122 , where the context of the security monitor 122 contains the values of security policy settings. In another particular implementation, the security monitor is further configured to change context 122 based on security policy decisions 150 . Depending on the security policies used by these models, context 122 may contain various security policy settings. For example, for security policies based on the mandatory integrity control model, context 122 will contain the values of integrity levels and access levels to securable objects. For state machine-based security policies, context 122 will contain the current state machine state value and the state machine transition table.

In a particular implementation, if at least two security policies correspond to the message 140 , the overall solution for the mentioned security policies is additionally calculated by conjuncting the solutions for each of the mentioned security policies, while the security monitor 120 monitors the delivery of the message 140 additionally taking into account the mentioned general solution. When process 131 or process 132 initiates an interaction by sending message 140 , security monitor 120 invokes all security policies from policy base 121 associated with that particular interaction. If all security policies have made a "allow" decision, then a general "allow" decision is made using the security monitor 120 . If at least one policy has issued a "forbidden" decision, a general "forbidden" decision is made using the security monitor 120 .

In yet another particular implementation, customizing the checker 221 includes generating code that makes a decision 150 upon request of the security monitor 120 for a security policy when said security policy is executed.

In a particular implementation, the security monitor 120 monitors the delivery of the message 140 in addition to decisions 150 based on the security policies associated with said messages 140 .

On FIG. 2b shows a delivery control system for interprocess communication messages passed between the first 134 and second 161 processes. To control the delivery of messages 140 passed between the first 134 and second 161 processes, the security monitor generation system 200 ( FIG. 2a ) can be used to generate the security monitor 120 for the first OS 100 . Thus, the message delivery control system 201 utilizes a security monitor generation system 200 , while further including a process builder 280 and a policy assigner 290 .

It is worth noting that the described tools and modules, in particular the configuration tools 220 , the generation tool 210 , the development tool 250 , the process creation tool 280 , the policy assigner 290 , are implemented with the ability to execute on the computer processor (see Fig. 5 ). In this case, the policy base 121 , the architecture of the first OS 241 , the verification modules 221 are contained in the computer's memory.

The process creator 280 is designed to create a proxy process 135 for the second process 161 , where the proxy process 135 is designed to exchange messages 140 with the second process 161 in the second OS 160 and has an API corresponding to the API of the second process 161 . In this case, information about the second process 161 , in particular about its programming interfaces, the process creation tool 280 receives from the development tool 250 .

Thus, information about the created first process 134 interacting with the second process 161 in the second OS 160 will be added to the architecture of the first OS 241 by the process creator 280 . The policy assigner 290 is designed to assign security policies to the created proxy process 135 to control the delivery of messages 140 associated with said proxy process 135 where said messages 140 are transmitted over a given API. In this case, the security policies assigned to the proxy process 135 will be stored in the policy base 121 . Once generated, the security monitor 120 will control the delivery of messages 140 between the first 134 and second 161 processes, the messages 140 being associated with said proxy process 135 , and said control taking into account the security policy assigned by the policy assigner 290 .

In a particular implementation, the security monitor 120 , when monitoring message delivery 140 , uses the proxy process 135 API to determine allowed messages 140 for the proxy process 135 . At the same time, using the policy assigner 290 , a security policy is determined that prohibits the delivery of messages 140 from the proxy process 135 if an attempt was made to deliver messages 140 that are not on the allowed list. The list of allowed messages 140 and the corresponding security policies are predefined by the policy assigner 290 when generating the security monitor 120 . In another particular implementation, when monitoring the delivery of messages 140 , the security monitor 120 uses the proxy process 135 API to determine the list of processes with which the proxy process 135 is allowed to exchange messages 140 . The list of processes includes at least the first process 134 . At the same time, using the policy assigner 290 , a security policy is additionally assigned that prohibits the exchange of messages 140 between the proxy process 135 and processes that are not in the mentioned list. Valid allowed message structures 140 can be defined using the declarative interface description of the second process 161 . Such structures may contain a message size 140 , valid arguments and other valid message options 140 .

Thus, using the present invention to implement inter-process communications of the second process 161 with the first process 134 , a proxy process 135 is created that implements all the programming interfaces of the second process 161 , and security policies are assigned to the created proxy process 135 to control the delivery of messages 140 between the second 161 and the first 134 processes on allowed interfaces. The present invention allows the security monitor 120 to control the delivery of messages 140 between the second 161 and the first 134 processes by monitoring the delivery of messages 140 associated with said proxy process 135 based on the security policy, even though there is an insecure communication channel 170 . Due to this, the claimed invention solves the specified technical problem and achieves the claimed technical results.

In another particular implementation, for processes 161 - 162 of the second OS 160 between which there is a programming interface for messaging 140 , using the process creation tool 280 , one proxy process 135 is created, which is the same for both mentioned processes 161 - 162 . It is worth noting that if processes 161 - 162 are not related to each other, that is, they are separate security domains, a separate proxy process will be created for each of them. For example, for the second process 161 a proxy process 135 will be created to interact with the first process 134 . And for the third process 162 , another proxy process (not shown in the figure) will be created to interact with another process (not shown in the figure) in the first OS 100 .

In a particular implementation, the second OS 160 is one of:

a guest OS running on a virtual machine running the first OS 100 on the computer;

a guest OS running on a virtual machine, wherein the first OS 100 is a second guest OS running on a second virtual machine and associated with the first virtual machine via a hypervisor;

the second OS 160 on a second computer that is connected to the computer running the first OS 100 via a network or other communication channels 170 .

In a particular implementation, when the second process 161 contains more than one thread of execution, for each thread of the second process 161 create a corresponding thread in the proxy process 135 . In this case, the thread of the second process 161 , which is exchanging interprocess communication messages, makes a call to the method of the communication channel driver 170 (by an I/O system call, for example, ioctl), which in turn notifies the proxy process 135 to create a thread in proxy process 135 to exchange IPC messages with the corresponding thread of the second process 161 . After the completion of the message exchange 140 between the threads of the second process 161 and the proxy process 135 , the second process 161 notifies the proxy process 135 of the completion of the message exchange 140 with it by calling the method of the communication channel driver 170 . After that, the proxy process 135 ends the execution of the corresponding thread in the proxy process 135 .

The communication channel driver 170 is designed to establish a communication channel 170 between the second process 161 and the proxy process 135 , flow control for the proxy process 135 , to implement the call(), recv(), reply() calls, and the proxy process API 135 corresponds to the interface of the second process 161 , as well as to deliver messages 140 from the second process 161 to the corresponding thread of the proxy process 135 .

It is also worth noting that when creating proxy processes, for example, proxy process 135 , a common proxy process template can be used for different processes of the second OS 160 , however, for different processes of the second OS 160 , a programming interface will be implemented in the corresponding proxy process, corresponding to the interface of the second process 161 . Thus, the use of a common proxy process template improves the security of the claimed invention due to the possibility of more detailed verification of the code of the specified template, as well as the use of common security policies. However, although some of the security policies for different processes of the second OS 160 will be the same, some of the security policies will be different.

On FIG. 3a illustrates an embodiment of the present invention with a second OS 160 as a guest OS running on a virtual machine running the first OS 100 on a computer (an example of a general purpose computer 20 is shown in FIG. 5 ). In the example under consideration, the hypervisor 303 is installed in the first OS 100 , which is a module (service) of the kernel of the OS 110 and manages virtual machines 301 - 302 . Said virtual machines 301 - 302 are applications of the first OS 100 running in user space on the computer's processor. The hypervisor 303 may use any virtualization system known in the art to provide virtual machines. An example of a hypervisor 303 is Kaspersky Secure Hypervisor (KSH), a secure virtualization system based on a type 2 hypervisor, where the first OS 100 (eg, KasperskyOS) acts as the host machine. In this case, the hypervisor 303 exports a component interface that is used by virtual machines 301 - 302 to manage sessions, virtual processors, memory, and low-level device forwarding. In addition to the virtual machines, other applications 331-332 may be running on the first OS 100 . In the preferred embodiment, said applications 331-332 and virtual machines 301-302 each contain a single process, but can also be implemented using multiple processes and run on a computer processor.

In the application context of the virtual machine 301 , a virtual machine is created with a guest OS 310 running guest functional components implemented using guest processes and applications. As an example, guest OS 310 creates applications 311-314 divided into two security domains 315-316 . In general, the functional components of the guest OS 310 may operate in different security domains, with the guest OS 310 isolating said security domains and the hypervisor 303 isolating the guest OS 310 from the virtual machines represented by applications 317-318 . Similarly, in the application context of virtual machine 302 , a virtual machine with guest OS 320 is created.

The delivery of IPC messages 140 from the various security domains 315-316 of the guest OS 310 as well as from the virtual machine application 301 that is a separate security domain are controlled by the security monitor 120 of the first OS 100 independently using generated proxy processes for each security domain. Similarly, the security monitor 120 monitors the delivery of messages 140 from the virtual machine application 302 and security domains 325-326 of the guest OS 320 . At the same time, the virtual machine 301 controls the interaction between security domains 315-316 within the guest OS 310 , controls its own security policies within the virtual machine 301 , controls access to guest OS 310 hardware , controls data flow for emulated devices, and other interactions within the guest OS 310 .

The interactions controlled by the security module 120 are indicated in FIG. 3a by a solid line with arrows. And interactions that are not controlled by the security monitor 120 are indicated by a dashed line - for example, interactions between the hypervisor 303 and virtual machines 301 - 302 that require privileged mode of the OS kernel 100 that cannot be implemented in user mode in virtual machine applications 301 - 302 . Meanwhile, the interactions between the various virtual machines 301 - 302 are also monitored by the security monitor 120 .

On FIG. 3b shows an example of creating proxy processes for virtual machine 301 and guest OS security domains 310 . Thus, a proxy process 341 for the security domain 315 and a proxy process 342 for the security domain 316 will be created. The created proxy processes 341 - 342 communicate with other processes of the first OS 100 via inter-process communication messages 140 , the delivery of which is controlled by the security monitor 120 . In this case, the virtual machine 301 , being a separate security domain and process of the first OS 100 , interacts with other processes of the first OS 100 through messages 140 , the delivery of which is also controlled by the security monitor 120 . That is, the virtual machine 301 does not require the creation of a separate proxy process. It is also worth noting that the generated proxy processes 341 - 342 will have APIs that correspond to those of the security domain 315 and security domain 316 , respectively.

As mentioned earlier, sending and receiving messages140 processes first OS100occur through system calls to the OS kernel110 and according to the given programming interfaces.

System calls may include the following:

• call() is used by process 131 to send a request 142 to process 132 and receive a response 143 for interprocess communication;

• recv() - used by process 132 to receive request 142 ;

• reply() is used by process 132 to send a reply 143 to process 131 .

In a particular implementation, the reply() system call is made on the same process thread as the recv() call.

To identify the recipient and sender of messages 140 in the guest OS 310 , unique identifiers can be used, the values of which are equal to the values of the process descriptors used by the proxy processes 341 - 342 to exchange messages 140 in the first OS 100 .

In the preferred embodiment, the messages 140 generated by the second, as well as other processes of the guest OS 310 (in this example, security domains 315 - 316 and the virtual machine application 301 ), are in the format of messages 140 transmitted in the first OS 100 . In this case, the corresponding proxy processes 341 - 342 , having received messages 140 from the processes of the guest OS 310 , which is the second OS 160 (security domains 315 - 316 ), will further send messages 140 to the corresponding processes 351 - 352 of the first OS 100 without change. In another embodiment, when the message format 140 from the processes of the second OS 160 is different from the message format 140 , the proxy process will convert the messages 140 from the processes of the second OS 160 to the message format 140 .

When a second process, such as security domain 315 in guest OS 310 , calls process 351 of first OS 100 , security domain 315 obtains a handle to process 351 and sends a message 140 to proxy process 341 over communication channel 170 (remote call()). In this case, the security domain 315 goes into a sleep state until the reply() message is received from the proxy process 341 . The proxy process 341 , upon receiving the specified message, transforms it into a message 140 and sends the message 140 to the process 351 using the OS kernel system call 100 . In this case, the delivery of the message 140 will be controlled by the security monitor 120 using the security policies assigned to the proxy process 341 and process 351 . Messages 140 from process 351 to security domain 315 are sent in a similar manner via proxy process 341 and under the control of security monitor 120 . Upon receipt of message 140 , the security domain 315 wakes up and completes the call() call.

It is worth noting that said interaction takes place via the security domain APIs 315 and the corresponding proxy process APIs 341 . The security domain API 315 receives a set of handles required for the exchange of messages 140 , whose values correspond to the handles of the proxy process 341 . The thread of execution of the security domain 315 makes a call to recv() on the specified interface to the proxy process 341 , after which the specified thread of execution enters sleep mode. The call to recv() of the thread of execution of the security domain 315 results in the system call recv() of the kernel of the first OS 110 , which initiates the proxy process 341 . After that, the proxy process 341 also goes to sleep. After the proxy process 341 receives a call() call from the security domain 315 (for example, from another thread of execution), the proxy process 341 wakes up, and sends the data received earlier when calling recv() to the security domain 315 on the appropriate software interface. The security domain 315 also wakes up and receives the data received in the recv() call from the proxy process 341 . The security domain 315 , on the same thread that made the recv() call, handles the call and sends the data using the reply() call. The proxy process 341 receives the specified data and sends it to the security domain 315 . For multi-threaded messaging 140 between the second process (security domain 315 ) and the proxy process 341 , an adviser thread of the proxy process is created for each thread of the second process.

In a particular implementation, the proxy process interface may include the following calls:

• method() is designed to get the thread ID, shared memory range descriptor and offset within this descriptor, processing of the specified method is performed by a separate thread of the proxy process;

• event() - designed to wait for events and return event handles, the processing of the specified method is carried out by a separate thread of the proxy process, while the mentioned events include responses to call() calls and receiving requests from processes of the second OS 160 while waiting in a sleep state on recv() call.

The mentioned event descriptors contain information about the event, including the type of the event (call(), recv()), the identifier of the proxy process thread in which the event occurred, the descriptor of the shared memory range in which the data was received, etc. In the case when there are no elements in the event buffer, the event() call waits for an event. In the case where the event buffer contains elements, the call to event() returns the handle from the specified buffer.

On FIG. 4 shows a method for controlling the delivery of messages 140 transmitted between at least the first 134 and the second 161 processes implemented by a computer. So, at step 410 , using the process creation tool 280 for the second process 161 , a proxy process 135 in the first OS 100 is created, designed to exchange messages 140 with the second process 161 in the second OS 160 and having a program interface corresponding to the program interface of the second process 161 . Then, at step 420 , at least one security policy is assigned by the policy assigner 290 to the created proxy process 135 to control the delivery of messages 140 associated with said proxy process 135 , where said messages 140 are transmitted through a given programming interface. At step 430 , a security monitor 120 is formed for the first OS 100 taking into account the architectural features of the OS 240 , in particular, taking into account the created proxy process 135 , and also taking into account the security requirements for the first OS 100 , which are expressed in the assigned security policies from the policy base 121 . Finally, at step 440 , the generated security monitor 120 monitors the delivery of messages 140 between at least the first 134 and the second 161 processes by monitoring the delivery of messages 140 associated with said proxy process 135 based on the security policies from the policy base 121 . It is worth noting that the particular embodiments disclosed earlier also apply to the method of FIG. 4 .

Fig. 5 shows an example of a general purpose computer system, a personal computer or a server 20 ', comprising a central processing unit 21 ', system memory 22 ', and a system bus 23 ', which contains various system components including memory associated with the central processing unit 21 '. The system bus 23 is implemented as any bus structure known in the art, in turn comprising a bus memory or bus memory controller, a peripheral bus, and a local bus capable of interfacing with any other bus architecture. The system memory contains read only memory (ROM) 24 , random access memory (RAM) 25 . The main input/output system (BIOS) 26 contains the basic procedures that ensure the transfer of information between the elements of a personal computer 20 , for example, at the time of booting the operating system using ROM 24 .

The personal computer 20 in turn comprises a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29 and an optical drive 30 for reading and writing to removable optical disks 31 such as CD-ROM, DVD -ROM and other optical storage media. The hard disk 27 , the magnetic disk drive 28 , the optical drive 30 are connected to the system bus 23 via the hard disk interface 32 , the magnetic disk interface 33 , and the optical drive interface 34 , respectively. Drives and related computer storage media are non-volatile means of storing computer instructions, data structures, program modules, and other personal computer data 20 . The present description discloses an implementation of a system that uses a hard disk 27 ', a removable magnetic disk 29 ', and a removable optical disk 31 ', but it should be understood that other types of computer storage media 56 that are capable of storing data in a computer-readable form (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.), which are connected to the system bus 23 through the controller 55 .

The computer 20 has a file system 36 that stores the recorded operating system 35 as well as additional software applications 37 , other program modules 38 and program data 39 . The user has the ability to enter commands and information into the personal computer 20 through input devices (keyboard 40 , mouse 42 ). Other input devices (not shown) may be used: microphone, joystick, game console, scanner, etc. Such input devices are normally connected to the computer system 20 through a serial port 46 , which in turn is connected to the system bus, but may be connected in other ways, such as through a parallel port, game port, or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48 '. In addition to the monitor 47 , the personal computer may be equipped with other peripheral output devices (not shown), such as speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment using a network connection to other remote computers 49 . The remotes 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the nature of the personal computer 20 shown in FIG. 5 . Other devices may also be present in the computer network, such as routers, network stations, peer-to-peer devices, or other network nodes.

The network connections may form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks (also information systems), internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the first network 50 via a network adapter or network interface 51 . When using networks, personal computer 20 may use a modem 54 or other means to communicate with a wide area network, such as the Internet. The modem 54 , which is an internal or external device, is connected to the system bus 23 via the serial port 46 . It should be clarified that the network connections are only indicative and are not required to represent the exact network configuration, i.e. in fact, there are other ways to establish a connection by technical means of communication from one computer to another.

As described, the components, execution steps, data structure described above can be executed using various types of operating systems, computer platforms, programs.

In conclusion, it should be noted that the information given in the description are examples that do not limit the scope of the present invention defined by the formula.

Claims (52)

1. A method for controlling the delivery of interprocess communication messages (hereinafter referred to as messages) transmitted between processes from different operating systems (OS), in which: a) using the process creation tool, a proxy process is created in the first OS, designed to exchange messages between at least the first process from the first OS and the second process in the second OS and having a programming interface corresponding to the programming interface of the second process, while the first OS and the second OS is operating systems installed in different computing environments; b) using the policy assigner, assigning at least one security policy to the created proxy process to control the delivery of messages associated with the proxy process, where messages are transmitted through a given programming interface; c) using the generated security monitor, they control the delivery of messages between at least the first and second processes by monitoring the delivery of messages associated with the proxy process based on security policies. 2. The method of claim 1, wherein the message delivery control includes at least allowing or denying message delivery. 3. The method of claim. 1, in which the messages include at least one of: a request to start the process, a request and response to perform inter-process communication, a process request to the security monitor. 4. The method of claim 1, wherein the second OS is one of at least the following: a guest OS running in a virtual machine running the first OS on the computer; a guest OS running on a virtual machine, wherein the first OS is a second guest OS running on a second virtual machine and associated with the first virtual machine via a hypervisor; a second OS on a second computer that is connected to the computer running the first OS via a network. 5. The method according to claim 1, wherein the security monitor is generated for the first OS using a generation tool. 6. The method according to claim 5, in which the security monitor is formed taking into account the architecture features of the first OS, in particular, taking into account the created proxy process, as well as taking into account the security policies assigned to the proxy process from the policy base. 7. The method of claim 5, wherein the security monitor is generated by generating a security monitor code including one of source code, intermediate code, executable code. 8. The method according to claim. 1, in which, when monitoring message delivery, the security monitor uses the proxy process API to determine allowed messages for the proxy process, while using the policy assignment tool, additionally specifying a list of allowed messages in accordance with the programming interface and assigning a security policy that prohibits the delivery of messages from the proxy process if the security monitor detected an attempt to deliver messages that are not on the allowed list. 9. The method according to claim 1, in which, when monitoring message delivery, the security monitor uses the proxy process API to determine the list of processes with which the proxy process is allowed to exchange messages, while using the policy assignment tool, additionally assign a security policy that prohibits the exchange messages between the proxy process and processes not in the process list, the process list including at least the first process. 10. The method of claim. 1, which creates a proxy process for at least two processes of the second OS, if between said processes of the second OS there is a programming interface for messaging. 11. The method of claim 1, wherein the security policies use at least one of the following models: a) basic operations; b) finite state machine; c) temporary machine; d) role-based access control; e) mandatory integrity control; f) regular expressions; g) discrete events; h) mandatory references; i) temporal logic. 12. The system for monitoring the delivery of messages transmitted between processes from different OS, implemented by a computer, including memory and at least one processor functionally associated with the memory, configured to implement the following means: a) a process creation tool for creating a proxy process in the first OS, designed to exchange messages between at least the first process in the first OS and the second process in the second OS and having a programming interface corresponding to the programming interface of the second process, while the first OS and the second OS are operating systems installed in different computing environments; b) a policy assigner for assigning at least one security policy to the created proxy process to control the delivery of messages associated with said proxy process, where the given API is used to transmit said messages, while said policies are stored in the security policy database , which is stored in memory; c) a generated security monitor for monitoring the delivery of messages between at least the first and second processes by monitoring the delivery of messages associated with said proxy process based on security policies from the security policy database. 13. The system of claim 12, wherein the message delivery control includes at least allowing or denying message delivery. 14. The system of claim 12, wherein the messages include at least one of a process start request, an interprocess communication request and response, a process request to a security monitor. 15. The system of claim 12, wherein the second OS is one of at least the following: a guest OS running in a virtual machine running the first OS on the computer; a guest OS running on a virtual machine, wherein the first OS is a second guest OS running on a second virtual machine and associated with the first virtual machine via a hypervisor; a second OS on a second computer that is connected to the computer running the first OS via a network. 16. The system of claim. 12, further comprising a generator for generating a security monitor in the first OS. 17. The system according to claim 16, in which the generation tool is designed to generate a security monitor, taking into account the architecture features of the first OS, in particular, taking into account the created proxy process, and also taking into account the security policies assigned to the proxy process from the policy base. 18. The system of claim 16, wherein the builder is for generating a security monitor by generating a security monitor code including one of source code, intermediate code, executable code. 19. The system of claim. 12, in which, when monitoring message delivery, the security monitor is designed to use the proxy process API to determine allowed messages for the proxy process, while the policy assigner is additionally designed to set the list of allowed messages in accordance with the programmatic interface and assigning a security policy that prohibits the delivery of messages from the proxy process if the security monitor detected an attempt to deliver messages that were not on the allowed list. 20. The system according to claim 12, in which, when monitoring message delivery, the security monitor is designed to use the proxy process API to determine the list of processes with which the proxy process is allowed to exchange messages, while using the policy assignment tool, the security policy is additionally assigned, prohibiting the exchange of messages between the proxy process and processes not in the process list, while the process list includes at least the first process. 21. The system of claim 12, wherein the process creator is for creating a proxy process for at least two processes of the second OS if there is a messaging API between said processes of the second OS. 22. The system of claim 12, wherein the security policies use at least one of the following models: a) basic operations; b) finite state machine; c) temporary machine; d) role-based access control; e) mandatory integrity control; f) regular expressions; g) discrete events; h) mandatory references; i) temporal logic.

Images