RU2773108C1 - System and method for forming a security monitor - Google Patents

Abstract

FIELD: information security.

SUBSTANCE: invention relates to the field of information security. According to the invention, security policies are analyzed, in particular, by determining the processes for which the corresponding security policy is used; security policies are selected and transmitted to the appropriate configuration tools; policy verification modules are configured; a security monitor is formed using the configured policy verification modules received from each configuration tool based on the analysis results, while the security monitor monitors message delivery taking into account the above-mentioned solution.

EFFECT: increase in OS security when exchanging interprocess communication messages transmitted by operating system (OS) application processes, and ensuring control over the delivery of interprocess communication messages transmitted by OS application processes in accordance with security policies.

20 cl, 6 dwg

Description

Область техникиTechnical field

Изобретение относится к области информационной безопасности.The invention relates to the field of information security.

Уровень техникиState of the art

Современные операционные системы (ОС) представляют собой сложные информационные системы (ИС) с множеством установленного программного обеспечения (ПО) для выполнения самого разнообразного функционала. При этом разработчики ПО ведут постоянную работу над исправлением ошибок и расширением функционала ПО. Тем не менее, такое количество и разнообразие ПО влечет за собой существенные риски информационной безопасности из-за наличия уязвимостей в ПО, а также из-за возможности несанкционированной установки вредоносного ПО. Первым уровнем защиты против упомянутых угроз являются встроенные в ОС средства защиты, а также особенности архитектуры ОС, потому что именно ОС предоставляет механизмы обработки и контроля межпроцессных взаимодействий (англ. inter-process communication, IPC), которые могут быть реализованы, в частности, путем обмена сообщений между процессами.Modern operating systems (OS) are complex information systems (IS) with a lot of installed software (SW) 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 security tools built into the OS, as well as the features of the OS architecture, because it is the OS that provides the mechanisms for processing and controlling inter-process communication (IPC), which can be implemented, in particular, by exchange of messages between processes.

Во многих популярных ОС (например, Windows 9x, Linux, Android и др.) используют монолитное ядро (англ. monolithic kernel), которое обладает рядом преимуществ, например простотой взаимодействия между драйверами и производительностью. Но из-за большого количества программных модулей ядра и, как следствия, высокой вероятности ошибок в коде обеспечение надежности и безопасности ОС с монолитным ядром затруднительно. Как следствие, при наличии уязвимости в ОС или в ПО некоторые нежелательные или вредоносные сообщения между процессами могут быть разрешены средствами обработки и контроля межпроцессных взаимодействий. Примером такого вредоносного сообщения между процессами может служить сообщение, содержащее запрос на доступ к защищенному участку памяти. Другим типом ядра ОС является микроядро (например, KasperskyOS, Symbian и др.), предоставляющее минимальный набор элементарных функций управления процессами и абстракций для работы с оборудованием. Для микроядерной (англ. microkernel) архитектуры ОС характерен небольшой размер микроядра и доверенной вычислительной базы. Это способствует более высокому уровню надежности и безопасности микроядерной архитектуры ОС, так как небольшой объем кода микроядра проще проверить на корректность. Но при этом такая архитектура ОС обладает, как правило, более низкой производительностью. Также существуют ОС с гибридными ядрами (англ. hybrid kernel, например MacOS X, Windows NT и др.), которые позволяют операционной системе использовать преимущества хорошо структурированной микроядерной архитектуры ОС, сохраняя при этом производительность монолитного ядра.Many popular operating systems (for example, Windows 9x, Linux, Android, etc.) use a monolithic kernel, which has several advantages, such as ease of interaction between drivers and performance. 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. As a result, if there is a vulnerability in the OS or software, some unwanted or malicious messages between processes can be resolved 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, KasperskyOS, Symbian, etc.), which provides a minimal set of elementary process control functions and abstractions for working with hardware. The 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 (eng. hybrid kernel, 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 a monolithic kernel.

Таким образом, для операционных систем существует актуальная задача обеспечения надежности и безопасности межпроцессных взаимодействий, реализованных путем обмена сообщений между процессами. Поэтому возникает техническая проблема, которая заключается в сложности осуществления контроля доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, на предмет соответствия политике безопасности.Thus, for operating systems, there is an urgent task of ensuring the reliability and security of interprocess communications implemented by exchanging messages between processes. Therefore, a technical problem arises, which lies in the difficulty of monitoring the delivery of interprocess communication messages transmitted by OS application processes for compliance with the security policy.

Из уровня техники известен патент US8234686B2, в котором описывают технологию создания политики безопасности криптографического модуля, после этого проверяют упомянутые политики на предмет их возможной подмены. Также известен патент US8650620B2, в котором описаны система и способ контроля запуска приложений на мобильном устройстве путем проверки сертификатов ЭЦП и с использованием мандатного контроля доступа.The patent US8234686B2 is known from the prior art, which describes the technology for creating a security policy for a cryptographic module, after which the mentioned policies are checked for their possible substitution. Also known is the patent US8650620B2, which describes a system and method for controlling the launch of applications on a mobile device by checking EDS certificates and using mandatory access control.

Тем не менее, известные технологии не позволяют решить заявленную техническую проблему, так как они не позволяют осуществить контроль доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, на предмет соответствия политике безопасности. Поэтому возникает необходимость в технологии, способной решить заявленную проблему.However, known technologies do not allow solving the claimed technical problem, since they do not allow controlling the delivery of interprocess communication messages transmitted by OS application processes for compliance with the security policy. Therefore, there is a need for a technology that can solve the stated problem.

Раскрытие сущности изобретенияDisclosure of the essence of the invention

Первый технический результат заключается в повышении безопасности ОС при обмене сообщениями межпроцессного взаимодействия, передаваемыми процессами приложений ОС за счет формирования монитора безопасности, предназначенного для контроля доставки сообщений с использованием политик безопасности.The first technical result is to improve OS security when exchanging interprocess communication messages transmitted by OS application processes by forming a security monitor designed to control message delivery using security policies.

Второй технический результат заключается в обеспечении контроля доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, в соответствии с политиками безопасности путем формирования монитора безопасности, обеспечивающего упомянутый контроль.The second technical result consists in providing control over the delivery of interprocess communication messages transmitted by OS application processes in accordance with security policies by forming a security monitor that provides the above control.

Согласно варианту реализации используется система формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), при этом указанная система содержит: базу политик, предназначенную для хранения политик безопасности для контроля доставки сообщений; по меньшей мере одно средство настройки, предназначенное для настройки модуля проверки политик на основании полученных от средства формирования политик безопасности, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности; средство формирования, предназначенное для: анализа политик безопасности из базы политик, где анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности; выбора политик безопасности из базы политик для соответствующих средств настройки; передачи по меньшей мере одной политики безопасности соответствующему средству настройки; формирования монитора безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения.According to an implementation variant, a system for generating a security monitor is used to control the delivery of interprocess communication messages (hereinafter - messages) transmitted by application processes of the operating system (hereinafter - OS), while this system contains: a policy base designed to store security policies for delivery control messages; at least one configuration tool for configuring the policy checker based on the policy checker received from the security policy generator, where the policy checker is for making a decision on the message delivery control method (hereinafter referred to as the decision) upon request of the security monitor when executing the security policy; a generation tool for: analysis of security policies from the policy base, where the analysis consists, in particular, in determining the processes for which the corresponding security policy is used; selecting security policies from the policy base for the appropriate configuration tools; transmitting at least one security policy to a corresponding configuration tool; generating a security monitor using the customized policy checkers received from each configuration tool based on the results of the analysis, while the security monitor controls the delivery of the message, taking into account the mentioned solution.

Согласно одному из частных вариантов реализации контроль доставки сообщения включает разрешение или запрет доставки сообщения.In one particular implementation, message delivery control includes allowing or denying message delivery.

Согласно другому частному варианту реализации при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.According to another particular implementation variant, said analysis takes into account the objects of the OS architecture, including the mentioned processes and applications.

Согласно еще одному частному варианту реализации сообщения включают: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.According to another particular embodiment, the messages include: a request to start a process, a request and response to interprocess communication, a process request to a security monitor.

Согласно одному из частных вариантов реализации объекты архитектуры ОС дополнительно включают: предоставляющий сервис процесс, который включает по меньшей мере один программный компонент, предназначенный для реализации программного интерфейса упомянутого процесса, при этом взаимодействие с упомянутым процессом происходит посредством упомянутого интерфейса; перечень программных интерфейсов для каждого процесса; при этом межпроцессное взаимодействие осуществляется с использованием упомянутых интерфейсов процессов.According to one particular implementation, the OS architecture objects further include: a service-providing process that includes at least one software component designed to implement a programming interface of said process, wherein interaction with said process occurs through said interface; a list of software interfaces for each process; wherein the inter-process communication is carried out using the mentioned process interfaces.

Согласно другому частному варианту реализации формируют монитор безопасности путем создания кода монитора безопасности, включающего один из: исходный код, промежуточный код, исполняемый код.According to another particular implementation variant, a security monitor is formed by creating a security monitor code, including one of: source code, intermediate code, executable code.

Согласно еще одному частному варианту реализации упомянутый анализ включает по меньшей мере один из: лексический анализ, синтаксический анализ, семантический анализ.According to another particular implementation variant, said analysis includes at least one of: lexical analysis, syntactic analysis, semantic analysis.

Согласно одному из частных вариантов реализации выполняют синтаксический анализ путем построения синтаксического дерева для кода монитора безопасности, при этом включают в синтаксическое дерево код модулей проверки политик, сформированных по меньшей мере одним средством настройки.According to one of the particular implementation options, parsing is performed by building a syntax tree for the security monitor code, while including in the syntax tree the code of policy checkers generated by at least one configuration tool.

Согласно другому частному варианту реализации политики безопасности используют по меньшей мере одну из следующих моделей: базовые операции; конечный автомат; временной автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события; мандатные ссылки; темпоральная логика.According to another particular embodiment 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; mandate links; temporal logic.

Согласно еще одному частному варианту реализации для политик безопасности, использующих различные модели, выбирают различные средства настройки.According to another particular implementation, different configuration tools are selected for security policies using different models.

Согласно одному из частных вариантов реализации с использованием средства формирования дополнительно включают в монитор безопасности контекст монитора безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого контекста, где контекст монитора безопасности содержит значения параметров политик безопасности.According to one of the private implementation options, using the generation tool, the context of the security monitor is additionally included in the security monitor, while the security monitor controls the delivery of the message additionally taking into account the mentioned context, where the security monitor context contains the values of security policy settings.

Согласно другому частному варианту реализации монитор безопасности дополнительно предназначен для изменения упомянутого контекста с учетом упомянутых решений.According to another particular implementation variant, the security monitor is further designed to change the said context, taking into account the mentioned decisions.

Согласно еще одному частному варианту реализации в случае, если сообщению соответствуют по меньшей мере две политики безопасности, дополнительно с использованием монитора безопасности выносят общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого общего решения.According to another particular implementation variant, if the message corresponds to at least two security policies, additionally using the security monitor, a general decision is made for the mentioned security policies by conjuncting decisions for each of the mentioned security policies, while the security monitor monitors the delivery of the message additionally taking into account the mentioned general solution.

Согласно одному из частных вариантов реализации настройка модуля проверки политик включает создание кода, обеспечивающего вычисление решения по запросу монитора безопасности для политики безопасности при выполнении упомянутой политики безопасности.In one particular implementation, customizing the policy checker includes creating code that computes a security monitor decision for a security policy when said security policy is executed.

Согласно другому частному варианту реализации монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутых решений.According to another particular implementation variant, the security monitor controls the delivery of the message in addition, taking into account the mentioned solutions.

Согласно еще одному частному варианту реализации система дополнительно включает сервис аудита, предназначенный для записи в журнал результатов контроля доставки сообщений, при этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита.In another particular embodiment, the system further includes an audit service for logging the results of message delivery control, wherein the message delivery control further includes performing an audit using the audit service.

Согласно одному из частных вариантов реализации монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом статуса и текущего состояния аудита.According to one of the private implementation options, the security monitor controls the delivery of the message in addition, taking into account the status and current state of the audit.

Согласно варианту реализации используется способ формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), в котором: с помощью средства формирования анализируют политики безопасности из базы политик, где база политик предназначена для хранения политик безопасности для контроля доставки сообщений, при этом анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности; с помощью средства формирования выбирают политики безопасности из базы политик для соответствующих средств настройки; с помощью средства формирования передают по меньшей мере одну выбранную политику безопасности соответствующему средству настройки; с использованием упомянутых средств настройки выполняют настройку модулей проверки политик, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности; с помощью средства формирования формируют монитор безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения.According to an implementation variant, a method for generating a security monitor is used to control the delivery of interprocess communication messages (hereinafter referred to as messages) transmitted by application processes of the operating system (hereinafter referred to as OS), in which: using the generating tool, security policies are analyzed from the policy base, where the policy base designed to store security policies to control the delivery of messages, while the analysis consists, in particular, in determining the processes for which the corresponding security policy is used; using the generating tool, selecting security policies from the policy base for the corresponding configuration tools; using the generation tool, transmit at least one selected security policy to the corresponding configuration tool; using the above configuration tools, setting up policy check modules, where the policy check module is designed to make a decision on the method for controlling the delivery of a message (hereinafter referred to as the decision) at the request of the security monitor when executing the security policy; using the generation tool, a security monitor is formed using customized policy check modules received from each configuration tool, based on the results of the analysis, while the security monitor controls the delivery of the message, taking into account the mentioned solution.

Согласно одному из частных вариантов реализации контроль доставки сообщения включает разрешение или запрет доставки сообщения.In one particular implementation, message delivery control includes allowing or denying message delivery.

Согласно другому частному варианту реализации при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.According to another particular implementation variant, said analysis takes into account the objects of the OS architecture, including the mentioned processes and applications.

Краткое описание чертежей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:

На Фиг. 1а-1в представлены схемы межпроцессного взаимодействия с использованием монитора безопасности на примере операционной системы с микроядерной архитектурой.On FIG. Figures 1a-1c show diagrams of inter-process communication using a security monitor using an operating system with a microkernel architecture as an example.

На Фиг. 2 представлена система формирования монитора безопасности.On FIG. 2 shows the security monitor generation system.

На Фиг. 3 представлен способ формирования монитора безопасности.On FIG. 3 shows a method for generating a security monitor.

Фиг. 4 представляет пример компьютерной системы общего назначения. Fig. 4 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) - последовательность операций при выполнении программы или ее части вместе с используемыми данными, включает один или более потоков (англ. thread) и ассоциированные с ними системные ресурсы.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) - набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов.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 asynchronous process is a process in which an operation does not require a response to continue execution.

Синхронный процесс - процесс, в котором операция требует отклика для продолжения выполнения.A synchronous process is a process in which an operation requires a response in order to continue execution.

Операция - элементарное действие, выполняемое в рамках рассматриваемого процесса (в качестве операции может выступать, например, API-функция).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.

Конечный автомат (англ. Finite State Machine, FSM) - модель дискретного устройства, характеризующаяся состояниями и переходами от одного состояния к другому. Каждое состояние конечного автомата характеризует одну из возможных ситуаций, в которой может находиться конечный автомат.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.

На Фиг. 1а-1в представлены схемы межпроцессного взаимодействия с использованием монитора безопасности 120 на примере операционной системы (ОС) 100 с микроядерной архитектурой. Представленная на Фиг. 1а ОС 100 включает изолированные процессы 131-132 приложений ОС 100, которые взаимодействуют между собой (IPC), а также с ядром ОС 110 посредством программных интерфейсов путем обмена сообщений 140 (также сообщения межпроцессного взаимодействия, IPC-сообщения, на фигуре обозначены стрелкой, начинающейся с точки). При этом упомянутые интерфейсы, реализуемые процессами, статически описаны, а разрешенные взаимодействия между процессами заданы заранее.On FIG. 1a-1c are diagrams of inter-process communication using security monitor 120 using an operating system (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 communicate with each other (IPC) as well as with the OS kernel 110 through programmatic interfaces by exchanging messages 140 (also inter-process communication messages, IPC messages, in the figure are indicated by an arrow starting from a dot). In this case, the mentioned interfaces implemented by the processes are statically described, and the allowed interactions between the processes are predetermined.

Отправка и получение сообщений процессами 131-132 происходят посредством системных вызовов ядра ОС 110.The sending and receiving of messages by processes 131 - 132 occur through OS kernel system calls 110 .

Системные вызовы могут включать следующие:System calls may include the following:

call() - используется процессом 131 для отправки запроса 142 к процессу 132 и получения ответа 143 на осуществление межпроцессного взаимодействия;call() - used by process 131 to send a request 142 to process 132 and receive a response 143 for inter-process communication;

recv() - используется процессом 132 для получения запроса 142;recv() - used by process 132 to receive request 142 ;

reply() - используется процессом 132 для отправки ответа 143 процессу 131.reply() - used by process 132 to send a reply 143 to process 131 .

Монитор безопасности 120 - компонент ОС 100, предназначенный для осуществления контроля доставки упомянутых сообщений 140. Сообщения 140 включают следующие: запрос на запуск 141 процесса 131, запрос 142 от процесса 131 или ответ 143 от другого процесса 132 (например, вызов процессом 131 метода процесса 132), запрос процесса 132 к монитору безопасности 120 (запрос безопасности 144). Также сообщения 140 могут включать уведомление об ошибке от ядра ОС 110 в ответ на сообщения от процессов 131-132. С использованием монитора безопасности 120 осуществляют контроль доставки сообщений 140 с учетом решений 150, принятых на основании политик безопасности из базы политик 121. Контроль доставки сообщения 140 включает разрешение или запрет доставки сообщения 140 и, соответственно, разрешение или запрет выполнения взаимодействия, осуществляющегося с использованием указанного сообщения 140. Решение 150 о способе контроля доставки сообщения 140 указывает на разрешение или запрет на передачу сообщения 140 при выполнении политики безопасности. Решение 150 используется монитором безопасности 120 или его компонентами для осуществления упомянутого контроля доставки сообщений 140 (см. Фиг. 2). На основании политик безопасности могут выносить решение 150 с использованием данных сообщения 140 (например, имя запускаемого процесса или фактические аргументы вызываемого метода процесса).The security monitor 120 is a component of the OS 100 designed to monitor the delivery of said messages 140 . 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 ). Also, messages 140 may include an error notification from the OS kernel 110 in response to messages from processes 131-132 . 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 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. 2 ). Based on the security policies, 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).

Также решение 150 о способе контроля доставки сообщения 140 может зависеть от корректности структуры упомянутого сообщения 140. Таким образом, если сообщение 140 имеет недопустимую структуру, передача указанного сообщения 140 может быть запрещена. В этом случае допустимые структуры сообщений могут быть определены с использованием декларативного описания интерфейса процесса-получателя сообщения. Упомянутая структура может содержать размер сообщения, допустимые аргументы и другие допустимые параметры сообщения.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 can be defined using the declarative description of the interface of the receiving process of the message. The referenced structure may contain the size of the message, valid arguments, and other valid message parameters.

В одном частном варианте реализации монитор безопасности 120 может быть частью ядра ОС 110 или отдельным приложением. В другом частном варианте реализации монитор безопасности 120 исполняется в привилегированном режиме ядра ОС 110.In one particular implementation, the security monitor 120 may be part of the OS kernel 110 or a separate application. In another particular implementation, the security monitor 120 runs in the privileged mode of the OS kernel 110 .

В частном варианте реализации ОС 100 дополнительно включает сервис аудита 133, предназначенный для записи в журнал результатов контроля доставки сообщений 140. При этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита 133. В еще одном частном варианте реализации монитор безопасности 120 осуществляет контроль доставки сообщений 140 дополнительно с учетом текущего статуса сервиса аудита 133. При этом упомянутый статус указывает на готовность сервиса аудита 133 принимать сообщения 140. Например, если процесс 131 выполняет запрос 142 к защищенному ресурсу (через процесс 132), где информация о доступе к защищенному ресурсу всегда должна быть записана в журнал, но при этом статус сервиса аудита 133 указывает на то, что сервис аудита 133 в данный момент не сохраняет сообщения, то такой запрос 142 будет запрещен монитором безопасности 120 согласно политике безопасности.In a particular implementation, OS 100 further includes an audit service 133 for logging the results of message delivery control 140 . At the same time, message delivery control 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 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, then such a request 142 will be denied by the security monitor 120 according to the security policy.

В еще одном частном варианте реализации ОС 100 содержит контекст 122 монитора безопасности 120, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого контекста 122, где контекст 122 содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста 122 с учетом решений 150 на основании политик безопасности. В частном варианте реализации политики безопасности используют модель конечного автомата, модель мандатного контроля целостности или другие модели для реализации политик безопасности. Подробнее об упомянутых моделях будет раскрыто далее. В зависимости от используемых политиками безопасности упомянутых моделей контекст 122 может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст 122 будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст 122 будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.In another particular implementation, the OS 100 contains a context 122 of the security monitor 120 , while the security monitor 120 monitors the delivery of the message 140 additionally taking into account the mentioned context 122 , where the context 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 . 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 disclosed below. Depending on the security policies of these models used, the 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.

На Фиг. 1б представлен пример доставки разрешенного запроса 142 от процесса 131 к процессу 132. Процесс 131 может вызвать метод интерфейса процесса 132, для этого процесс 131 отправляет запрос 142, содержащий входные аргументы вызываемого метода. Процесс 131 отправляет запрос 142 посредством ядра ОС 110, которое в свою очередь передает запрос 142 на проверку монитору безопасности 120. Монитор безопасности 120 выносит решение 150 «разрешено» на основании политик безопасности и передает указанное решение 150 ядру ОС 110. После этого ядро 110 на основании решения 150 передает запрос 142 далее процессу 132.On FIG. 1b shows an example of delivery of a resolved request 142 from process 131 to process 132 . Process 131 can call a process interface method 132 , for which 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 .

В рассматриваемом примере процесс 132 далее отправляет ответ 143 процессу 131, где ответ 143 содержит выходные аргументы вызываемого метода. Способ отправки ответа 143 аналогичен способу отправки запроса 142, но в обратном порядке, от процесса 132 к процессу 131. То есть, процесс 132 отправляет ответ 143 посредством ядра ОС 110, которое в свою очередь передает ответ 143 на проверку монитору безопасности 120. Монитор безопасности 120 выносит новое решение «разрешено» на основании политик безопасности и передает указанное новое решение обратно ядру ОС 110. После этого ядро 110 на основании нового решения передает ответ 143 далее процессу 131.In this example, process 132 then sends a response 143 to process 131 , where response 143 contains the output arguments of the method being called. The method of sending response 143 is similar to the method of 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 based on the security policies and sends the new decision back to the OS kernel 110 . After that, the core 110 passes the response 143 on to the process 131 based on the new decision.

На Фиг. 1в представлен пример запрещенного запроса 142 от процесса 131 к процессу 132. Процесс 131 отправляет запрос 142 посредством ядра ОС 110, которое в свою очередь передает запрос 142 на проверку монитору безопасности 120. Монитор безопасности 120 выносит решение 150 «запрещено» на основании политик безопасности и передает указанное решение 150 ядру ОС 110. После этого ядро 110 на основании решения 150 направляет уведомление об ошибке процессу 131. При этом запрос 142 не будет передан процессу 132.On FIG. 1c shows an example of a forbidden request 142 from process 131 to process 132 . 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 issues 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 .

На Фиг. 2 представлена система формирования монитора безопасности 200. Система формирования монитора безопасности 200 используется для повышения безопасности ОС 100 при обмене сообщениями 140, а также для обеспечения контроля доставки упомянутых сообщений 140 получателям. При этом монитор безопасности 120 может быть использован разработчиками ПО в различных операционных системах 100, а также в любых других компьютерных системах, в которых осуществляется обмен сообщениями, в частности в базах данных и в прикладном ПО. Пример такого использования был приведен ранее на Фиг. 1а-1в. Для каждой ОС 100 формируют монитор безопасности 120 с учетом особенностей архитектуры ОС 240, а также с учетом требований безопасности для данной ОС 100, которые выражаются в политиках безопасности. Стоит отметить, что для различных программных и программно-аппаратных систем разработчика на базе ОС 100 (далее - система разработчика) основные объекты архитектуры ОС 240 могут быть общими, например процессы, службы, приложения, драйверы, отвечающие за работу ядра ОС 110 и других компонентов ОС 260. В то же время, другие объекты архитектуры ОС 240, отвечающие за функциональность системы разработчика, будут различными для каждой из упомянутых систем. Следовательно, будут различаться и политики безопасности, с использованием которых осуществляется контроль доставки сообщений 140. Системы разработчика могут включать программное обеспечение, а также программно-аппаратные комплексы.On FIG. 2 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 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 features, as well as taking into account the security requirements for this OS 100 , which are expressed in security policies. It should be noted that for various software and hardware 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.

Система 200 содержит базу политик безопасности 121, предназначенную для хранения политик безопасности, необходимых для контроля доставки сообщений 140. Система 200 также содержит по меньшей мере одно средство настройки 220, которое предназначено для настройки соответствующего ему модуля проверки политик 221 на основании полученных от средства формирования 210 политик безопасности. Модуль проверки политик 221 предназначен для вынесения решения 150 о способе контроля доставки сообщения 140 (далее - решение) по запросу монитора безопасности 120 при выполнении политики безопасности. Система 200 также содержит описание архитектуры ОС 240, включающее такие объекты архитектуры ОС, как процессы и приложения ОС 100. В частном варианте реализации упомянутые объекты архитектуры ОС дополнительно включают объекты системы разработчика на базе ОС 100. В еще одном частном варианте реализации объекты архитектуры ОС дополнительно включают:The system 200 includes a security policy database 121 for storing the security policies needed to control the delivery of messages 140 . The system 200 also includes at least one configuration tool 220 which is configured to configure its corresponding policy checker 221 based on the security policy generator 210 received. The policy checking 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 a security policy. The system 200 also contains a description of the architecture of the OS 240 , including OS architecture objects such as processes and applications of the OS 100 . 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 a programming interface of said process, wherein 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 an event processing process );

перечень программных интерфейсов для каждого процесса. Также, могут быть указаны соответствующие методы интерфейсов, реализующие функционал соответствующего процесса.a list of programming interfaces for each process. Also, the corresponding interface methods 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. Where the resource is, specifically, a file, port, or process. For example, the file system is a resource driver, and the files themselves are resources that it can provide access to other processes.

Кроме того, система 200 содержит средство формирования 210, предназначенное для анализа политик безопасности, где анализ заключается, в частности, в определении процессов, для которых используется упомянутая политика безопасности. В частном варианте реализации при упомянутом анализе учитывают объекты архитектуры ОС 240, включающие упомянутые процессы и приложения. Средство формирования 210 также предназначено для выбора политик безопасности из базы политик 121 для соответствующих средств настройки 220 и для передачи по меньшей мере одной выбранной политики безопасности соответствующему средству настройки 220. Средство формирования 210 также предназначено для формирования монитора безопасности 120 с использованием настроенных модулей проверки политик 221, полученных от каждого средства настройки 220 на основании результатов анализа. В частном варианте реализации средство формирования 210 формирует монитор безопасности 120 путем создания кода монитора безопасности 120. При этом упомянутый код может быть исходным кодом, промежуточным кодом или исполняемым кодом. Кроме того, формирование кода монитора безопасности 120 также может включать оптимизацию кода, анализ кода на наличие ошибок. Таким образом, средство формирования 210 может быть компилятором, формирующим упомянутый код.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, said analysis takes into account OS architecture objects 240 that include said processes and applications. 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 respective customizer 220 . The builder 210 is also configured to build the security monitor 120 using the customized policy checkers 221 obtained 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, code analysis for errors. Thus, generator 210 may be a compiler that generates said code.

Архитектура ОС 240, база политик 121, а также средства настройки 220 могут быть настроены заранее с использованием средства разработки 250. Для этого средство разработки 250 может предоставлять набор API (англ. application programming interface - программный интерфейс приложения) или готовые модули для разработки ПО. В частном варианте реализации по меньшей мере часть объектов архитектуры ОС 240, часть политик безопасности из базы политик 121, а также часть средств настройки 220 могут быть общими (шаблонными) для различных ОС 100. В этом случае разработчик с использованием средств разработки 250 может настроить средства настройки 220, объекты архитектуры ОС 240 и политики безопасности из базы политик безопасности 121 путем добавления в упомянутый шаблон отсутствующих в шаблоне политик безопасности, объектов архитектуры ОС 240, а также средств настройки 220, необходимых для отражения особенностей ОС 100 или системы разработчика на базе ОС 100 и требований безопасности к ОС 100 или соответственно к системе разработчика на базе ОС 100, для которой упомянутый разработчик формирует монитор безопасности 120. Кроме того, часть данных из упомянутого шаблона может быть удалена, если она будет не нужна в ОС 100 или соответственно в системе разработчика на базе ОС 100. Например, могут быть удалены некоторые политики безопасности и приложения.The OS architecture 240 , the policy base 121 , as well as the configuration tools 220 can be configured in advance using the development tool 250 . To do this, the development tool 250 may provide a set of APIs (English application programming interface - application programming interface) or ready-made modules for software development. In a private implementation, at least part of the OS architecture objects 240 , part of the security policies from the policy base 121 , and also 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 , OS architecture objects 240 and security policies from the security policy database 121 by adding to the template the security policies missing in the template, the OS architecture objects 240 , as well as the configuration tools 220 required to reflect the features of the OS 100 or OS 100 developer's system and the security requirements for OS 100 or OS 100 developer's system, respectively, for which said developer is generating security monitor 120 . In addition, some 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.

Сформированный монитор безопасности 120 вместе с другими компонентами ОС 260 далее включают в операционную систему 100. При этом упомянутое включение монитора безопасности 120 и компонентов ОС 260 может быть осуществлено известными из уровня техники способами, например на этапе компиляции ОС 100 с использованием компилятора ОС 100 или путем установки монитора безопасности 120 в ОС 100. Как упоминалось ранее, монитор безопасности 120 может быть частью ядра ОС 110 или отдельным приложением ОС 100. Монитор безопасности 120 исполняется в привилегированном режиме ядра ОС 110. Для ОС 100 также может быть создан установочный образ ОС 270, необходимый для установки ОС 100 на компьютерные устройства конечных пользователей. Установочный образ ОС 270 может быть, например, архивом, исполняемым файлом или установочным пакетом. Установочный пакет представляет собой файл архива, в который входят файлы ОС 100, управляющие файлы и опционально файлы для настройки процесса установки ОС 110. Кроме того, в установочный пакет могут входить файлы системы разработчика на базе ОС 100. Упомянутые файлы могут быть представлены в исходном коде, в промежуточном коде или в исполняемом коде.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 the privileged mode of the OS kernel 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 in source code, in intermediate code, or in executable code.

На Фиг. 3 представлен способ формирования монитора безопасности 200. На шаге 310 с использованием средства формирования 210 анализируют политики безопасности из базы политик 121. Упомянутый анализ заключается, в частности, в сопоставлении политик безопасности 121 и объектов архитектуры ОС 240. Например, будут определены процессы, для которых используется упомянутая политика безопасности. Кроме того, могут быть выбраны лишь те политики безопасности 121, которые соответствуют существующим процессам в рамках архитектуры ОС 240 или системы разработчика на базе ОС 100. Далее на шаге 320 с использованием средства формирования 210 выполняют выбор политик безопасности из базы политик 121 для соответствующих средств настройки 220 и, на шаге 330, осуществляют передачу по меньшей мере одной выбранной политики безопасности соответствующему средству настройки 220. После этого на шаге 340 с использованием средств настройки 220 выполняют настройку модулей проверки политик 221. Упомянутая настройка заключается, в частности, в добавлении выбранных политик безопасности в модули проверки политик 221. В итоге на шаге 350 с использованием средства формирования 210 формируют монитор безопасности 120 с использованием настроенных модулей проверки политик 221 на основании результатов анализа.On FIG. 3 shows a method for generating a security monitor 200 . At step 310 , the security policies from the policy base 121 are parsed using generation tool 210 . Said analysis consists in particular in comparing security policies 121 and OS architecture objects 240. For example, the processes for which said security policy is used will be determined. In addition, only those security policies 121 that correspond to existing processes within the architecture of the OS 240 or the developer's system based on the OS 100 can be selected. Next, at step 320 , using generation tool 210 , a selection of security policies from policy base 121 for respective configuration tools 220 is performed and, at step 330 , at least one selected security policy is transmitted to the corresponding configuration tool 220 . Thereafter, at step 340 , the policy check modules 221 are configured using the configuration tools 220 . Said customization consists, in particular, in adding the selected security policies to the policy check modules 221 . As a result, at step 350 , using the generation tool 210 , the security monitor 120 is generated using the configured policy checkers 221 based on the results of the analysis.

Таким образом, заявленное изобретение позволяет решить заявленную техническую проблему и достичь заявленные технические результаты, а именно повысить безопасность ОС при обмене сообщениями межпроцессного взаимодействия, передаваемыми процессами приложений ОС за счет формирования монитора безопасности, предназначенного для контроля доставки сообщений с использованием политик безопасности, а также обеспечить контроль доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, в соответствии с политиками безопасности путем формирования монитора безопасности, обеспечивающего упомянутый контроль.Thus, the claimed invention allows solving the claimed technical problem and achieving the claimed technical results, namely, to increase the security of the OS when exchanging interprocess communication messages transmitted by the OS application processes by forming a security monitor designed to control the delivery of messages using security policies, and also to provide control of delivery of interprocess communication messages transmitted by OS application processes in accordance with security policies by forming a security monitor that provides said control.

В частном варианте реализации монитор безопасности 120 формируют путем создания кода монитора безопасности 120, где код может быть исходным кодом, промежуточным кодом или исполняемым кодом. В этом варианте реализации модули проверки политик 221 также являются участками кода, включаемыми в код монитора безопасности 120.In a particular implementation, the security monitor 120 is generated by generating code for the security monitor 120 , where the code can be source code, intermediate code, or executable code. In this implementation, the policy checkers 221 are also sections of code included in the code of the security monitor 120 .

Описание политик безопасности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 Event Systems, DES);discrete events (English Discrete Event Systems, DES);

мандатные ссылки;mandate links;

темпоральная логика (временнáя логика; англ. temporal logic).temporal logic (temporal logic; English temporal logic).

Политики безопасности 121 могут быть заданы с использованием языка спецификации, например PSL (англ. policy specification language). На примере PSL мандатный контроль целостности задан классом политик Mandatory_integrity_control. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в системе, которые могут быть реализованы путем обмена сообщений 140 между процессами. При каждой попытке взаимодействия, то есть при проверке монитором безопасности 120 сообщений 140, монитор безопасности 120 исполняет правила для определения решения о допустимости указанного взаимодействия (доставки сообщения 140). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.Security policies 121 may be defined using a specification language such as PSL (policy specification language). In the PSL example, the mandatory integrity control is specified 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.

В частном варианте реализации анализ политик безопасности и объектов архитектуры ОС 240 включает по меньшей мере один из следующих видов анализа: лексический анализ, синтаксический анализ, семантический анализ. В результате указанного анализа политик безопасности определяют объекты архитектуры ОС 240, в частности, процессы, участвующие в обмене сообщений 140, для которых применяется упомянутая политика безопасности. То есть будет определено соответствие между определенными объектами архитектуры ОС 240 и политикой безопасности, применяемой для указанных объектов. Например, если политика безопасности разрешает запрос 142 от процесса 131 к процессу 132, то в результате анализа этой политики безопасности будут определены указанные процессы 131-132 и информация о разрешенном запросе 142. Стоит отметить, что в результате указанного анализа политик безопасности могут дополнительно определить и другие объекты архитектуры ОС 240, которые проверяют в указанной политике безопасности, например, методы интерфейсов процесса, когда сообщение 140 адресовано указанному методу и будет передано по указанному интерфейсу процесса. В этом случае, политики безопасности будет проверять условие, что при обмене сообщениями 140 между определенными процессами используются заданные интерфейсы процессов и заданные методы интерфейсов.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 permits a request 142 from process 131 to process 132 , then parsing that security policy will identify the specified processes 131 - 132 and information about the permitted 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 policy will check the condition that when messages 140 are exchanged between certain processes, the specified process interfaces and specified interface methods are used.

На примере языка PSL, с использованием которого могут быть заданы политики безопасности 121, указание на процесс 131, являющийся источником запроса 142, может содержаться в переменной scr. Указание на процесс 132, являющийся получателем запроса 142 может содержаться в переменной dst. Соответственно, именно упомянутый анализ политики безопасности 121, написанной на языке PSL, позволит определить указанные объекты архитектуры ОС, для которых будет применяться указанная политика безопасности.In the example of PSL, which can be used to set security policies 121 , an indication of the process 131 that is the source of the request 142 can be contained 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 121 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.

В другом частном варианте реализации анализ политик безопасности 121 также включает проверку типов объектов архитектуры ОС 240, а также анализ на ошибки в политиках безопасности 121.In another particular implementation, the analysis of security policies 121 also includes checking the types of OS architecture objects 240 as well as analyzing for errors in security policies 121 .

Результаты упомянутого анализа учитываются при формировании монитора безопасности 120. Например, в мониторе безопасности 120 могут быть записаны условия применения политик безопасности - перечень объектов архитектуры ОС 240, в частности, процессов, и соответствующие указанному перечню политики безопасности, а также модули проверки политик 221. Поэтому, при получении от ядра ОС 110 сообщения 140, сформированный монитор безопасности 120 определяет объекты архитектуры ОС 240, участвующие в обмене сообщением 140, после чего определяет политики безопасности, применимые к указанным объектам архитектуры ОС 240. После чего монитор безопасности 120 передает сообщения 140 модулям проверки политик 221, соответствующим указанным политикам безопасности, для вынесения решения о способе контроля доставки сообщения 140.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 policy 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 messages 140 to policy checkers 221 corresponding to the specified security policies to decide how to control the delivery of the message 140 .

В еще одном частном варианте реализации выполняют синтаксический анализ путем построения синтаксического дерева для кода монитора безопасности 120, при этом включают в синтаксическое дерево код модулей проверки политик 221, сформированных по меньшей мере одним средством настройки 220.In yet another particular implementation, parsing is performed by constructing a parse tree for the security monitor code 120 , while including in the parse tree the code of policy checkers 221 generated by at least one configuration tool 220 .

Политики безопасности могут использовать базовые операции, разрешающие или запрещающие передачу сообщения 140 при условии совпадения параметров сообщения 140 (например, имя запускаемого процесса или фактические аргументы вызываемого метода) с данными, указанными в политике безопасности. Например, политика безопасности может определить, что процесс 131 может получать любые сообщения, но при этом процессу 131 запрещено отправлять сообщения.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, 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.

Модель временных автоматов (англ. Timed automata), и в частности временной автомат типа ERA (англ. Event-recording automata), является частным случаем конечных автоматов. В данной модели дополнительно для каждого сообщения задают параметр времени (таймер), равный времени с момента последнего получения этого сообщения. Например, переход из одного состояния конечного автомата в другое состояние может быть осуществлен, если сообщение было получено спустя время, определенное таймером.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, a time parameter (timer) is set equal to the time since the last receipt of this message. For example, the transition from one state of the state machine to another state can be performed if the message was received after the time specified by the timer.

Модель мандатного контроля целостности (англ. Mandatory integrity control) используется для разрешения или запрета доставки сообщения 140. Согласно модели мандатного контроля доступа, с использованием монитора безопасности 120 объектам архитектуры ОС 240, участвующим в передаче сообщения 140, например процессам 131-132, ставят в соответствие два числа, называемые уровнем целостности (англ. Integrity level) и уровнем доступа. При этом для разрешения доставки сообщения от одного объекта к другому используются политики безопасности на основе мандатного контроля целостности, то есть использующие значения уровней целостности и уровней доступа объектов. Например, может быть использована политика безопасности, согласно которой одному объекту разрешено обращаться к другому объекту, если значение уровня доступа первого объекта не ниже значения уровня целостности другого. На языке спецификаций PSL для модели мандатного контроля целостности задают уровни целостности и уровни доступа. Таким образом, для задания уровней целостности определяют объект политик integrity, являющийся экземпляром класса Mandatory_integrity_control:The Mandatory integrity control model is used to allow or deny message delivery 140 . According to the mandatory access control model, using the security monitor 120 objects of the OS architecture 240 participating in the transmission of the message 140 , for example, processes 131 - 132 , are assigned two numbers called the integrity level and the access level. At the same time, to allow message delivery 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 access level value of the first object is not lower than the integrity level value 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:

В конфигурации объекта политик integrity будут заданы три уровня целостности: LOW (низкий), MEDIUM (средний) и HIGH (высокий) - в порядке возрастания. То есть LOW < MEDIUM < HIGH.In the integrity policy object configuration, three integrity levels will be specified: LOW (low), MEDIUM (medium) and HIGH (high) - in ascending order. That is, LOW < MEDIUM < HIGH.

В основе политик на основе мандатных ссылок (англ. object capability model) лежит принцип минимальных привилегий. Этот принцип организации доступа к ресурсам подразумевает предоставление субъекту (процессу или пользователю) только тех привилегий, которые являются абсолютно необходимыми для успешного выполнения задачи. Например, пользователю, который хочет ознакомиться с содержимым файла, должны быть выданы только права на чтение этого файла и только на период использования этого файла.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 see the contents of a file should only be granted read access to the file, and only for the duration of the file's use.

Для задания политик безопасности на основе темпоральной логики формулируют свойства (требования) безопасности с помощью формулы темпоральной логики и с использованием темпоральных операторов. С использованием монитора безопасности 120 объектам архитектуры ОС 240, участвующим в передаче сообщения 140, например процессам 131-132, ставят в соответствие события их состояния из заранее определенного множества событий.To set security policies based on temporal logic, security properties (requirements) are formulated using the 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.

В качестве примера рассматривается применение политик безопасности на основе темпоральной логики для процесса установки ПО из образа ПО. В процессе установки могут участвовать несколько компонентов (являющихся процессами 131-132), например средство проверки и средство установки. Процесс установки ПО может включать проверку целостности образа ПО средством проверки и последующую установку ПО из образа ПО средством установки в случае, если целостность образа ПО не нарушена. Целостность образа ПО определяет непротиворечивость, полнота и сохранность данных образа ПО. Проверка целостности образа ПО может быть осуществлена путем проверки электронно-цифровой подписи. Для упомянутого образа ПО множество событий может включать следующие: {seal, verify, apply}, где seal - событие «запечатывания» образа ПО, verify - событие проверки целостности образа ПО, apply - событие установки ПО из образа ПО. Свойства безопасности формулируют, например, следующим образом: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 may 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:

Свойство 1. Всегда, когда выполняется проверка целостности образа ПО, должно быть гарантировано, что после процесса проверки целостности образа ПО упомянутый образ ПО не будет изменен. Данное свойство можно записать в виде формулы: 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),G (verify => P seal),

где G - темпоральный оператор «всегда в будущем», P - темпоральный оператор «хотя бы один раз в прошлом». Свойство 1 означает, что всегда, когда осуществляется проверка целостности образа ПО в прошлом, должна быть гарантирована невозможность дальнейшей записи данных в образ ПО.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.

Свойство 2. Установка ПО из образа ПО возможна только в том случае, если подтверждена целостность образа ПО. Данное свойство можно записать в виде формулы: Feature 2: Installing software from a software image is possible only if the integrity of the software image is verified. This property can be written as a formula:

G (apply => P verify).G (apply => P verify).

Создание объекта класса политик, реализующего управление доступом на основе темпоральной логики, может быть реализовано на языке PSL в виде следующей конструкции:Creating a policy class object that implements access control based on temporal logic can be implemented in PSL as the following construct:

Стоит отметить, что возможны и другие формулировки свойств. Например, свойство 2 может быть задано следующим образом: образ ПО не применяется, пока не подтверждена целостность образа ПО: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,!apply U verify,

где U - темпоральный оператор «до тех пор, пока не наступит заданное событие».where U is the temporal operator "until the given event occurs".

Политика на основе модели темпоральной логики при установке ПО связывает с данным межпроцессным взаимодействием событие apply и проверяет истинность формулы, указанной в конфигурации объекта политик. Если формула истинна, политика разрешает взаимодействие, если ложна - запрещает.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.

Политики на основе модели с дискретными событиями задают с использованием соответствующего политикам модуля проверки 221. Упомянутые политики безопасности также могут быть описаны на языке спецификаций PSL. Упомянутые политики безопасности могут быть применены для систем разработчика, состоящих из большого количества компонентов. Для упомянутой системы модель с дискретными событиями представляет собой результирующий конечный автомат, который задан путем комбинации множества конечных автоматов, каждый из которых описывает отдельный компонент системы. Для каждого конечного автомата указывают множество их состояний и переходов между ними при возникновении определенных событий. Состояние результирующего конечного автомата определяют путем комбинации состояний конечных автоматов компонентов системы. При этом указанная комбинация осуществляется, например, путем синхронного или асинхронного произведения конечных автоматов. Для результирующего конечного автомата также задают список разрешенных переходов, список разрешенных состояний и список запрещенных состояний результирующего конечного автомата. Соответственно, с использованием политик безопасности проверяют переход упомянутых конечных автоматов компонентов системы и результирующего конечного автомата в начальное состояние, заданное в конфигурации соответствующего конечного автомата, переход между состояниями при возникновении определенного события, нахождение соответствующего конечного автомата в одном из заданных состояний.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 mentioned system, the discrete event model is the resulting finite state machine, which is defined by combining a set of finite state machines, each of which describes a separate component of the system. For each 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.

В еще одном частном варианте реализации для политик безопасности, использующих различные модели, выбирают различные средства настройки 220. Например, политики безопасности могут быть объедены в классы политик. Класс политик безопасности - это набор семантически связанных политик, реализующих определенную модель политик безопасности. Первый класс политик может состоять из политик безопасности, использующих конечный автомат, а второй класс политик может состоять из политик безопасности, использующих мандатный контроль целостности. В этом примере для политик безопасности из первого класса будет выбрано средство настройки 1, в то время как для политик безопасности из второго класса будет выбрано средство настройки 2. Описанный вариант реализации позволит разрабатывать средства настройки 220, предназначенные для настройки модулей проверки 221 для политик безопасности из одного класса. Кроме того, при добавлении новой политики безопасности в базу политик 121 будет использовано существующее средство настройки 220 без необходимости его доработки или добавления нового средства настройки 220.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 that use a state machine, and the second class of policies may consist of security policies that use 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 .

В еще одном частном варианте реализации с использованием средства формирования 210 дополнительно включают в монитор безопасности 120 контекст 122 монитора безопасности 120, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого контекста 122, где контекст 122 монитора безопасности 120 содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста 122 с учетом решений 150 на основании политик безопасности. В зависимости от используемых политиками безопасности упомянутых моделей контекст 122 может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст 122 будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст 122 будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.In another particular implementation, using the generation tool 210 , the context 122 of the security monitor 120 is additionally included in the security monitor 120 , while the security monitor 120 monitors the delivery of the message 140 additionally taking into account the mentioned context 122 , where the context 122 of the security monitor 120 contains the values of the policy settings security. 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 of these models used, the 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.

В частном варианте реализации в случае, если сообщению 140 соответствуют по меньшей мере две политики безопасности, дополнительно вычисляют общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого общего решения. Когда процесс 131 или процесс 132 инициирует взаимодействие путем отправки сообщения 140, монитор безопасности 120 вызывает все политики безопасности из базы политик 121, связанные с этим конкретным взаимодействием. Если все политики безопасности вынесли решение «разрешено», то с использованием монитора безопасности 120 выносят общее решение «разрешено». Если хотя бы одна политика вынесла решение «запрещено», с использованием монитора безопасности 120 выносят общее решение «запрещено».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 issued a "forbidden" decision, a general "forbidden" decision is made using the security monitor 120 .

В еще одном частном варианте реализации настройка модуля проверки политик 221 включает создание кода, обеспечивающего вынесение решения 150 по запросу монитора безопасности 120 для политики безопасности при выполнении упомянутой политики безопасности.In yet another particular implementation, customizing the policy 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.

В частном варианте реализации монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом решений 150 на основании политик безопасности, связанных с упомянутыми сообщениями 140.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 .

Фиг. 4 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24. Fig. 4 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 .

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.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 .

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.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 .

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.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.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 4. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.The personal computer 20 is capable of operating in a networked environment using a network connection to another or more remote computers 49 . The remote computer (or computers) 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. 4 . Other devices may also be present in the computer network, such as routers, network stations, peer-to-peer devices, or other network nodes.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях (также — информационных системах), внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.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 local 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 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 (44)

1. Система формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), при этом указанная система содержит:1. A system for generating a security monitor designed to control the delivery of interprocess communication messages (hereinafter referred to as messages) transmitted by processes of operating system applications (hereinafter referred to as OS), while this system contains: а) базу политик, предназначенную для хранения политик безопасности для контроля доставки сообщений;a) a policy base designed to store security policies to control message delivery; б) по меньшей мере одно средство настройки, предназначенное для настройки модуля проверки политик на основании полученных от средства формирования политик безопасности, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности;b) at least one configuration tool for configuring the policy checker based on the policy checker received from the security policy generator, where the policy checker is designed to make a decision on the method for controlling message delivery (hereinafter referred to as the decision) at the request of the security monitor when executing the security policy ; в) упомянутое средство формирования, предназначенное для:c) said forming means intended for: анализа политик безопасности из базы политик, где анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности;analysis of security policies from the policy base, where the analysis consists, in particular, in determining the processes for which the corresponding security policy is used; выбора политик безопасности из базы политик для соответствующих средств настройки;selecting security policies from the policy base for the appropriate configuration tools; передачи по меньшей мере одной политики безопасности соответствующему средству настройки;transmitting at least one security policy to a corresponding configuration tool; формирования монитора безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения.generating a security monitor using the customized policy checkers received from each configuration tool based on the results of the analysis, while the security monitor controls the delivery of the message, taking into account the mentioned solution. 2. Система по п. 1, в которой контроль доставки сообщения включает разрешение или запрет доставки сообщения.2. The system of claim 1, wherein the message delivery control includes allowing or denying message delivery. 3. Система по п. 1, в которой при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.3. The system of claim 1, wherein said analysis takes into account OS architecture objects including said processes and applications. 4. Система по п. 1, в которой сообщения включают: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.4. The system of claim 1, wherein the messages include: a request to start a process, a request and response to interprocess communication, a process request to a security monitor. 5. Система по п. 3 или 4, в которой объекты архитектуры ОС дополнительно включают:5. The system of claim 3 or 4, wherein the OS architecture objects further include: предоставляющий сервис процесс, который включает по меньшей мере один программный компонент, предназначенный для реализации программного интерфейса упомянутого процесса, при этом взаимодействие с упомянутым процессом происходит посредством упомянутого интерфейса;a service-providing process that includes at least one software component for implementing a programming interface of said process, wherein interaction with said process occurs via said interface; перечень программных интерфейсов для каждого процесса;a list of software interfaces for each process; при этом межпроцессное взаимодействие осуществляется с использованием упомянутых интерфейсов процессов.wherein the inter-process communication is carried out using the mentioned process interfaces. 6. Система по п. 1, в которой формируют монитор безопасности путем создания кода монитора безопасности, включающего один из: исходный код, промежуточный код, исполняемый код.6. The system according to claim 1, in which the security monitor is generated by creating a security monitor code, including one of: source code, intermediate code, executable code. 7. Система по п. 1, в которой упомянутый анализ включает по меньшей мере один из: лексический анализ, синтаксический анализ, семантический анализ.7. The system of claim. 1, in which the said analysis includes at least one of: lexical analysis, syntactic analysis, semantic analysis. 8. Система по п. 7, в которой выполняют синтаксический анализ путем построения синтаксического дерева для кода монитора безопасности, при этом включают в синтаксическое дерево код модулей проверки политик, сформированных по меньшей мере одним средством настройки.8. The system of claim 7, wherein parsing is performed by constructing a parse tree for the security monitor code, wherein the code of the policy checkers generated by at least one configuration tool is included in the parse tree. 9. Система по п. 1, в которой политики безопасности используют по меньшей мере одну из следующих моделей:9. The system of claim 1, wherein the security policies use at least one of the following models: а) базовые операции;a) basic operations; б) конечный автомат;b) finite state machine; в) временной автомат;c) time machine; г) ролевое управление доступом;d) role-based access control; д) мандатный контроль целостности;e) mandatory integrity control; е) регулярные выражения;f) regular expressions; ж) дискретные события;g) discrete events; з) мандатные ссылки; h) mandatory references; и) темпоральная логика.i) temporal logic. 10. Система по п. 9, в которой для политик безопасности, использующих различные модели, выбирают различные средства настройки.10. The system of claim 9, wherein different configuration tools are selected for security policies using different models. 11. Система по п. 9, в которой с использованием средства формирования дополнительно включают в монитор безопасности контекст монитора безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого контекста, где контекст монитора безопасности содержит значения параметров политик безопасности.11. The system according to claim 9, wherein using the generation tool, the context of the security monitor is additionally included in the security monitor, while the security monitor controls the delivery of the message additionally taking into account the said context, where the security monitor context contains the values of security policy settings. 12. Система по п. 11, в которой монитор безопасности дополнительно предназначен для изменения упомянутого контекста с учетом упомянутых решений.12. The system of claim 11, wherein the security monitor is further configured to change said context in view of said decisions. 13. Система по п. 1, в которой в случае, если сообщению соответствуют по меньшей мере две политики безопасности, дополнительно с использованием монитора безопасности выносят общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого общего решения.13. The system according to claim 1, in which, if at least two security policies correspond to the message, in addition, using the security monitor, a general decision is made for the mentioned security policies by conjunct decisions for each of the mentioned security policies, while the security monitor performs message delivery control additionally taking into account the mentioned general solution. 14. Система по п. 1, в которой настройка модуля проверки политик включает создание кода, обеспечивающего вычисление решения по запросу монитора безопасности для политики безопасности при выполнении упомянутой политики безопасности.14. The system of claim 1, wherein configuring the policy checker includes generating code that computes a decision on a security monitor request for a security policy when said security policy is executed. 15. Система по п. 1, в которой монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутых решений.15. The system according to claim 1, in which the security monitor monitors the delivery of the message in addition, taking into account the mentioned solutions. 16. Система по п. 1, в которой система дополнительно включает сервис аудита, предназначенный для записи в журнал результатов контроля доставки сообщений, при этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита.16. The system of claim 1, wherein the system further includes an audit service for logging the results of message delivery control, wherein the message delivery control further includes performing an audit using the audit service. 17. Система по п. 16, в которой монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом статуса и текущего состояния аудита.17. The system of claim 16, wherein the security monitor monitors message delivery further based on the status and current state of the audit. 18. Способ формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), в котором:18. A method for generating a security monitor designed to control the delivery of interprocess communication messages (hereinafter referred to as messages) transmitted by processes of operating system applications (hereinafter referred to as OS), in which: а) с помощью средства формирования анализируют политики безопасности из базы политик, где база политик предназначена для хранения политик безопасности для контроля доставки сообщений, при этом анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности;a) using a generation tool, they analyze the security policies from the policy base, where the policy base is intended to store security policies for controlling message delivery, the analysis being, in particular, determining the processes for which the corresponding security policy is used; б) с помощью средства формирования выбирают политики безопасности из базы политик для соответствующих средств настройки;b) using the generation tool, select security policies from the policy base for the corresponding configuration tools; в) с помощью средства формирования передают по меньшей мере одну выбранную политику безопасности соответствующему средству настройки;c) using the generation tool, transfer at least one selected security policy to the corresponding configuration tool; г) с использованием упомянутых средств настройки выполняют настройку модулей проверки политик, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности;d) using the above configuration tools, configure the policy check modules, where the policy check module is designed to make a decision on the method for controlling message delivery (hereinafter referred to as the decision) at the request of the security monitor when executing the security policy; д) с помощью средства формирования формируют монитор безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения.e) the generation tool generates a security monitor using the customized policy checkers received from each configuration tool based on the results of the analysis, while the security monitor monitors the delivery of the message, taking into account the mentioned solution. 19. Способ по п. 18, в котором контроль доставки сообщения включает разрешение или запрет доставки сообщения.19. The method of claim 18, wherein the message delivery control includes allowing or denying message delivery. 20. Способ по п. 18, в котором при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.20. The method of claim 18, wherein said analysis takes into account OS architecture objects including said processes and applications.

Images