Patent Description:
Modem operating systems (hereafter OS) are complex information systems with a large set of installed software for performing a wide variety of functions. At the same time, software developers are constantly working to correct bugs and expand the functionality of the software. However, this quantity and range of software carries significant information security risks due to vulnerabilities in the software and also the possibility of unauthorized installation of malicious software. The first layer of protection against these threats is the features of the OS architecture as well as the built-in security tools of the OS, since it is the OS that provides the mechanisms for processing and monitoring inter-process communication, which can be implemented, inter alia, 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, for example, performance and the simplicity of communication between drivers. However, 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 a monolithic OS. Thus, if a vulnerability exists in the OS, delivery of certain unwanted or malicious messages may be allowed between processes by the means for inter-process communication processing and control. An example of such a malicious message between processes is a message requesting access to a protected area of memory. Another type of OS kernel is a microkernel (for example, the KasperskyOS, Symbian, etc. kernels), which provides a minimum set of elementary process control and abstraction functions for working with the hardware. The microkernel architecture of the OS is characterized by the small size of the microkernel and the trusted computing platform. This contributes to a higher level of reliability and security of the OS's microkernel architecture, since it is easier to verify the correctness of a small amount of microkernel code. However, this type of OS architecture typically has lower performance. There are also operating systems with hybrid kernels (such as 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 the monolithic kernel.

A current function of operating systems is to ensure the reliability and security of inter-process communications implemented by exchanging messages between processes. An even more challenging task is that of securing inter-process communications between the first and second processes, where the second process is executed in an environment that is hardware- or software-isolated from the first execution environment in which the first process is executed. For example, the second process can be executed on a second computer that is connected to the first computer over a network, on a virtual machine, or in other execution environments. In this case a technical problem arises due to the complexity of monitoring the delivery of inter-process communication messages between processes from different operating systems to comply with the security policy. In order to comply with policy, typical technologies disallow monitoring of the delivery of inter-process communication messages between processes from different operating systems.

Therefore, there is a need for a method and a system for improving information security while monitoring of the delivery of inter-process communication messages between processes from different operating systems.

The scientific document XP055967100 entitled "Improving the Security of Building Automation Systems Through an seL4-based Communication Framework" by Habeeb Richard describes a secure communication framework for rich access control policy for operating system services and objects.

Aspects of the disclosure relate to information security, more specifically, to systems and methods of monitoring delivery of messages passed between processes from different operating systems (OSs). The method of the present disclosure improves the OS security for the exchange of inter-process communication messages passed between first and second processes from different operating systems, by creating a proxy process for sending and receiving messages from the second process which has a programming interface for the proxy process, and adding a security policy for monitoring the delivery of messages associated with the given proxy process. The method also increases the level of monitoring of the delivery of inter-process communication messages passed between first and second processes which are being executed on different operating systems.

In one example, a method is provided for monitoring delivery of messages passed between processes from different operating systems, the method comprising: creating a proxy process in a first Operating System (OS) for a second process, wherein the second process is from a second OS, the first and second OS being installed in respective computing environments, assigning at least one security policy to the created proxy process for monitoring delivery of messages associated with the created proxy process, where the messages are transmitted through a programming interface of the created proxy process corresponding to a programming interface of the second process, generating a security monitor for the first OS based on the created proxy process and security policies of the first OS, and monitoring the delivery of messages between at least a first process in the first OS and the second process, wherein the monitoring of the delivery of messages associated with the proxy process is based on the security policies.

In one example, the monitoring of the delivery of messages includes, for each message, at least an authorization or a prohibition of the delivery of the message.

In one example, the messages comprise at least one of: a request to launch a process, a request and a reply for implementing of communication between processes, and a process request to the security monitor.

In one example, the second OS comprises at least one of: a guest OS running on a virtual machine under a control of the first OS on a first computer, a guest OS running on a virtual machine, the first OS being a second guest OS running on a second virtual machine and connected to the first virtual machine through a hypervisor, and a second OS on a second computer that is connected to the first computer that is running the first OS over a network.

In one example, the security monitor is generated for the first OS using a generating tool.

In one example, the security monitor is generated based on features of an architecture of the first OS, the features including at least the created proxy process and the security policies assigned to the proxy process, the security policies being obtained from a security policy database.

In one example, the security monitor is generated by creating a code of the security monitor, the created code including at least one of: a source code, an intermediate code, and an executable code.

In one example, when monitoring the delivery of messages, the security monitor uses the programming interface of the proxy process to determine allowed messages for the proxy process, and a policy assignment tool is used to additionally specify a list of allowed messages according to the programming interface and to assign a security policy that prohibits the delivery of messages from the proxy process, when the security monitor detects an attempt to deliver messages that are not in the list of allowed messages.

In one example, when monitoring the delivery of messages, the security monitor uses the programming interface of the proxy process to determine a list of processes with which the proxy process is allowed to exchange messages, and a policy assignment tool is used to additionally assign a security policy that prohibits messages from being exchanged between the proxy process and processes that are not in the list of processes, wherein the list of processes includes at least the first process.

In one example, the proxy process is created for at least two processes of the second OS when a programming interface for exchanging messages exists between said at least two processes of the second OS.

In one example, the security policies use a model based on at least one of: basic operations, a finite state machine, a timed automation, a role-based access control, a mandatory integrity control, regular expressions, discrete events, object capability model, and a temporal logic.

According to one example of the disclosure, a system is provided for monitoring delivery of messages passed between processes from different operating systems, the system comprising at least one hardware processor of a first computer configured to: create a proxy process in a first Operating System (OS) for a second process, wherein the second process is from a second OS, the first OS being installed in the first computer and the second OS being installed in a different computing environment from the first computer, assign at least one security policy to the created proxy process for monitoring delivery of messages associated with the created proxy process, where the messages are transmitted through a programming interface of the created proxy process corresponding to a programming interface of the second process, generate a security monitor for the first OS based on the created proxy process and security policies of the first OS, and monitor the delivery of messages between at least a first process in the first OS and the second process, wherein the monitoring of the delivery of messages associated with the proxy process is based on the security policies.

The method and system of the present disclosure are designed to provide information security, in a more optimal and effective manner, enabling messages from processes executed on different OSs to be monitored.

Exemplary aspects are described herein in the context of a system, method, and a computer program for monitoring delivery of messages passed between processes from different operating systems. Those of ordinary skill in the art will realize that the following description is illustrative only and is not intended to be in any way limiting. Other aspects will readily suggest themselves to those skilled in the art having the benefit of the disclosure. Reference will now be made in detail to implementations of the example aspects as illustrated in the accompanying drawings. The same reference indicators will be used to the extent possible throughout the drawings and the following description to refer to the same or like items.

In order to describe the teachings of the present disclosure with clarity, a brief summary of terms used throughout the disclosure is first provided below.

A process refers to a sequence of operations in an execution of a program or a part thereof together with useful data, which includes one or more threads and associated system resources.

Inter-process communication (IPC) refers to a set of methods for exchanging data between multiple threads in one or more processes. The processes can be launched on one or more computers that are connected to each other via the network. IPC methods may be divided into methods of message passing, synchronization, shared memory, and remote procedure calls.

An operation refers to an elementary action performed within the process under consideration (an example of an operation can be an API function). A modem operating system uses both synchronous and asynchronous operations to exchange data between two processes using inter-process communication methods.

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

A finite state machine (FSM) refers to a model of a discrete device characterized by states and transitions from one state to another. Each state of the finite state machine characterizes one of the possible situations in which the finite state machine may be located.

<FIG> illustrate block diagrams of inter-process communications using a security monitor <NUM> based on an example of an operating system <NUM> with a microkernel architecture. The OS <NUM> shown in <FIG> includes isolated processes <NUM>-<NUM> of applications of the OS <NUM> that communicate with one another through inter-process communication, as well as with the OS kernel <NUM> by means of programming interfaces using messages <NUM> (also inter-process communication messages, IPC messages). Referring to <FIG>, for clarity, the inter-process communication messages are indicated by a bold arrow starting with a dot. Messages <NUM> include the following: a request to launch <NUM> from a process <NUM>, a request <NUM> from the process <NUM> or a response <NUM> from another process <NUM> (for example, calls to a method of process <NUM> by process <NUM>), a process request <NUM> to the security monitor <NUM> (such as security request <NUM>). It is worth noting that messages <NUM> in the present disclosure are understood to mean inter-process communication messages, in general providing the facility for communication between different processes of the OS <NUM>, including the processes <NUM>-<NUM>. The security monitor <NUM> is a component of the OS <NUM> designed to monitor the delivery of the above-mentioned messages <NUM>. Details of the implementation of the security monitor <NUM> will be disclosed below. The messages <NUM> may also include an error notification from the OS kernel <NUM> in response to the messages <NUM> from processes <NUM>-<NUM>. In this case, the above-mentioned interfaces implemented by the processes are data structures containing declared methods which implement the functionality of the corresponding process.

The above mentioned interfaces are statically defined and the allowed communications between the processes are defined in advance. In one example, the messages <NUM> are sent and received by processes <NUM>-<NUM> using system calls to the OS kernel <NUM>.

In one example, the system calls may include the following:.

In one example, the system call reply() is executed in the same process thread in which the call recv() was executed.

The security monitor <NUM> is implemented with the ability to run on a computer processor running the OS <NUM> (an example of a general purpose computer <NUM> is shown in <FIG>). The security monitor <NUM> monitors the delivery of the messages <NUM> based on decisions <NUM>. The decisions <NUM> are based on security policies obtained from the policy database <NUM>. The policy database <NUM> is stored on a machine-readable computer medium (in memory) on which the OS <NUM> is installed, for example, on the storages <NUM> or <NUM> of the computer <NUM> (see <FIG>). In one example, the monitoring of the delivery of the message <NUM> includes authorizing or prohibiting delivery of a message <NUM> and, respectively, authorizing or prohibiting the execution of communication that uses the message <NUM>. In one example, the decision <NUM>, by the security monitor <NUM>, of the method for monitoring the delivery of the message <NUM> indicates either an authorization or a prohibition of a transmission of the message <NUM> in compliance with the security policy. In one example, the decision <NUM> is used, by the security monitor <NUM> or its components, to implement the monitoring of the delivery of the messages <NUM> (see <FIG>). Based on the security policies from the policy database <NUM>, the decision <NUM> may be issued using the data in the message <NUM> (for example, the name of the process to be launched or the actual arguments of the process method called).

Also, the decision <NUM> on the method for monitoring the delivery of the message <NUM> may depend on the correctness of the structure of the message <NUM>. Thus, if the message <NUM> has an invalid structure, the transmission of the message <NUM> may be prohibited. In this case, valid structures of the messages <NUM> may be defined using a declarative description of the interface of the process-receiver of the message <NUM>. The above-mentioned structure may contain the size of the message <NUM>, valid arguments and other valid parameters of the message <NUM>.

In one example, the security monitor <NUM> may be part of the OS kernel <NUM>, or a separate application executed on the computer's processor.

In another example, the security monitor <NUM> runs on the computer's processor in the privileged mode of the OS kernel <NUM>.

One example of the OS <NUM> additionally may include an audit service <NUM>, designed to log results of the monitoring of the delivery of the messages <NUM>. In this case, the monitoring of the delivery of the message <NUM> additionally may include performing an audit using the audit service <NUM>. In another example, the security monitor <NUM> may perform monitoring of the delivery of messages <NUM>, additionally taking account of a current status of the audit service <NUM>.

In one example, the status of the audit service <NUM> indicates that the audit service <NUM> is ready to receive and store messages <NUM>. For example, if the process <NUM> sends a request <NUM> to a secure resource (via the process <NUM>) where the information about access to the secure resource should always be logged but the status of the audit service <NUM> indicates that the audit service <NUM> is not currently saving the messages <NUM>, then such a request <NUM> will be denied by the security monitor <NUM> in accordance with the security policy.

In another example, the OS <NUM> may contain the security monitor context <NUM>, wherein the security monitor <NUM> monitors the delivery of the messages <NUM> additionally taking into account the security monitor context <NUM>, where the security monitor context <NUM> contains values of security policy parameters.

In another example, the security monitor <NUM> may additionally be designed to change the security monitor context <NUM> taking into account the decisions <NUM> based on the security policies obtained from the policy database <NUM>.

In one example, the security policies use a finite state machine model, a mandatory integrity control model, or other models to implement the security policies. Details of these models will be described later in conjunction with the description of <FIG>. Depending on the models used by the security policies, the security monitor context <NUM> may contain different security policy parameters. For example, for security policies based on a mandatory integrity control model, the security monitor context <NUM> may contain values for integrity levels and access levels to protected resources. For security policies based on a finite state machine, the security monitor context <NUM> may contain a current value of the state of the finite state machine and a transition table of the finite state machine.

<FIG> illustrates an example block diagram of inter-process communications for monitoring a delivery of an allowed request <NUM> from a process <NUM> to a process <NUM> using a security monitor <NUM>. The process <NUM> can call an interface method of the process <NUM>. As such, the process <NUM> calls the interface method of process <NUM> by sending a request <NUM> containing the input arguments of the called method. Process <NUM> sends the request <NUM> via the OS kernel <NUM>, which in turn sends the request <NUM> to the security monitor <NUM> for verification. The security monitor <NUM> issues the decision <NUM> "permitted" based on the security policies and transfers this decision <NUM> to the OS kernel <NUM>. Then, the kernel <NUM> forwards the request <NUM> based on the decision <NUM> to process <NUM>.

For the example shown in <FIG>, process <NUM> then sends a reply <NUM> to process <NUM>, where the reply <NUM> contains the output arguments of the called method. The method for sending the reply <NUM> is the same as the method for sending the request <NUM>, but in reverse order, from process <NUM> to process <NUM>. That is, the process <NUM> sends a reply <NUM> using the OS kernel <NUM>, which in turn sends a reply <NUM> to the security monitor <NUM> for verification. The security monitor <NUM> issues a new decision <NUM> "permitted" based on the security policies and transfers this new decision <NUM> back to the OS kernel <NUM>. Then, the kernel <NUM>, based on the new decision <NUM>, forwards the reply <NUM> to process <NUM>.

<FIG> illustrates an example block diagram of inter-process communications for monitoring a delivery of a denied request <NUM> from a process <NUM> to a process <NUM> using a security monitor <NUM>. Process <NUM> sends the request <NUM> via the OS kernel <NUM>, which in turn sends the request <NUM> to the security monitor <NUM> for verification. The security monitor <NUM> issues the decision <NUM> "prohibited" based on the security policies and transfers this decision <NUM> to the OS kernel <NUM>. The kernel <NUM> then sends an error notification to process <NUM> based on the decision <NUM>. In this case, the request <NUM> will not be transferred to process <NUM>.

<FIG> illustrates an example block diagram of communication between the first process <NUM>, implemented in the first OS <NUM>, and the second process <NUM>, implemented in the second OS <NUM>, via a communication channel <NUM>, which is not monitored by the security monitor <NUM>. For ease of presentation, here and below the first OS is referred to as OS <NUM> (see <FIG>). It is worth noting that the second OS <NUM> can be any OS, the architecture of which may be known in the relevant art. Thus, the second OS <NUM> may include the operating system <NUM>, the architecture of which is represented in <FIG>. As such, the first OS <NUM> and the second OS <NUM> can be either different OS's (that is, they may have different OS architectures) or the same OS, but with the key difference that the first OS <NUM> and the second OS <NUM> are installed in different computing environments. Thus, the first OS <NUM> and the second OS <NUM> can be installed on different computers, virtual machines, or in mutually isolated software or hardware computing environments, which in turn are implemented with the ability to run on the computer <NUM> (see <FIG>). One example of technology for isolating computing environments is the TrustZone technology.

Thus, the first process <NUM> communicates with the second process <NUM> using the communication channel <NUM>, such as a computer network, a virtual machine transport mechanism (for example, the paravirtualization extension VirtIO), and another communication channel depending on the computing environments on which the first OS <NUM> and the second OS <NUM> are installed. However, there are several disadvantages to the communication illustrated in <FIG>. Specifically, for the communication between the first process <NUM> and the second process<NUM>, the delivery of the messages <NUM> which are exchanged between these processes occurs over the communication channel <NUM>, which cannot be monitored by the security monitor <NUM> for ascertaining compliance with security policy <NUM>. This reduces the security of the first OS <NUM> when exchanging messages <NUM> passed between the first <NUM> and the second <NUM> processes. Thus, the example of the communication between the first <NUM> and the second <NUM> processes presented in <FIG> does not solve the stated technical problem. In contrast, as shown in <FIG>, for the communication between the first process <NUM> and the second process <NUM>, the method of the present disclosure can be used to solve the specified technical problem.

<FIG> illustrates an example block diagram of a secure communication between the first process <NUM>, implemented in the first OS <NUM>, and the second process <NUM>, implemented in the second OS <NUM>. It is worth noting that in general, the second process <NUM> may communicate with multiple processes in the first OS <NUM>, one of which is represented in the figure as the first process <NUM>. However, for ease of presentation, only the first process <NUM>, which communicates with the second process <NUM>, will be considered in the following description. As in the previous example shown in <FIG>, the first OS <NUM> is connected to the second OS <NUM> via a communication channel <NUM> that is not monitored by the security monitor <NUM>. The second OS <NUM> can be any OS with an architecture known from the prior art, including the operating system <NUM>, the architecture of which is shown in <FIG>. The first OS <NUM> and the second OS <NUM> can be installed on different computers, virtual machines, or in computing environments isolated from each other in software or hardware, which in turn are implemented with the ability to run on the computer <NUM> (see <FIG>). However, the second process <NUM> does not communicate with the first process <NUM> directly, but using a previously created proxy process <NUM>. In this case, the proxy process <NUM> shown in the first OS <NUM> (but not in the second OS <NUM>), is designed for exchanging messages <NUM> with the second process <NUM> via the communication channel <NUM> and has a programming interface corresponding to the programming interface of the second process <NUM>.

In one example, when monitoring the delivery of messages <NUM> the security monitor <NUM> uses the programming interface of the proxy process <NUM> to determine the allowed messages <NUM> for the proxy process <NUM>. However, at least one security policy is pre-defined in the policy database <NUM> to prevent the delivery of messages <NUM> from the proxy process <NUM> if the security monitor <NUM> has detected an attempt to deliver messages <NUM> that are not in the allowed list. In this case, the list of allowed messages <NUM> and the corresponding security policies are pre-defined using the policy assignment tool <NUM> when the security monitor <NUM> is generated (see <FIG>). Thus, the first process <NUM> communicates with the proxy process <NUM> by sending inter-process communication messages <NUM> and under the control of the security monitor <NUM>, while the proxy process <NUM> is connected to the second process <NUM> via the communication channel <NUM>, wherein the security monitor <NUM> does not monitor the communication channel <NUM>.

In one example, in the second OS <NUM> there is a separate proxy process corresponding to each second process. For example, the proxy process <NUM> corresponds to the second process <NUM>, and the second proxy process (not shown in the figure), different from the proxy process <NUM> corresponds to the third process <NUM>. In addition, in a preferred embodiment, the processes <NUM> and <NUM> are not interconnected. In this case, in one example, in the second OS <NUM>, the second process <NUM> can be connected to the third process <NUM> using the application interface for exchanging messages <NUM>. In this example, it is possible to use one proxy process <NUM> common to both mentioned processes <NUM> and <NUM>. Thus, the processes <NUM> and <NUM> form a single security domain, communication with which takes place through a single proxy process <NUM>, which also allows the communication between the second <NUM> and third <NUM> processes of the second OS <NUM> to be monitored. It is worth noting that the aforementioned security domain, which includes the processes <NUM> and <NUM>, may also include more processes of the second OS <NUM>, not shown in the figure. In another scenario, when the second OS <NUM> contains multiple distinct security domains, wherein each distinct security domain includes at least one second process, a separate proxy process may be defined in the first OS <NUM> for each of the distinct security domains.

The above system (as shown in <FIG>) used for communication between the first <NUM> and second <NUM> processes allows the specified technical problem to be solved and the stated technical results to be achieved, namely to improve the security of an OS during the exchange of messages <NUM> for inter-process communication passed between the first <NUM> and the second <NUM> processes of different operating systems. The technical problems are solved by: creating a proxy process <NUM> for sending and receiving messages <NUM> from the second process <NUM>, wherein the second process <NUM> has a programming interface for the proxy process <NUM>; adding a security policy for monitoring the delivery of messages <NUM> related to the aforementioned proxy process <NUM>, and increasing the monitoring of the delivery of messages <NUM> for inter-process communication passed between the first <NUM> and the second <NUM> processes. More information about examples of the present disclosure regarding the creation of the proxy process <NUM> and the assignment of security policies to the proxy process <NUM> created, will be described below.

<FIG> illustrates an exemplary security monitor generating system <NUM>. The security monitor generating system <NUM> is used to improve the security of the OS <NUM> when exchanging messages <NUM> and to perform monitoring of the delivery of said messages <NUM> to the recipients. In this case, the security monitor <NUM> can be used by software developers in different operating systems <NUM> as well as in any other computer systems in which message passing <NUM> is used, in particular, in databases and in application software. An example of this use was described earlier in conjunction with the descriptions of <FIG>. For each operating system <NUM>, a security monitor <NUM> is constructed based on features of the OS architecture <NUM> and by taking account of the security requirements for that operating system <NUM>, as expressed in the security policies. It is worth noting that for various software and firmware development systems based on OS <NUM> (hereafter referred to as the development system), the main objects of the OS architecture <NUM> can be shared. For example, processes, services, applications, drivers that are responsible for operating the OS kernel <NUM>, and other components of the operating system <NUM>, can be shared. At the same time, other objects of the OS architecture <NUM> that are responsible for the functionality of the development system will be different for each of the mentioned systems. Therefore, there will also be different security policies that are used to monitor the delivery of messages <NUM>. Development systems can include software as well as firmware systems.

The system <NUM> contains the policy database <NUM> designed to store the security policies required to monitor the delivery of messages <NUM>. The system <NUM> also contains at least one configuration tool <NUM> which is designed to configure the corresponding verification module <NUM> based on the security policies received from the generating tool <NUM>. The verification module <NUM> is designed to issue a decision <NUM> on the method for monitoring the delivery of the message <NUM> (hereafter, the decision) at the request of the security monitor <NUM>, while implementing the security policy. The system <NUM> also contains a description of the OS architecture <NUM>, which in turn includes OS architecture objects such as the processes and applications of the OS <NUM>.

In one example, the mentioned OS architecture objects additionally include objects of the development system based on the OS <NUM>.

In another example, the OS architecture objects additionally include:.

In another example, the OS architecture object is additionally a resource driver - a process that manages resources and access to the resources. In one example, the resource is, in particular, a file, port, or process. For example, the file system may be a resource driver, and the files themselves may be resources to which the file system provides access by other processes.

In one example, the system <NUM> further contains a generating tool <NUM> designed to analyze security policies, where the analysis consists, inter alia, in identifying the processes for which the given security policy is used.

In one example, the above analysis takes into account the OS architecture objects <NUM>, including the above-mentioned processes and applications. The generating tool <NUM> is also designed to select security policies from the policy database <NUM> for the corresponding configuration tools <NUM> and to transfer at least one selected security policy to the corresponding configuration tool <NUM>. In one example, the generating tool <NUM> is also designed to generate a security monitor <NUM> using the configured verification modules <NUM> obtained from each configuration tool <NUM>, based on the analysis results.

In one example, the generating tool <NUM> generates the security monitor <NUM> by creating the code of the security monitor <NUM>. In one example, the code of the security monitor <NUM> may be a source code, an intermediate code, or an executable code. In one example, the generation of the code of the security monitor <NUM> may further include code optimization and error analysis. Thus, the generating tool <NUM> may be the compiler that generates the code in question.

The OS architecture <NUM>, the policy database <NUM> and the configuration tools <NUM> can be pre-configured using the development tool <NUM>. To do the pre-configuration, the development tool <NUM> may provide a set of APIs (application programming interfaces) or plug-in modules for software development. The term "interface" is used hereinafter to refer to the process interface described earlier, and the abbreviation "API" is used hereinafter to refer to the application programming interface.

In one example, at least part of the OS architecture <NUM>, part of the security policies from the policy database <NUM>, and part of the configuration tools <NUM> may be shared (based on templates) across different operating systems <NUM>. In this case, using the development tools <NUM>, the developer may configure the configuration tools <NUM>, the OS architecture <NUM>, and the security policies from the policy database <NUM>. The configuring may be performed by: adding, to the template in question, the security policies in the architecture of the OS <NUM> that are missing from the template, as well as the configuration tools <NUM> that are necessary to reflect the features of the OS <NUM> or the development system based on the OS <NUM>, and the security requirements of the OS <NUM> or of the development system based on the OS <NUM>, respectively, for which the developer generates the security monitor <NUM>. In addition, some of the data can be deleted from the template in question, if it will not be needed in the OS <NUM> or in the OS development system <NUM>, respectively. For example, some security policies and applications may be deleted.

The security monitor <NUM> generated, together with the other components of the OS <NUM>, are also incorporated into the operating system <NUM>. The incorporation of the security monitor <NUM> and the OS components <NUM> may be implemented using known techniques, for example, during the compilation stage of the OS <NUM> using the OS <NUM> compiler, or by installing the security monitor <NUM> on the OS <NUM>. As mentioned earlier, the security monitor <NUM> may be part of the OS kernel <NUM> or be a separate application of the OS <NUM>. The security monitor <NUM> runs in a privileged mode on the OS kernel <NUM>. For the OS <NUM>, an OS installation image <NUM> may also be created to install the OS <NUM> on end-user computing devices. The OS installation image <NUM> may be, for example, an archive, an executable file, or an installation package. The installation package is an archive file that includes the files of the OS <NUM>, control files, and optionally, files for configuring the installation process of the OS kernel <NUM>. In addition, the installation package may include system developer files based on the OS <NUM>. These files may be provided as source code, intermediate code, or executable code.

The description of the security policies, in accordance with the teachings of the present disclosure, are provided below.

In one example, the security policies use at least one of the following models:.

The security policies from the policy database <NUM> may be defined using a specification language, such as PSL (policy specification language). In the PSL example, mandatory integrity control is defined by the policy class Mandatory_integrity_control. The class (family) of security policies defines a set of rules that match the rules of the model used in the security policy. The security policy specification determines the correspondence of these rules with communications in the system that can be implemented by exchanging messages <NUM> between processes. For each communication attempt, that is, each time the security monitor <NUM> verifies the messages <NUM>, the security monitor <NUM> applies the rules to determine a decision as to the validity of the given communication (delivery of message <NUM>). To use a policy class, a policy object is created based on it, for which the configuration is specified.

In one example, the analysis of the security policy and objects of the OS architecture <NUM> includes at least one of the following types of analysis: lexical analysis, syntactic analysis, semantic analysis. This security policy analysis identifies objects of the OS architecture <NUM>, in particular, the processes involved in the exchange of messages <NUM>, for which the specified security policy applies. That is, a correspondence is determined between the identified objects in the OS architecture <NUM> and the security policy applied to the specified objects. For example, if a security policy allows a request <NUM> from process <NUM> to process <NUM>, an analysis of that security policy identifies specific processes <NUM>-<NUM> and information about the allowed request <NUM>. It is worth noting that as a result of this security policy analysis, other objects of the OS architecture <NUM> that are verified in the specified security policy may be further identified. For example, when the message <NUM> is addressed to a specified method, process interface methods will be passed to the specified process interface. In this case, the security policies will verify the requirement that the defined process interfaces and defined interface methods are used when messages <NUM> are passed between the identified processes.

In the example of the PSL language, which can be used to define security policies in the policy database <NUM>, a reference to the process <NUM>, which is the source of the request <NUM>, may be contained in the variable scr. A reference to the process <NUM>, which is the destination of the request <NUM>, may be contained in the variable dst. Accordingly, it is the above-mentioned analysis of the security policy, written in the PSL language, that will allow identification of the specified OS architecture objects for which the specified security policy will be applied.

In another example, the analysis of the security policies also includes verification of the types of the objects of the OS architecture <NUM>, as well as an analysis for errors in the security policies.

The results of the above analysis are taken into account in generating the security monitor <NUM>. For example, the security monitor <NUM> may record the application conditions of the security policies - a list of objects of the OS architecture <NUM>, in particular processes and security policies corresponding to this list, as well as the verification modules <NUM>. Therefore, when a message <NUM> is received from the OS kernel <NUM>, the generated security monitor <NUM> identifies the objects of the OS architecture <NUM> participating in the message passing <NUM> and then determines the security policies that are applied to the specified objects of the OS architecture <NUM>. The security monitor <NUM> then sends the messages <NUM> to the verification modules <NUM>, which correspond to the specified security policies, to decide on which method to use for monitoring the delivery of the message <NUM>.

In another example, a syntactic analysis is carried out by constructing a syntactic tree for the code of the security monitor <NUM>, wherein the syntax tree includes the code of the verification modules <NUM> generated by the at least one configuration tool <NUM>.

Security policies may use basic operations that allow or prohibit passing of the message <NUM> on the condition that the parameters of the message <NUM> (for example, the name of the process to be launched or the actual arguments of the method to be called) match the data specified in the security policy. For example, the security policy might determine that the process <NUM> may receive any messages <NUM>, but that the process <NUM> is not allowed to send messages <NUM>.

The security policies may also use a finite state machine, where the security policy determines whether the message <NUM> is allowed or denied depending on the state of the finite state machine and in accordance with the state transition table of the finite state machine.

The timed automata model, in particular timed automata of the ERA type (event-recording automata), is a special case of finite state machines. In this model, an additional time parameter (timer) is defined for each message <NUM>, equal to the time since the last receipt of this message <NUM>. For example, a transition from one finite state machine state to another state may be made if the message <NUM> was received after the time determined by the timer.

The Mandatory integrity control model is used to allow or deny the delivery of a message <NUM>. According to the mandatory integrity control model, using the security monitor <NUM> the objects of the OS architecture <NUM> involved in passing the message <NUM>, for example, the processes <NUM>-<NUM>, are mapped to two numbers called the integrity level and the access level. In the process, security policies based on mandatory integrity control are used to allow the delivery of a message <NUM> from one object to another, that is, using the values of the integrity levels and the access levels of the objects. For example, a security policy may be used that allows one object to access another object if the value of the access level of the first object is not less than the integrity level of the other. In the PSL specification language, integrity levels and access levels are defined for the mandatory integrity control model.

Thus, to set the integrity levels, an 'integrity' policy object is defined as an instance of
<IMG>.

The integrity policy object configuration will define three levels of integrity: LOW, MEDIUM, and HIGH, in ascending order. That is, LOW < MEDIUM < HIGH.

Policies based on object capability model (mandatory references) are based on the principle of minimum privileges. This principle of organization of access to resources implies that only privileges that are absolutely necessary for the successful completion of a task are provided to the subject (process or user). For example, a user who wants to find out the contents of a file should only be granted read permission for that file and only for the duration of the use of that file.

To define security policies based on temporal logic, security properties (requirements) are formulated based on a temporal logic formula and using temporal operators. Using the security monitor <NUM>, the OS architecture objects <NUM> involved in the passing of the message <NUM>, such as the processes <NUM>-<NUM>, are mapped to their state events from a predefined set of events.

As an example, the application of security policies based on temporal logic to the software installation process from a software image will be considered. Several components (which are the processes <NUM>-<NUM>), such as the verification tool and the installation tool, may be involved in the installation process. The software installation process may include verifying the integrity of the software image by the verification tool and then installing the software from the software image by the installation tool if the integrity of the software image is not compromised. The integrity of the software image determines the consistency, completeness, and integrity of the software image data. The integrity of the software image can be verified by validating the electronic digital signature. For the aforementioned 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 verifying the integrity of the software image, and apply is the event of installing the software from the software image. The security properties are formulated, for example, as follows:.

Property <NUM>. Whenever a software image integrity verification is performed, it must be ensured that after the software image integrity verification process, the software image in question will not be changed.

This property can be written as the formula: <MAT> where G is the temporal operator "always in the future", P is the temporal operator "at least once in the past".

Property <NUM> means that whenever the integrity of the software image has been verified in the past, it must be ensured that no further data is written to the software image.

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

The construction of a policy class object that implements access control based on temporal logic can be implemented in the PSL language as the following structure:
<IMG>.

It is worth noting that other formulations of the properties are also possible. For example, property <NUM> can be defined as follows: the software image is not applied until the integrity of the software image has been confirmed:
!apply U verify,
where U is the temporal operator "until such time as the specified event occurs".

A policy based on a temporal logic model when installing the software associates the apply event with this inter-process communication and verifies the truth of the formula specified in the policy object configuration. If the formula is true, the policy allows the communication, and if false it denies it.

Policies based on a discrete event model are defined using the verification module <NUM> corresponding to the policies. These security policies may also be described in the PSL specification language. These security policies may be applied to development systems that contain a large number of components. For the system mentioned above, the model with discrete events is a resultant finite state machine which is defined by a combination of a set of finite state machines, each of which describes a separate component of the system. For each finite state machine, the set of its states and transitions between them are indicated when certain events occur. The state of the resultant finite state machine is determined by a combination of the states of the finite state machines of the system components. In this case, the specified combination is implemented, for example, by a synchronous or asynchronous production of finite state machines. For the resultant finite state machine, a list of allowed transitions, a list of allowed states, and a list of prohibited states of the resulting finite state machine are also specified. Accordingly, the security policies are used to verify the transition of the finite state machines of the system components and the resulting finite state machine into the initial state defined in the configuration of the corresponding finite state machine, the transition between states on the occurrence of a specific event, the occupation of one of the defined states by the corresponding finite state machine.

In another example, different configuration tools <NUM> are selected for the security policies that use the different models. For example, the security policies may be combined into policy classes. A security policy class is a set of semantically linked policies that implement a specific security policy model. A first class of policies may consist of security policies that use a finite state machine, and a second class of policies may consist of security policies that use mandatory integrity control. In this example, configuration tool <NUM> may be selected for security policies from the first class, while configuration tool <NUM> may be selected for security policies from the second class. The examples described will allow configuration tools <NUM> to be developed that are designed to configure verification modules <NUM> for security policies from a single class. In addition, when adding a new security policy to the policy database <NUM>, the existing configuration tool <NUM> may be used without the need to redesign the configuration tool <NUM> or to add a new configuration tool <NUM>.

In another example, using the generating tool <NUM>, the security monitor <NUM> may additionally include a security monitor context <NUM>, wherein the security monitor <NUM> monitors the delivery of the messages <NUM> additionally taking account of the context <NUM>, where the security monitor context <NUM> contains the values of the security policy parameters.

In another example, the security monitor is additionally designed to change the context <NUM> to take into account the decisions <NUM> that are made based on the security policies. Depending on these models used by the security policies, the context <NUM> may contain different security policy parameters. For example, for security policies based on the mandatory integrity control model, the context <NUM> may contain values for integrity levels and access levels to the protected resources. For security policies based on a finite state machine, the context <NUM> may contain the current value of the state of the finite state machine and the transition table of the finite state machine.

In one example, if the message <NUM> complies with at least two security policies, an overall decision for the security policies in question may additionally be calculated by conjoining the decisions for each of these security policies, wherein the security monitor <NUM> monitors the delivery of the messages <NUM> additionally taking account of this general decision. When the process <NUM> or process <NUM> initiates a communication by sending the message <NUM>, the security monitor <NUM> invokes all security policies from the policy database <NUM> associated with that particular communication. If all security policies have issued an "allowed" decision, then the security monitor <NUM> issues an overall "allowed" decision. If at least one policy has issued a "prohibited" decision, however, the security monitor <NUM> issues the overall decision of "prohibited".

In another example, the configuration of the verification module <NUM> involves the creation of code to issue the decision <NUM> at the request of the security monitor <NUM> for a security policy when implementing the security policy.

In one example, the security monitor <NUM> monitors the delivery of the message <NUM> additionally taking account of the decisions <NUM> based on the security policies related to the messages <NUM> in question.

<FIG> illustrates an exemplary system <NUM> for monitoring the delivery of inter-process communication messages passed between the first <NUM> and the second <NUM> processes. To monitor the delivery of messages <NUM> passed between the first <NUM> and the second <NUM> processes, the security monitor generating system <NUM> (<FIG>) can be used to generate the security monitor <NUM> for the first OS <NUM>. In this way, the system for monitoring the delivery of messages <NUM> uses the security monitor generating system <NUM> and additionally includes a process creation tool <NUM> and a policy assignment tool <NUM>.

It is worth noting that the tools and modules described, in particular, the configuration tool <NUM>, the generating tool <NUM>, the development tool <NUM>, the process creation tool <NUM>, and the policy assignment tool <NUM> are implemented with the ability to run on the processor of the computer (see <FIG>). In this case, the policy database <NUM>, the architecture of the first OS <NUM>, and the verification modules <NUM> are contained in the memory of the computer.

The process creation tool <NUM> is designed to create a proxy process <NUM> for the second process <NUM>, where the proxy process <NUM> is designed to exchange messages <NUM> with the second process <NUM> on the second OS <NUM> and has a programming interface corresponding to the programming interface of the second process <NUM>. The process creation tool <NUM> receives information about the second process <NUM>, in particular its programming interfaces, from the development tool <NUM>.

Thus, information about the first process created <NUM>, which communicates with the second process <NUM> on the second OS <NUM>, may be added to the architecture of the first OS <NUM> by the process creation tool <NUM>. The policy assignment tool <NUM> is designed to assign security policies to the created proxy process <NUM> for monitoring the delivery of messages <NUM> associated with the proxy process <NUM>, where these messages <NUM> are passed through a defined programming interface. The security policies assigned to the proxy process <NUM> may be stored in the policy database <NUM>. Once generated, the security monitor <NUM> may perform monitoring of the delivery of messages <NUM> between the first <NUM> and the second <NUM> processes, including messages <NUM> associated with the aforementioned proxy process <NUM>, and the aforementioned monitoring is performed based on the security policy assigned by the policy assignment tool <NUM>.

In one example, when monitoring the delivery of messages <NUM> the security monitor <NUM> uses the programming interface of the proxy process <NUM> to determine the allowed messages <NUM> for the proxy process <NUM>. At the same time, the policy assignment tool <NUM> is used to define a security policy that prohibits the delivery of messages <NUM> from the proxy process <NUM> if an attempt has been detected to deliver messages <NUM> that are not in the allowed list. The list of allowed messages <NUM> and the associated security policies are pre-defined using the policy assignment tool <NUM> when generating the security monitor <NUM>. In another example, when monitoring the delivery of messages <NUM>, the security monitor <NUM> uses the programming interface of the proxy process <NUM> to determine the list of processes which are allowed to exchange messages <NUM> with the proxy process <NUM>. The list of processes includes at least the first process <NUM>. The policy assignment tool <NUM> also assigns a security policy that prevents the exchange of messages <NUM> between the proxy process <NUM> and processes that are not on the aforementioned list. Valid structures of allowed messages <NUM> may be defined using a declarative description of the second process interface <NUM>. These structures may contain the size of the message <NUM>, valid arguments and other valid parameters of the message <NUM>.

Thus, to implement inter-process communications of the second process <NUM> with the first process <NUM> using the method of the present disclosure, a proxy process <NUM> is created. The proxy process <NUM> implements all the programming interfaces of the second process <NUM>. Security policies are assigned for the created proxy process <NUM> for monitoring the delivery of messages <NUM> between the second <NUM> and the first <NUM> processes via the allowed interfaces. The system of the present disclosure allows the security monitor <NUM> to monitor the delivery of messages <NUM> between the second <NUM> and the first <NUM> processes by monitoring the delivery of messages <NUM> associated with the aforementioned proxy process <NUM>, taking into account the security policy, even despite the presence of an insecure communication channel <NUM>. As a result of this, the technical problem described in the present disclosure is addressed.

In another example, for the processes <NUM> and <NUM> of the second OS <NUM>, between which there is a software interface for exchanging messages <NUM>, the process creation tool <NUM> is used to create a single proxy process <NUM> common to both of the aforementioned processes <NUM> and <NUM>. It is worth noting that if the processes <NUM>-<NUM> are not linked to each other, that is, they are separate security domains, then a separate proxy process will be created for each one. For example, for the second process <NUM> a proxy process <NUM> will be created for communication with the first process <NUM>. And for the third process <NUM>, another proxy process (not shown in the figure) will be created for communication with another process (not shown in the figure) in the first OS <NUM>.

In one example, the second OS <NUM> is one of:.

In one example, when the second process <NUM> contains more than one execution thread, for each thread in the second process <NUM>, a corresponding thread is created in the proxy process <NUM>. In this case, the thread of the second process <NUM>, which performs the exchange of inter-process communication messages, calls the driver method of the communication channel <NUM> (using system calls to I/O operations, such as ioctl), which in turn notifies the proxy process <NUM> that a thread must be created in the proxy process <NUM> to exchange inter-process communication messages between the process and the corresponding thread of the second process <NUM>. After completion of the exchange of messages <NUM> between the threads of the second process <NUM> and the proxy process <NUM>, the second process <NUM>, by calling the driver method of the communication channel <NUM>, notifies the proxy process <NUM> about the completion of the exchange of messages <NUM> with it. The proxy process <NUM> then terminates the execution of the corresponding thread in the proxy process <NUM>.

The communication channel <NUM> driver is designed to establish a communication channel <NUM> between the second process <NUM> and the proxy process <NUM>, to control the threads for the proxy process <NUM>, to implement the call(), recv(), reply() calls, wherein the programming interface of the proxy process <NUM> corresponds to the interface of the second process <NUM>, and also to deliver the messages <NUM> from the second process <NUM> to the corresponding thread of the proxy process <NUM>.

It is also worth noting that when creating proxy processes, for example, the proxy process <NUM>, a common proxy-process template may be used for different processes of the second OS <NUM>, but for different processes of the second OS <NUM> a software interface corresponding to the interface of the second process <NUM> will be implemented in the corresponding proxy process. Thus, the use of a common proxy-process template increases the security of the claimed invention by allowing the possibility of a more detailed verification of the code of the specified template, as well as the use of common security policies. However, although some security policies may be the same for different processes in the second OS <NUM>, some of the security policies may be different.

<FIG> illustrates an exemplary of a guest OS (second OS <NUM>) running on a virtual machine under control of a first OS <NUM> on a computer system (an example of a general-purpose computer <NUM> is illustrated in <FIG>). The first OS <NUM> has a hypervisor <NUM> installed, which is a module (service) of the OS kernel <NUM> and controls the virtual machines <NUM>-<NUM>. The aforementioned virtual machines <NUM>-<NUM> are applications of the first OS <NUM>, which run in the user space on the processor of the computer. The hypervisor <NUM> may use any known virtualization solution to operate the virtual machines. An example of a hypervisor <NUM> is a Kaspersky Secure Hypervisor (KSH), a secure virtualization system based on the second type of hypervisor, where the first OS <NUM> (for example, KasperskyOS) acts as a host machine. In this case, the hypervisor <NUM> exports the component interface which uses the virtual machines <NUM>-<NUM> to manage the sessions, the virtual processors, memory, and low-level device polling. In addition to the virtual machines, other applications <NUM>-<NUM> may run on the first OS <NUM>. In one example, the aforementioned applications <NUM>-<NUM> and virtual machines <NUM>-<NUM> contain one process each, but may also be implemented using multiple processes and run on the processor of the computer.

In the context of a virtual machine application <NUM>, a virtual machine running a guest OS <NUM> is created, which then controls the operation of guest functional components that are implemented using guest processes and applications. As an example, the applications <NUM>-<NUM> are created in the guest OS <NUM>, divided over two security domains <NUM>-<NUM>. In general, the functional components of the guest OS <NUM> run in different security domains, with the guest OS <NUM> providing isolation of these security domains and the hypervisor <NUM> providing isolation of the guest OS <NUM> from the virtual machines represented by the applications <NUM>-<NUM>. Similarly, in the context of the virtual machine application <NUM> a virtual machine with guest OS <NUM> is created.

The delivery of messages <NUM> for inter-process communication from the various security domains <NUM>-<NUM> of the guest OS <NUM> and also from the virtual machine application <NUM>, which is a separate security domain, are monitored by the security monitor <NUM> of the first OS <NUM> independently using the proxy processes created for each security domain. Similarly, the security monitor <NUM> monitors the delivery of messages <NUM> from the virtual machine application <NUM> and from the security domains <NUM>-<NUM> of the guest OS <NUM>. In this case, the virtual machine <NUM> monitors the communication between the security domains <NUM>-<NUM> within the guest OS <NUM>, monitors its own security policies within the virtual machine <NUM>, controls access to the guest OS <NUM> hardware, data flows for the emulated devices, and other communications within the guest OS <NUM>.

The communications monitored by the security module <NUM> are indicated in <FIG> by a solid line with arrows. The communications that are not monitored by the security monitor <NUM> are indicated in <FIG> by a dashed line - for example, communications between the hypervisor <NUM> and the virtual machines <NUM>-<NUM> that require the privileged mode of the OS kernel <NUM>, which cannot be implemented in user mode in applications of the virtual machines <NUM>-<NUM>. In this case, the communications between the different virtual machines <NUM>-<NUM> are also monitored by the security monitor <NUM>.

<FIG> illustrates an exemplary of creating a proxy process for a virtual machine <NUM> and security domains for the guest OS (the second OS <NUM>). For example, the proxy process <NUM> may be created for the security domain <NUM> and the proxy process <NUM> may be created for the security domain <NUM>. The created proxy processes <NUM>-<NUM> communicate with other processes of the first OS <NUM> using inter-process communication messages <NUM>. The delivery of the inter-process communication messages is monitored by the security monitor <NUM>. The virtual machine <NUM>, as a separate security domain and as a process of the first OS <NUM>, communicates with other processes of the first OS <NUM> via the messages <NUM>, the delivery of which is also monitored by the security monitor <NUM>. In other words, the virtual machine <NUM> does not require a separate proxy process to be created. It is also worth noting that the created proxy processes <NUM>-<NUM> will have programming interfaces that correspond to the programming interfaces of the security domain <NUM> and the security domain <NUM> respectively.

As described earlier, the messages <NUM> are sent and received by the processes of the first OS <NUM> using system calls to the OS kernel <NUM> and via the defined programming interfaces.

The system calls may include the following:.

To identify the recipient and the sender of the messages <NUM> in the guest OS <NUM>, unique identifiers are used. The values of the unique identifiers are equal to the values of the process descriptors used by the proxy processes <NUM>-<NUM> for exchanging the messages <NUM> in the first OS <NUM>.

In one example, the messages <NUM> generated by the second process as well as other processes of the guest OS <NUM> (in this example, security domains <NUM>-<NUM> and the virtual machine application <NUM>) are represented in the format of the messages <NUM> passed in the first OS <NUM>. In this case, the corresponding proxy processes <NUM>-<NUM>, having received messages <NUM> from the processes of the guest OS <NUM>, being the second OS <NUM> (security domains <NUM>-<NUM>), perform the subsequent sending of messages <NUM> to the corresponding processes <NUM>-<NUM> of the first OS <NUM> without modification. In another example, when the format of messages <NUM> from the processes of the second OS <NUM> differs from the format of the messages <NUM>, the proxy process may convert the messages <NUM> from the processes of the second OS <NUM> into the format of the messages <NUM>.

When a second process, such as the security domain <NUM> in the guest OS <NUM>, accesses the process <NUM> of the first OS <NUM>, the security domain <NUM> receives a process descriptor <NUM> and sends a message <NUM> to the proxy process <NUM> via the communication channel <NUM> (remote call to call()). The security domain <NUM> then transitions to a sleep state until the reply() message is received from the proxy process <NUM>. The proxy process <NUM>, having received the specified message, converts the received specified message into the message <NUM> and sends the message <NUM> to the process <NUM> using a system call of the OS kernel <NUM>. The delivery of the message <NUM> is then monitored by the security monitor <NUM> using the security policies assigned to the proxy process <NUM> and the process <NUM>. Messages <NUM> from the process <NUM> to the security domain <NUM> are sent in a similar way using the proxy process <NUM> under the control of the security monitor <NUM>. After receiving the message <NUM>, the security domain <NUM> wakes up from the sleep state and terminates the invocation of call().

It is worth noting that this communication is carried out via the programming interfaces of the security domain <NUM> and the corresponding software interface of the proxy process <NUM>. The programming interface of security domain <NUM> receives a set of descriptors required for exchanging messages <NUM>. The values of set of descriptors required for exchanging messages <NUM> correspond to the descriptors of the proxy process <NUM>. The execution thread of the security domain <NUM> uses the recv() call on the specified interface to the proxy process <NUM>, after which the specified execution thread transitions to the sleep mode. A recv() call by the execution thread of the security domain <NUM> leads to a system call recv() by the kernel of the first OS <NUM>, which initiates the proxy process <NUM>. The proxy process <NUM> then also goes into the sleep mode. After the proxy process <NUM> receives the call to call() from the security domain <NUM> (for example, from another execution thread), the proxy process <NUM> wakes up from the sleep state, and the security domain <NUM> sends the data received earlier during the recv() call via the corresponding programming interface. The security domain <NUM> also wakes up from the sleep state and receives the data received in the recv() call from the proxy process <NUM>. The security domain <NUM> handles the call in the same thread that performed the recv() call and sends the data using the reply() call. The proxy process <NUM>, after receiving this data, sends the received data to the security domain <NUM>. To conduct multithreaded exchange of messages <NUM> between the second process (security domain <NUM>) and the proxy process <NUM>, a service thread of the proxy process is created for each thread of the second process.

In one example, the proxy-process interface may include the following calls:.

The event descriptors contain information about the event, including the type of 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, and so on. If there are no items in the event buffer, the wait for the event takes place in the event() call. If the event buffer contains elements, the event() call returns the descriptor from the specified buffer.

<FIG> illustrates a method <NUM> for monitoring delivery of messages <NUM> passed between first and second processes. For example, method <NUM> may monitor delivery of messages between the first process <NUM> and the second process <NUM>. Method <NUM> starts in step <NUM> and proceeds to step <NUM>.

In step <NUM>, using the process creation tool <NUM> for the second process <NUM>, method <NUM> creates a proxy process <NUM> in a first OS <NUM> for a second process, wherein the second process is from a second OS. For example, the created proxy process <NUM> is designed to exchange messages <NUM> with a second process <NUM> on the second OS <NUM>. In one example, the created proxy process <NUM> has a programming interface corresponding to a programming interface of the second process <NUM>.

In step <NUM>, using the policy assignment tool <NUM>, method <NUM> assigns at least one security policy to the created proxy process <NUM> for monitoring delivery of messages <NUM> associated with the created proxy process <NUM>, where the messages <NUM> are transmitted through the programming interface corresponding to a programming interface of the second process <NUM>.

In step <NUM>, for the first OS <NUM>, method <NUM> generates a security monitor <NUM> based on the created proxy process <NUM> and the security policies of the first OS <NUM>. The security requirements are expressed in the assigned security policies which are obtained from a policy database <NUM>. Thus, the security monitor <NUM> is based on features of the OS architecture <NUM>, which include at least the created proxy process <NUM> and the security requirements of the first OS <NUM>.

In step <NUM>, by the generated security monitor <NUM>, method <NUM> monitors the delivery of messages <NUM> between at least the first process <NUM> and the second process <NUM>, wherein the monitoring of the delivery of messages <NUM> associated with the proxy process <NUM> is based on the security policies obtained from the policy database <NUM>. It is worth noting that the particular aspects disclosed above also apply to the method shown in <FIG>.

<FIG> is a block diagram illustrating a computer system <NUM> on which examples of systems and methods for monitoring delivery of messages passed between first and second processes may be implemented. The computer system <NUM> can be in the form of multiple computing devices, or in the form of a single computing device, for example, a desktop computer, a notebook computer, a laptop computer, a mobile computing device, a smart phone, a tablet computer, a server, a mainframe, an embedded device, and other forms of computing devices.

As shown, the computer system <NUM> includes a central processing unit (CPU) <NUM>, a system memory <NUM>, and a system bus <NUM> connecting the various system components, including the memory associated with the central processing unit <NUM>. The system bus <NUM> may comprise a bus memory or bus memory controller, a peripheral bus, and a local bus that is able to interact with any other bus architecture. Examples of the buses may include PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I<NUM>C, and other suitable interconnects. The central processing unit <NUM> (also referred to as a processor) can include a single or multiple sets of processors having single or multiple cores. The processor <NUM> may execute one or more computer-executable code implementing the techniques of the present disclosure. The system memory <NUM> may be any memory for storing data used herein and/or computer programs that are executable by the processor <NUM>. The system memory <NUM> may include volatile memory such as a random access memory (RAM) <NUM> and non-volatile memory such as a read only memory (ROM) <NUM>, flash memory, etc., or any combination thereof. The basic input/output system (BIOS) <NUM> may store the basic procedures for transfer of information between elements of the computer system <NUM>, such as those at the time of loading the operating system with the use of the ROM <NUM>.

Computer readable program instructions for carrying out operations of the present disclosure may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language, and conventional procedural programming languages. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or the connection may be made to an external computer (for example, through the Internet). In some examples, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

In various examples, the systems and methods described in the present disclosure can be addressed in terms of modules. The term "module" as used herein refers to a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or FPGA, for example, or as a combination of hardware and software, such as by a microprocessor system and a set of instructions to implement the module's functionality, which (while being executed) transform the microprocessor system into a special-purpose device. A module may also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of a module may be executed on the processor of a computer system (such as the one described in greater detail in <FIG>, above). Accordingly, each module may be realized in a variety of suitable configurations, and should not be limited to any particular implementation exemplified herein.

Furthermore, it is to be understood that the phraseology or terminology used herein is for the purpose of description and not of restriction, such that the terminology or phraseology of the present specification is to be interpreted by the skilled in the art in light of the teachings and guidance presented herein, in combination with the knowledge of those skilled in the relevant art(s). Moreover, it is not intended for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such.

Claim 1:
A computer implemented method (<NUM>) for monitoring delivery of messages passed between processes from different operating systems, the method comprising:
creating (<NUM>) a proxy process in a first Operating System (OS) for a second process, wherein the second process is from a second OS, the first and second OS being installed in respective computing environments;
assigning (<NUM>) at least one security policy to the created proxy process for monitoring delivery of messages associated with the created proxy process, where the messages are transmitted through a programming interface of the created proxy process corresponding to a programming interface of the second process;
generating (<NUM>) a security monitor for the first OS based on the created proxy process and security policies of the first OS,
wherein the security monitor is generated by creating a code for the security monitor, the created code including at least one of: a source code, an intermediate code, and an executable code; and
monitoring (<NUM>) the delivery of messages between at least a first process in the first OS and the second process, wherein the monitoring of the delivery of messages associated with the proxy process is based on the security policies.