Система и способ контроля доставки сообщений, передаваемых между процессами из разных операционных систем Российский патент 2022 года по МПК G06F21/50 G06F9/46 

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

Изобретение относится к области информационной безопасности.

Уровень техники

Современные операционные системы (далее - ОС) представляют собой сложные информационные системы с множеством установленного программного обеспечения (далее - ПО) для выполнения самого разнообразного функционала. При этом разработчики ПО ведут постоянную работу над исправлением ошибок и расширением функционала ПО. Тем не менее, такое количество и разнообразие ПО влечет за собой существенные риски информационной безопасности из-за наличия уязвимостей в ПО, а также из-за возможности несанкционированной установки вредоносного ПО. Первым уровнем защиты против упомянутых угроз являются особенности архитектуры ОС, а также встроенные в ОС средства защиты, потому что именно ОС предоставляет механизмы обработки и контроля межпроцессных взаимодействий (англ. inter-process communication, IPC), которые могут быть реализованы, в частности путем обмена сообщений между процессами.

Во многих популярных ОС (например, Windows 9x, Linux, Android и др.) используют монолитное ядро (англ. monolithic kernel), которое обладает рядом преимуществ, например производительностью, а также простотой взаимодействия драйверов между собой. Но из-за большого количества программных модулей ядра и, как следствие, высокой вероятности ошибок в коде, обеспечение надежности и безопасности ОС с монолитным ядром затруднительно. Таким образом, при наличии уязвимости в ОС, доставка некоторых нежелательных или вредоносных сообщений между процессами может быть разрешена средствами обработки и контроля межпроцессных взаимодействий. Примером такого вредоносного сообщения между процессами является сообщение, содержащее запрос на доступ к защищенному участку памяти. Другим типом ядра ОС является микроядро (например, ядро KasperskyOS, Symbian и др.), предоставляющее минимальный набор элементарных функций управления процессами и абстракций для работы с оборудованием. Для микроядерной (англ. microkernel) архитектуры ОС характерен небольшой размер микроядра и доверенной вычислительной базы. Это способствует более высокому уровню надежности и безопасности микроядерной архитектуры ОС, так как небольшой объем кода микроядра проще проверить на корректность. Но при этом такая архитектура ОС обладает, как правило, более низкой производительностью. Также существуют ОС с гибридными ядрами (англ. hybrid kernel, например, MacOS X, Windows NT и др.), которые позволяют операционной системе использовать преимущества хорошо структурированной микроядерной архитектуры ОС, сохраняя при этом производительность монолитного ядра.

Для операционных систем актуальна задача обеспечения надежности и безопасности межпроцессных взаимодействий, реализованных путем обмена сообщений между процессами. Еще более сложной задачей является обеспечение безопасности межпроцессных взаимодействий между первым и вторым процессами, где второй процесс исполняется в среде, аппаратно или программно изолированной от первой среды исполнения, в которой исполняется первый процесс. Например, второй процесс может исполняться на втором компьютере, связанном с первым компьютером по сети, на виртуальной машине или в других средах выполнения. В этом случае возникает техническая проблема, заключающаяся в сложности осуществления контроля доставки сообщений межпроцессного взаимодействия между процессами из разных ОС на предмет соответствия политике безопасности.

Из уровня техники известен патент US8336050B2, в котором описан способ межпроцессного взаимодействия между виртуальными машинами с использованием виртуальной синхронизации и общей памяти.

Тем не менее, известные технологии не позволяют решить заявленную техническую проблему, так как они не позволяют осуществить контроль доставки сообщений межпроцессного взаимодействия между процессами из разных ОС на предмет соответствия политике безопасности. Поэтому возникает необходимость в технологии, способной решить заявленную техническую проблему.

Раскрытие сущности изобретения

Настоящее изобретение предназначено контроля доставки сообщений, передаваемых между первым и вторым процессами, исполняющимися в разных операционных системах.

Первый технический результат заключается в повышении безопасности ОС при обмене сообщениями межпроцессного взаимодействия, передаваемыми между первым и вторым процессами из разных ОС за счет создания прокси-процесса для отправки и получения сообщений от второго процесса, обладающего программным интерфейсом для прокси-процесса, а также добавления политики безопасности для контроля доставки сообщений, связанных с упомянутым прокси-процессом.

Второй технический результат заключается в повышении контроля доставки сообщений межпроцессного взаимодействия, передаваемых между первым и вторым процессами.

В варианте реализации используется способ контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых между процессами из разных операционных систем (ОС), в котором: с помощью средства создания процесса создают прокси-процесс в первой ОС, предназначенный для обмена сообщениями между по меньшей мере первым процессом из первой ОС и вторым процессом во второй ОС и обладающий программным интерфейсом, соответствующим программному интерфейсу второго процесса, при этом первая ОС и вторая ОС — это операционные системы, установленные в разных вычислительных средах; с помощью средства назначения политик назначают по меньшей мере одну политику безопасности созданному прокси-процессу для контроля доставки сообщений, связанных с прокси-процессом, где сообщения передают через заданный программный интерфейс; с помощью сформированного монитора безопасности осуществляют контроль доставки сообщений между по меньшей мере первым и вторым процессами путем контроля доставки сообщений, связанных с прокси-процессом, на основании политик безопасности.

В одном из частных вариантов реализации контроль доставки сообщения включает по меньшей мере разрешение или запрет доставки сообщения.

В другом частном варианте реализации сообщения включают по меньшей мере одно из: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.

В еще одном частном варианте реализации вторая ОС является одной из по меньшей мере следующих: гостевой ОС, работающей на виртуальной машине под управлением первой ОС на компьютере; гостевой ОС, работающей на виртуальной машине, при этом первая ОС является второй гостевой ОС, работающей на второй виртуальной машине и связанной с первой виртуальной машиной посредством гипервизора; второй ОС на втором компьютере, который связан с компьютером, на котором функционирует первая ОС, по сети.

В одном из частных вариантов реализации монитор безопасности сформирован для первой ОС с использованием средства формирования.

В одном из частных вариантов реализации формируют монитор безопасности с учетом особенностей архитектуры первой ОС, в частности с учетом созданного прокси-процесса, а также с учетом назначенных прокси-процессу политик безопасности из базы политик.

В другом частном варианте реализации формируют монитор безопасности путем создания кода монитора безопасности, включающего один из: исходный код, промежуточный код, исполняемый код.

В одном из частных вариантов реализации при контроле доставки сообщений, монитор безопасности использует программный интерфейс прокси-процесса для определения разрешенных сообщений для прокси-процесса, при этом с помощью средства назначения политик дополнительно задают список разрешенных сообщений в соответствии с программным интерфейсом и назначают политику безопасности, запрещающую доставку сообщений от прокси-процесса в случае, если монитором безопасности была зафиксирована попытка доставки сообщений, отсутствующих в списке разрешенных.

В другом частном варианте реализации при контроле доставки сообщений, монитор безопасности использует программный интерфейс прокси-процесса для определения перечня процессов, с которыми разрешен обмен сообщениями прокси-процессу, при этом с помощью средства назначения политик дополнительно назначают политику безопасности, запрещающую обмен сообщениями между прокси-процессом и процессами, отсутствующими в перечне процессов, при этом перечень процессов включает по меньшей мере первый процесс.

В еще одном частном варианте реализации создают прокси-процесс для по меньшей мере двух процессов второй ОС, если между упомянутыми процессами второй ОС присутствует программный интерфейс для обмена сообщениями.

В одном из частных вариантов реализации политики безопасности используют по меньшей мере одну из следующих моделей: базовые операции; конечный автомат; временный автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события; мандатные ссылки; темпоральная логика.

В варианте реализации используется система контроля доставки сообщений, передаваемых между процессами из разных ОС, реализуемая компьютером, включающим память и функционально связанный с памятью по меньшей мере один процессор, выполненный с возможностью осуществлять следующие средства: средство создания процесса, предназначенное для создания прокси-процесса в первой ОС, предназначенного для обмена сообщениями между по меньшей мере первым процессом в первой ОС и вторым процессом во второй ОС и обладающего программным интерфейсом, соответствующим программному интерфейсу второго процесса, при этом первая ОС и вторая ОС - это операционные системы, установленные в разных вычислительных средах; средство назначения политик, предназначенное для назначения по меньшей мере одной политики безопасности созданному прокси-процессу для контроля доставки сообщений, связанных с упомянутым прокси-процессом, где заданный программный интерфейс служит для передачи упомянутых сообщений, при этом упомянутые политики сохраняют в базу политик безопасности, которая хранится в памяти; сформированный монитор безопасности, предназначенный для осуществления контроля доставки сообщений между по меньшей мере первым и вторым процессами путем контроля доставки сообщений, связанных с упомянутым прокси-процессом, на основании политик безопасности из базы политик безопасности.

В одном из частных вариантов реализации контроль доставки сообщения включает по меньшей мере разрешение или запрет доставки сообщения.

В другом частном варианте реализации сообщения включают по меньшей мере одно из: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.

В еще одном частном варианте реализации вторая ОС является одной из по меньшей мере следующих: гостевой ОС, работающей на виртуальной машине под управлением первой ОС на компьютере; гостевой ОС, работающей на виртуальной машине, при этом первая ОС является второй гостевой ОС, работающей на второй виртуальной машине и связанной с первой виртуальной машиной посредством гипервизора; второй ОС на втором компьютере, который связан с компьютером, на котором функционирует первая ОС, по сети.

В одном из частных вариантов реализации система дополнительно содержит средство формирования, предназначенное для формирования монитора безопасности в первой ОС.

В одном из частных вариантов реализации средство формирование предназначено для формирования монитора безопасности с учетом особенностей архитектуры первой ОС, в частности с учетом созданного прокси-процесса, а также с учетом назначенных прокси-процессу политик безопасности из базы политик.

В другом частном варианте реализации средство формирование предназначено для формирования монитора безопасности путем создания кода монитора безопасности, включающего один из: исходный код, промежуточный код, исполняемый код.

В одном из частных вариантов реализации при контроле доставки сообщений, монитор безопасности предназначен для использования программного интерфейса прокси-процесса для определения разрешенных сообщений для прокси-процесса, при этом средство назначения политик дополнительно предназначено для задания списка разрешенных сообщений в соответствии с программным интерфейсом и назначения политики безопасности, запрещающей доставку сообщений от прокси-процесса в случае, если монитором безопасности была зафиксирована попытка доставки сообщений, отсутствующих в списке разрешенных.

В другом частном варианте реализации при контроле доставки сообщений, монитор безопасности предназначен для использования программного интерфейса прокси-процесса для определения перечня процессов, с которыми разрешен обмен сообщениями прокси-процессу, при этом с помощью средства назначения политик дополнительно назначают политику безопасности, запрещающую обмен сообщениями между прокси-процессом и процессами, отсутствующими в перечне процессов, при этом перечень процессов включает по меньшей мере первый процесс.

В еще одном частном варианте реализации средство создания процесса предназначено для создания прокси-процесс для по меньшей мере двух процессов второй ОС, если между упомянутыми процессами второй ОС присутствует программный интерфейс для обмена сообщениями.

В одном из частных вариантов реализации политики безопасности используют по меньшей мере одну из следующих моделей: базовые операции; конечный автомат; временный автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события; мандатные ссылки; темпоральная логика.

Краткое описание чертежей

Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:

На Фиг. 1а-1д представлены схемы межпроцессного взаимодействия с использованием монитора безопасности на примере операционной системы с микроядерной архитектурой.

На Фиг. 2а представлена система формирования монитора безопасности.

На Фиг. 2б представлена система контроля доставки сообщений межпроцессного взаимодействия, передаваемых между первым и вторым процессами.

На Фиг. 3а представлен вариант реализации настоящего изобретения на примере второй ОС, являющейся гостевой ОС, работающей на виртуальной машине под управлением первой ОС на компьютере.

На Фиг. 3б представлен пример создания прокси-процессов для виртуальной машины и доменов безопасности гостевой ОС.

На Фиг. 4 представлен способ контроля доставки сообщений, передаваемых между первым и вторым процессами.

Фиг. 5 представляет пример компьютерной системы общего назначения.

Осуществление изобретения

Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако, настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, обеспеченными для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.

Глоссарий

Процесс (англ. process) - последовательность операций при выполнении программы или ее части вместе с используемыми данными, включает один или более потоков (англ. thread) и ассоциированные с ними системные ресурсы.

Межпроцессное взаимодействие (англ. inter-process communication, IPC) - набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов.

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

Современные операционные системы при обмене данными между двумя процессами методами межпроцессного взаимодействия используют как синхронные, так и асинхронные операции.

Домен безопасности (англ. security domain) — часть автоматизированной системы, которая реализует одни и те же политики безопасности.

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

На Фиг. 1а-1в представлены схемы межпроцессного взаимодействия с использованием монитора безопасности 120 на примере ОС 100 с микроядерной архитектурой. Представленная на Фиг. 1а ОС 100 включает изолированные процессы 131-132 приложений ОС 100, которые взаимодействуют между собой за счет межпроцессного взаимодействия, а также с ядром ОС 110 посредством программных интерфейсов путем обмена сообщений 140 (также сообщения межпроцессного взаимодействия, IPC-сообщения, на фигуре обозначены стрелкой, начинающейся с точки). Сообщения 140 включают следующие: запрос на запуск 141 процесса 131, запрос 142 от процесса 131 или ответ 143 от другого процесса 132 (например, вызов процессом 131 метода процесса 132), запрос процесса 132 к монитору безопасности 120 (запрос безопасности 144). Стоит отметить, что под сообщениями 140 в настоящем изобретении понимаются сообщения межпроцессного взаимодействия в общем случае, обеспечивающие возможность взаимодействия между различными процессами ОС 100, в том числе процессами 131-132. Монитор безопасности 120 — компонент ОС 100, предназначенный для осуществления контроля доставки упомянутых сообщений 140. Подробности реализации монитора безопасности 120 будут раскрыты далее по тексту. Также сообщения 140 могут включать уведомление об ошибке от ядра ОС 110 в ответ на сообщения 140 от процессов 131-132. При этом упомянутые интерфейсы, реализуемые процессами, представляют собой структуры данных с объявленными в них методами, реализующими функционал соответствующего процесса.

Упомянутые интерфейсы статически описаны, а разрешенные взаимодействия между процессами заданы заранее.

Отправка и получение сообщений 140 процессами 131-132 происходят посредством системных вызовов ядра ОС 110.

Системные вызовы могут включать следующие:

• call() — используется процессом 131 для отправки запроса 142 к процессу 132 и получения ответа 143 на осуществление межпроцессного взаимодействия;

• recv() — используется процессом 132 для получения запроса 142;

• reply() — используется процессом 132 для отправки ответа 143 процессу 131.

В частном варианте реализации системный вызов reply() производится в том же потоке процесса, в котором происходил вызов recv().

Монитор безопасности 120 реализован с возможностью исполнения на процессоре компьютера, на котором установлена ОС 100 (пример компьютера 20 общего назначения представлен на Фиг. 5). С использованием монитора безопасности 120 осуществляют контроль доставки сообщений 140 с учетом решений 150, принятых на основании политик безопасности из базы политик 121. База политик 121 хранится на машиночитаемом носителе компьютера (в памяти), на котором установлена ОС 100, например на диске 27 компьютера 20 (см. Фиг. 5). Контроль доставки сообщения 140 включает разрешение или запрет доставки сообщения 140 и, соответственно, разрешение или запрет выполнения взаимодействия, осуществляющегося с использованием указанного сообщения 140. Решение 150 о способе контроля доставки сообщения 140 указывает на разрешение или запрет передачи сообщения 140 при выполнении политики безопасности. Решение 150 используется монитором безопасности 120 или его компонентами для осуществления упомянутого контроля доставки сообщений 140 (см. Фиг. 2а). На основании политик безопасности из базы политик 121 могут выносить решение 150 с использованием данных сообщения 140 (например, имени запускаемого процесса или фактических аргументов вызываемого метода процесса).

Также решение 150 о способе контроля доставки сообщения 140 может зависеть от корректности структуры упомянутого сообщения 140. Таким образом, если сообщение 140 имеет недопустимую структуру, передача указанного сообщения 140 может быть запрещена. В этом случае допустимые структуры сообщений 140 могут быть определены с использованием декларативного описания интерфейса процесса-получателя сообщения 140. Упомянутая структура может содержать размер сообщения 140, допустимые аргументы и другие допустимые параметры сообщения 140.

В одном частном варианте реализации монитор безопасности 120 может быть частью ядра ОС 110 или отдельным приложением, исполняющимся на процессоре компьютера. В другом частном варианте реализации монитор безопасности 120 исполняется на процессоре компьютера в привилегированном режиме ядра ОС 110.

В частном варианте реализации ОС 100 дополнительно включает сервис аудита 133, предназначенный для записи в журнал результатов контроля доставки сообщений 140. При этом контроль доставки сообщения 140 дополнительно включает выполнение аудита с использованием сервиса аудита 133. В еще одном частном варианте реализации монитор безопасности 120 осуществляет контроль доставки сообщений 140 дополнительно с учетом текущего статуса сервиса аудита 133. При этом упомянутый статус указывает на готовность сервиса аудита 133 принимать и сохранять сообщения 140. Например, если процесс 131 выполняет запрос 142 к защищенному ресурсу (через процесс 132), где информация о доступе к защищенному ресурсу всегда должна быть записана в журнал, но при этом статус сервиса аудита 133 указывает на то, что сервис аудита 133 в данный момент не сохраняет сообщения 140, то такой запрос 142 будет запрещен монитором безопасности 120 согласно политике безопасности.

В еще одном частном варианте реализации ОС 100 содержит контекст монитора безопасности 122, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого контекста 122, где контекст 122 содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности 120 дополнительно предназначен для изменения контекста 122 с учетом решений 150 на основании политик безопасности из базы политик 121. В частном варианте реализации политики безопасности используют модель конечного автомата, модель мандатного контроля целостности или другие модели для реализации политик безопасности. Подробнее об упомянутых моделях будет раскрыто далее в описании к Фиг. 2а. В зависимости от используемых политиками безопасности упомянутых моделей контекст 122 может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст 122 будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст 122 будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата. На Фиг. 1б представлен пример контроля доставки разрешенного запроса 142 от процесса 131 к процессу 132 с использованием монитора безопасности 120. Процесс 131 может вызвать метод интерфейса процесса 132, для этого процесс 131 отправляет запрос 142, содержащий входные аргументы вызываемого метода. Процесс 131 отправляет запрос 142 посредством ядра ОС 110, которое в свою очередь передает запрос 142 на проверку монитору безопасности 120. Монитор безопасности 120 выносит решение 150 «разрешено» на основании политик безопасности и передает указанное решение 150 ядру ОС 110. После этого ядро 110 на основании решения 150 передает запрос 142 далее процессу 132.

В рассматриваемом примере процесс 132 далее отправляет ответ 143 (обратный порядок следования сообщений 140 не указан) процессу 131, где ответ 143 содержит выходные аргументы вызываемого метода. Способ отправки ответа 143 аналогичен способу отправки запроса 142, но в обратном порядке, от процесса 132 к процессу 131. То есть процесс 132 отправляет ответ 143 посредством ядра ОС 110, которое в свою очередь передает ответ 143 на проверку монитору безопасности 120. Монитор безопасности 120 выносит новое решение 150 «разрешено» на основании политик безопасности и передает указанное новое решение 150 обратно ядру ОС 110. После этого ядро 110 на основании нового решения 150 передает ответ 143 далее процессу 131.

На Фиг. 1в представлен пример контроля запрещенного запроса 142 от процесса 131 к процессу 132, в котором монитор безопасности 120 осуществляет контроль доставки запроса 142 путем запрета доставки запроса 142. Процесс 131 отправляет запрос 142 посредством ядра ОС 110, которое в свою очередь передает запрос 142 на проверку монитору безопасности 120. Монитор безопасности 120 выносит решение 150 «запрещено» на основании политик безопасности и передает указанное решение 150 ядру ОС 110. После этого ядро 110 на основании решения 150 направляет уведомление об ошибке процессу 131. При этом запрос 142 не будет передан процессу 132.

На Фиг. 1г представлен пример взаимодействия первого процесса 134, выполняемого в первой ОС 100, со вторым процессом 161, выполняемого во второй ОС 160, посредством канала связи 170, который не контролируется монитором безопасности 120. Для простоты изложения здесь и далее под первой ОС понимается ОС 100 (см. Фиг. 1а). Стоит отметить, что вторая ОС 160 может быть любой ОС, архитектура которой известна из уровня техники, в том числе и операционной системой 100, архитектура которой представлена на Фиг. 1а. Таким образом, первая ОС 100 и вторая ОС 160 могут быть как разными ОС (то есть не обладающими одинаковой архитектурой ОС), так и одинаковыми ОС, а ключевое отличие заключается в том, что первая ОС 100 и вторая ОС 160 установлены в разных вычислительных средах. Так в примерных вариантах реализации первая ОС 100 и вторая ОС 160 могут быть установлены на различных компьютерах, виртуальных машинах или в программно или аппаратно изолированных друг от друга вычислительных средах, которые в свою очередь реализованы с возможностью исполнения на компьютере 20 (см. Фиг. 5). Одним из примеров технологии для изолирования вычислительных сред является технология TrustZone.

Таким образом, взаимодействие первого процесса 134 со вторым процессом 161 осуществляется с использованием канала связи 170, например компьютерной сети, транспортного механизма виртуальных машин (например, расширения паравиртуализации VirtIO) и другого канала связи в зависимости от вычислительных сред, на которых установлены первая ОС 100 и вторая ОС 160. Однако, такой способ взаимодействия первого процесса 134 со вторым процессом 161 обладает рядом недостатков, так как доставка сообщений 140, передаваемых между упомянутыми процессами по каналу связи 170, не может быть проконтролирована монитором безопасности 120 на предмет соответствия политике безопасности из базы политик 121. Это влечет за собой снижение безопасности первой ОС 100 при обмене сообщениями 140, передаваемыми между первым 134 и вторым 161 процессами. Таким образом, пример взаимодействия между первым 134 и вторым 161 процессами, представленный на Фиг. 1г не позволяет решить заявленную техническую проблему. В данной связи для решения указанной технической проблемы может быть использовано заявленное изобретение.

На Фиг. 1д представлен пример безопасного взаимодействия первого процесса 134 в первой ОС 100 со вторым процессом 161 во второй ОС 160 согласно заявленному изобретению. Стоит отметить, что в общем случае второй процесс 161 может взаимодействовать с несколькими процессами в первой ОС 100, один из которых представлен на фигуре как первый процесс 134. Однако для простоты изложения далее будет рассмотрен только первый процесс 134, взаимодействующий со вторым процессом 161. Как и в предыдущем примере, представленном на Фиг. 1г, первая ОС 100 связана со второй ОС 160 посредством канала связи 170, который не контролируется монитором безопасности 120. Вторая ОС 160 может быть любой ОС, архитектура которой известна из уровня техники, в том числе и операционной системой 100, архитектура которой представлена на Фиг. 1а. Первая ОС 100 и вторая ОС 160 могут быть установлены на различных компьютерах, виртуальных машинах или в программно или аппаратно изолированных друг от друга вычислительных средах, которые в свою очередь реализованы с возможностью исполнения на компьютере 20 (см. Фиг. 5). Однако второй процесс 161 взаимодействует с первым процессом 134 не напрямую, а посредством заранее созданного прокси-процесса 135. При этом прокси-процесс 135 представлен в первой ОС 100 (но не представлен во второй ОС 160), предназначен для обмена сообщениями 140 со вторым процессом 161 по каналу связи 170 и обладает программным интерфейсом, соответствующим программному интерфейсу второго процесса 161. В частном варианте реализации при контроле доставки сообщений 140 монитор безопасности 120 использует программный интерфейс прокси-процесса 135 для определения разрешенных сообщений 140 для прокси-процесса 135. При этом в базе политик 121 заранее определена по меньшей мере одна политика безопасности, запрещающая доставку сообщений 140 от прокси-процесса 135 в случае, если монитором безопасности 120 была зафиксирована попытка доставки сообщений 140, отсутствующих в списке разрешенных. При этом список разрешенных сообщений 140 и соответствующие политики безопасности заранее задают с помощью средства назначения политик 290 при формировании монитора безопасности 120 (см. Фиг. 2а-2б). Таким образом, первый процесс 134 взаимодействует с прокси-процессом 135 посредством отправки сообщений 140 межпроцессного взаимодействия и под контролем монитора безопасности 120, в то время как прокси-процесс 135 связан со вторым процессом 161 по каналу связи 170, при этом монитор безопасности 120 не контролирует канал связи 170.

В предпочтительном варианте реализации во второй ОС 160 каждому второму процессу соответствует свой отдельный прокси процесс. Например, второму процессу 161 соответствует прокси-процесс 135, а третьему процессу 162 соответствует второй прокси-процесс (на фигуре не указан), отличный от прокси-процесса 135. Кроме того, в предпочтительном варианте реализации процессы 161 и 162 не связаны между собой.

При этом в частном варианте реализации во второй ОС 160 второй процесс 161 может быть связан с третьим процессом 162 посредством программного интерфейса для обмена сообщениями 140. В этом примере может использоваться один прокси-процесс 135, единый для обоих упомянутых процессов 161-162. Таким образом, процессы 161-162 образуют единый домен безопасности, взаимодействие с которым происходит посредством одного прокси-процесса 135, что также позволяет контролировать взаимодействие между вторым 161 и третьим 162 процессами второй ОС 160. Стоит отметить, что упомянутый домен безопасности, включающий процессы 161-162, может также включать и большее количество процессов второй ОС 160, не представленных на фигуре. В ином случае, когда во второй ОС 160 могут быть выделены несколько различных доменов безопасности, каждый из которых включает по меньшей мере один второй процесс, то для каждого упомянутого домена безопасности будет определен отдельный прокси-процесс в первой ОС 100.

Использование представленной системы взаимодействия первого 134 и второго 161 процессов позволяет решить указанную техническую проблему и достичь заявленных технических результатов, а именно повысить безопасность ОС при обмене сообщениями 140 межпроцессного взаимодействия, передаваемыми между первым 134 и вторым 161 процессами из разных ОС за счет создания прокси-процесса 135 для отправки и получения сообщений 140 от второго процесса 161, обладающего программным интерфейсом для прокси-процесса 135, а также добавления политики безопасности для контроля доставки сообщений 140, связанных с упомянутым прокси-процессом 135, а также повысить контроль доставки сообщений 140 межпроцессного взаимодействия, передаваемых между первым 134 и вторым 161 процессами. Подробнее о вариантах реализации настоящего изобретения, в частности о создании прокси-процесса 135 и назначении политик безопасности созданному прокси-процессу 135 будет описано далее.

На Фиг. 2а представлена система формирования монитора безопасности 200. Система формирования монитора безопасности 200 используется для повышения безопасности ОС 100 при обмене сообщениями 140, а также для обеспечения контроля доставки упомянутых сообщений 140 получателям. При этом монитор безопасности 120 может быть использован разработчиками ПО в различных операционных системах 100, а также в любых других компьютерных системах, в которых осуществляется обмен сообщениями 140, в частности в базах данных и в прикладном ПО. Пример такого использования был приведен ранее на Фиг. 1а-1в. Для каждой ОС 100 формируют монитор безопасности 120 с учетом особенностей архитектуры ОС 240, а также с учетом требований безопасности для данной ОС 100, которые выражаются в политиках безопасности. Стоит отметить, что для различных программных и программно-аппаратных систем разработчика на базе ОС 100 (далее — система разработчика) основные объекты архитектуры ОС 240 могут быть общими, например процессы, службы, приложения, драйверы, отвечающие за работу ядра ОС 110 и других компонентов ОС 260. В то же время другие объекты архитектуры ОС 240, отвечающие за функциональность системы разработчика, будут различными для каждой из упомянутых систем. Следовательно, будут различаться и политики безопасности, с использованием которых осуществляется контроль доставки сообщений 140. Системы разработчика могут включать программное обеспечение, а также программно-аппаратные комплексы.

Система 200 содержит базу политик 121, предназначенную для хранения политик безопасности, необходимых для контроля доставки сообщений 140. Система 200 также содержит по меньшей мере одно средство настройки 220, которое предназначено для настройки соответствующего ему модуля проверки 221 на основании политик безопасности, полученных от средства формирования 210. Модуль проверки 221 предназначен для вынесения решения 150 о способе контроля доставки сообщения 140 (далее — решение) по запросу монитора безопасности 120 при выполнении политики безопасности. Система 200 также содержит описание архитектуры ОС 240, которое в свою очередь включает такие объекты архитектуры ОС, как процессы и приложения ОС 100. В частном варианте реализации упомянутые объекты архитектуры ОС дополнительно включают объекты системы разработчика на базе ОС 100. В еще одном частном варианте реализации объекты архитектуры ОС дополнительно включают:

• предоставляющий сервис процесс, который включает по меньшей мере один программный компонент, предназначенный для реализации программного интерфейса упомянутого процесса, при этом взаимодействие с упомянутым процессом происходит посредством упомянутого интерфейса (например, таким сервисом может быть приложение, транслирующее поток внешних событий и запросы для процесса обработки событий);

• перечень программных интерфейсов для каждого процесса, при этом могут быть указаны соответствующие методы интерфейсов, реализующие функционал соответствующего процесса.

В еще одном частном варианте реализации объектом архитектуры ОС дополнительно является драйвер ресурсов — процесс, управляющий ресурсами и доступом к ним. Ресурсом является, в частности, файл, порт или процесс. Например, файловая система является драйвером ресурсов, а сами файлы — ресурсами, к которым файловая система может предоставить доступ другим процессам.

Кроме того, система 200 содержит средство формирования 210, предназначенное для анализа политик безопасности, где анализ заключается, в частности, в определении процессов, для которых используется упомянутая политика безопасности. В частном варианте реализации при упомянутом анализе учитывают объекты архитектуры ОС 240, включающие упомянутые процессы и приложения. Средство формирования 210 также предназначено для выбора политик безопасности из базы политик 121 для соответствующих средств настройки 220 и для передачи по меньшей мере одной выбранной политики безопасности соответствующему средству настройки 220. Средство формирования 210 также предназначено для формирования монитора безопасности 120 с использованием настроенных модулей проверки 221, полученных от каждого средства настройки 220 на основании результатов анализа. В частном варианте реализации средство формирования 210 формирует монитор безопасности 120 путем создания кода монитора безопасности 120. При этом упомянутый код может быть исходным кодом, промежуточным кодом или исполняемым кодом. Кроме того, формирование кода монитора безопасности 120 также может включать оптимизацию кода и анализ кода на наличие ошибок. Таким образом, средство формирования 210 может быть компилятором, формирующим упомянутый код.

Архитектура ОС 240, база политик 121, а также средства настройки 220 могут быть настроены заранее с использованием средства разработки 250. Для этого средство разработки 250 может предоставлять набор API (англ. application programming interface — программный интерфейс приложения) или готовые модули для разработки ПО. При этом под интерфейсом далее понимается интерфейс процессов, описанный ранее, а для программного интерфейса приложения будет использовано сокращение API. В частном варианте реализации по меньшей мере часть архитектуры ОС 240, часть политик безопасности из базы политик 121, а также часть средств настройки 220 могут быть общими (шаблонными) для различных ОС 100. В этом случае разработчик с использованием средств разработки 250 может настроить средства настройки 220, архитектуру ОС 240 и политики безопасности из базы политик 121 путем добавления в упомянутый шаблон отсутствующих в шаблоне политик безопасности, в архитектуре ОС 240, а также средств настройки 220, необходимых для отражения особенностей ОС 100, или системы разработчика на базе ОС 100, и требований безопасности к ОС 100 или соответственно к системе разработчика на базе ОС 100, для которой упомянутый разработчик формирует монитор безопасности 120. Кроме того, часть данных из упомянутого шаблона может быть удалена, если она будет не нужна в ОС 100 или соответственно в системе разработчика на базе ОС 100. Например, могут быть удалены некоторые политики безопасности и приложения.

Сформированный монитор безопасности 120 вместе с другими компонентами ОС 260 далее включают в операционную систему 100. При этом упомянутое включение монитора безопасности 120 и компонентов ОС 260 может быть осуществлено известными из уровня техники способами, например на этапе компиляции ОС 100 с использованием компилятора ОС 100 или путем установки монитора безопасности 120 в ОС 100. Как упоминалось ранее, монитор безопасности 120 может быть частью ядра ОС 110 или отдельным приложением ОС 100. Монитор безопасности 120 исполняется в привилегированном режиме ядра ОС 110. Для ОС 100 также может быть создан установочный образ ОС 270, необходимый для установки ОС 100 на компьютерные устройства конечных пользователей. Установочный образ ОС 270 может быть, например архивом, исполняемым файлом или установочным пакетом. Установочный пакет представляет собой файл архива, в который входят файлы ОС 100, управляющие файлы и опционально файлы для настройки процесса установки ОС 110. Кроме того, в установочный пакет могут входить файлы системы разработчика на базе ОС 100. Упомянутые файлы могут быть представлены в исходном коде, в промежуточном коде или в исполняемом коде.

Описание политик безопасности

В частном варианте реализации политики безопасности используют по меньшей мере одну из следующих моделей:

базовые операции;

конечный автомат;

временной автомат;

ролевое управление доступом;

мандатный контроль целостности;

регулярные выражения;

дискретные события (англ. Discrete Event Systems, DES);

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

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

Политики безопасности из базы политик 121 могут быть заданы с использованием языка спецификации, например PSL (англ. policy specification language). На примере PSL мандатный контроль целостности задан классом политик Mandatory_integrity_control. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в системе, которые могут быть реализованы путем обмена сообщений 140 между процессами. При каждой попытке взаимодействия, то есть при проверке монитором безопасности 120 сообщений 140, монитор безопасности 120 исполняет правила для определения решения о допустимости указанного взаимодействия (доставки сообщения 140). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.

В частном варианте реализации анализ политик безопасности и объектов архитектуры ОС 240 включает по меньшей мере один из следующих видов анализа: лексический анализ, синтаксический анализ, семантический анализ. В результате указанного анализа политик безопасности определяют объекты архитектуры ОС 240, в частности, процессы, участвующие в обмене сообщений 140, для которых применяется упомянутая политика безопасности. То есть будет определено соответствие между определенными объектами архитектуры ОС 240 и политикой безопасности, применяемой для указанных объектов. Например, если политика безопасности разрешает запрос 142 от процесса 131 к процессу 132, то в результате анализа этой политики безопасности будут определены указанные процессы 131-132 и информация о разрешенном запросе 142. Стоит отметить, что в результате указанного анализа политик безопасности могут дополнительно определить и другие объекты архитектуры ОС 240, которые проверяют в указанной политике безопасности, например, методы интерфейсов процесса, когда сообщение 140 адресовано указанному методу и будет передано по указанному интерфейсу процесса. В этом случае политики безопасности будут проверять условие, что при обмене сообщениями 140 между определенными процессами используются заданные интерфейсы процессов и заданные методы интерфейсов.

На примере языка PSL, с использованием которого могут быть заданы политики безопасности в базе политик 121, указание на процесс 131, являющийся источником запроса 142, может содержаться в переменной scr. Указание на процесс 132, являющийся получателем запроса 142 может содержаться в переменной dst. Соответственно, именно упомянутый анализ политики безопасности, написанной на языке PSL, позволит определить указанные объекты архитектуры ОС, для которых будет применяться указанная политика безопасности.

В другом частном варианте реализации анализ политик безопасности также включает проверку типов объектов архитектуры ОС 240, а также анализ на ошибки в политиках безопасности.

Результаты упомянутого анализа учитываются при формировании монитора безопасности 120. Например, в мониторе безопасности 120 могут быть записаны условия применения политик безопасности — перечень объектов архитектуры ОС 240, в частности, процессов, и соответствующие указанному перечню политики безопасности, а также модули проверки 221. Поэтому при получении от ядра ОС 110 сообщения 140 сформированный монитор безопасности 120 определяет объекты архитектуры ОС 240, участвующие в обмене сообщением 140, после чего определяет политики безопасности, применимые к указанным объектам архитектуры ОС 240. После чего монитор безопасности 120 передает сообщения 140 модулям проверки 221, соответствующим указанным политикам безопасности, для вынесения решения о способе контроля доставки сообщения 140.

В еще одном частном варианте реализации выполняют синтаксический анализ путем построения синтаксического дерева для кода монитора безопасности 120, при этом включают в синтаксическое дерево код модулей проверки 221, сформированных по меньшей мере одним средством настройки 220.

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

Политики безопасности также могут использовать конечный автомат, где политика безопасности определяет разрешение или запрет доставки сообщения 140 в зависимости от состояния конечного автомата и в соответствии с таблицей переходов состояний конечного автомата.

Модель временных автоматов (англ. Timed automata), и в частности временной автомат типа ERA (англ. Event-recording automata), является частным случаем конечных автоматов. В данной модели дополнительно для каждого сообщения 140 задают параметр времени (таймер), равный времени с момента последнего получения этого сообщения 140. Например, переход из одного состояния конечного автомата в другое состояние может быть осуществлен, если сообщение 140 было получено спустя время, определенное таймером.

Модель мандатного контроля целостности (англ. Mandatory integrity control) используется для разрешения или запрета доставки сообщения 140. Согласно модели мандатного контроля целостности с использованием монитора безопасности 120 объектам архитектуры ОС 240, участвующим в передаче сообщения 140, например процессам 131-132, ставят в соответствие два числа, называемые уровнем целостности (англ. Integrity level) и уровнем доступа. При этом для разрешения доставки сообщения 140 от одного объекта к другому используются политики безопасности на основе мандатного контроля целостности, то есть использующие значения уровней целостности и уровней доступа объектов. Например, может быть использована политика безопасности, согласно которой одному объекту разрешено обращаться к другому объекту, если значение уровня доступа первого объекта не ниже значения уровня целостности другого. На языке спецификаций PSL для модели мандатного контроля целостности задают уровни целостности и уровни доступа. Таким образом, для задания уровней целостности определяют объект политик integrity, являющийся экземпляром класса Mandatory_integrity_control:

В конфигурации объекта политик integrity будут заданы три уровня целостности: LOW (низкий), MEDIUM (средний) и HIGH (высокий) — в порядке возрастания. То есть LOW < MEDIUM < HIGH.

В основе политик на основе мандатных ссылок (англ. object capability model) лежит принцип минимальных привилегий. Этот принцип организации доступа к ресурсам подразумевает предоставление субъекту (процессу или пользователю) только тех привилегий, которые являются абсолютно необходимыми для успешного выполнения задачи. Например, пользователю, который хочет ознакомиться с содержимым файла, должны быть выданы только права на чтение этого файла и только на период использования этого файла.

Для задания политик безопасности на основе темпоральной логики формулируют свойства (требования) безопасности с помощью формулы темпоральной логики и с использованием темпоральных операторов. С использованием монитора безопасности 120 объектам архитектуры ОС 240, участвующим в передаче сообщения 140, например процессам 131-132, ставят в соответствие события их состояния из заранее определенного множества событий.

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

Свойство 1. Всегда, когда выполняется проверка целостности образа ПО, должно быть гарантировано, что после процесса проверки целостности образа ПО упомянутый образ ПО не будет изменен. Данное свойство можно записать в виде формулы:

G (verify => P seal),

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

Свойство 2. Установка ПО из образа ПО возможна только в том случае, если подтверждена целостность образа ПО. Данное свойство можно записать в виде формулы:

G (apply => P verify).

Создание объекта класса политик, реализующего управление доступом на основе темпоральной логики, может быть реализовано на языке PSL в виде следующей конструкции:

Стоит отметить, что возможны и другие формулировки свойств. Например, свойство 2 может быть задано следующим образом: образ ПО не применяется, пока не подтверждена целостность образа ПО:

!apply U verify,

где U — темпоральный оператор «до тех пор, пока не наступит заданное событие».

Политика на основе модели темпоральной логики при установке ПО связывает с данным межпроцессным взаимодействием событие apply и проверяет истинность формулы, указанной в конфигурации объекта политик. Если формула истинна, политика разрешает взаимодействие, если ложна — запрещает.

Политики на основе модели с дискретными событиями задают с использованием соответствующего политикам модуля проверки 221. Упомянутые политики безопасности также могут быть описаны на языке спецификаций PSL. Упомянутые политики безопасности могут быть применены для систем разработчика, состоящих из большого количества компонентов. Для упомянутой системы модель с дискретными событиями представляет собой результирующий конечный автомат, который задан путем комбинации множества конечных автоматов, каждый из которых описывает отдельный компонент системы. Для каждого конечного автомата указывают множество их состояний и переходов между ними при возникновении определенных событий. Состояние результирующего конечного автомата определяют путем комбинации состояний конечных автоматов компонентов системы. При этом указанная комбинация осуществляется, например, путем синхронного или асинхронного произведения конечных автоматов. Для результирующего конечного автомата также задают список разрешенных переходов, список разрешенных состояний и список запрещенных состояний результирующего конечного автомата. Соответственно, с использованием политик безопасности проверяют переход упомянутых конечных автоматов компонентов системы и результирующего конечного автомата в начальное состояние, заданное в конфигурации соответствующего конечного автомата, переход между состояниями при возникновении определенного события, нахождение соответствующего конечного автомата в одном из заданных состояний.

В еще одном частном варианте реализации для политик безопасности, использующих различные модели, выбирают различные средства настройки 220. Например, политики безопасности могут быть объедены в классы политик. Класс политик безопасности — это набор семантически связанных политик, реализующих определенную модель политик безопасности. Первый класс политик может состоять из политик безопасности, использующих конечный автомат, а второй класс политик может состоять из политик безопасности, использующих мандатный контроль целостности. В этом примере для политик безопасности из первого класса будет выбрано средство настройки 1, в то время как для политик безопасности из второго класса будет выбрано средство настройки 2. Описанный вариант реализации позволит разрабатывать средства настройки 220, предназначенные для настройки модулей проверки 221 для политик безопасности из одного класса. Кроме того, при добавлении новой политики безопасности в базу политик 121 будет использовано существующее средство настройки 220 без необходимости его доработки или добавления нового средства настройки 220.

В еще одном частном варианте реализации с использованием средства формирования 210 дополнительно включают в монитор безопасности 120 контекст монитора безопасности 122, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого контекста 122, где контекст монитора безопасности 122 содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста 122 с учетом решений 150 на основании политик безопасности. В зависимости от используемых политиками безопасности упомянутых моделей контекст 122 может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст 122 будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст 122 будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.

В частном варианте реализации в случае, если сообщению 140 соответствуют по меньшей мере две политики безопасности, дополнительно вычисляют общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности 120 осуществляет контроль доставки сообщения 140 дополнительно с учетом упомянутого общего решения. Когда процесс 131 или процесс 132 инициирует взаимодействие путем отправки сообщения 140, монитор безопасности 120 вызывает все политики безопасности из базы политик 121, связанные с этим конкретным взаимодействием. Если все политики безопасности вынесли решение «разрешено», то с использованием монитора безопасности 120 выносят общее решение «разрешено». Если хотя бы одна политика вынесла решение «запрещено», с использованием монитора безопасности 120 выносят общее решение «запрещено».

В еще одном частном варианте реализации настройка модуля проверки 221 включает создание кода, обеспечивающего вынесение решения 150 по запросу монитора безопасности 120 для политики безопасности при выполнении упомянутой политики безопасности.

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

На Фиг. 2б представлена система контроля доставки сообщений межпроцессного взаимодействия, передаваемых между первым 134 и вторым 161 процессами. Для осуществления контроля доставки сообщений 140, передаваемых между первым 134 и вторым 161 процессами, может быть использована система формирования монитора безопасности 200 (Фиг. 2а) для формирования монитора безопасности 120 для первой ОС 100. Таким образом система контроля доставки сообщений 201 использует систему формирования монитора безопасности 200, при этом дополнительно включает средство создания процесса 280 и средство назначения политик 290.

Стоит отметить, что описанные средства и модули, в частности средства настройки 220, средство формирования 210, средство разработки 250, средство создания процесса 280, средство назначения политик 290, реализованы с возможностью исполнения на процессоре компьютера (см. Фиг. 5). При этом база политик 121, архитектура первой ОС 241, модули проверки 221 содержатся в памяти компьютера.

Средство создания процесса 280 предназначено для создания прокси-процесса 135 для второго процесса 161, где прокси-процесс 135 предназначен для обмена сообщениями 140 со вторым процессом 161 во второй ОС 160 и обладает программным интерфейсом, соответствующим программному интерфейсу второго процесса 161. При этом информацию о втором процессе 161, в частности о его программных интерфейсах, средство создания процесса 280 получает от средства разработки 250.

Таким образом, информация о созданном первом процессе 134, взаимодействующим со вторым процессом 161 во второй ОС 160, будет добавлена в архитектуру первой ОС 241 средством создания процесса 280. Средство назначения политик 290 предназначено для назначения политик безопасности созданному прокси-процессу 135 для контроля доставки сообщений 140, связанных с упомянутым прокси-процессом 135, где упомянутые сообщения 140 передают по заданному программному интерфейсу. При этом назначенные прокси-процессу 135 политики безопасности будут сохранены в базу политик 121. После формирования монитор безопасности 120 будет осуществлять контроль доставки сообщений 140 между первым 134 и вторым 161 процессами, при этом сообщения 140 связаны с упомянутым прокси-процессом 135, а упомянутый контроль осуществляется с учетом политики безопасности, назначенной средством назначения политик 290.

В частном варианте реализации монитор безопасности 120 при контроле доставки сообщений 140 использует программный интерфейс прокси-процесса 135 для определения разрешенных сообщений 140 для прокси-процесса 135. При этом с помощью средства назначения политик 290 определяют политику безопасности, запрещающую доставку сообщений 140 от прокси-процесса 135 в случае, если была зафиксирована попытка доставки сообщений 140, отсутствующих в списке разрешенных. Список разрешенных сообщений 140 и соответствующие политики безопасности заранее задают с помощью средства назначения политик 290 при формировании монитора безопасности 120. В еще одном частном варианте реализации при контроле доставки сообщений 140 монитор безопасности 120 использует программный интерфейс прокси-процесса 135 для определения перечня процессов, с которыми разрешен обмен сообщениями 140 прокси-процессу 135. При этом перечень процессов включает по меньшей мере первый процесс 134. При этом с помощью средства назначения политик 290 дополнительно назначают политику безопасности, запрещающую обмен сообщениями 140 между прокси-процессом 135 и процессами, отсутствующими в упомянутом перечне. Допустимые структуры разрешенных сообщений 140 могут быть определены с использованием декларативного описания интерфейса второго процесса 161. Такие структуры могут содержать размер сообщения 140, допустимые аргументы и другие допустимые параметры сообщения 140.

Таким образом, с использованием настоящего изобретения для реализации межпроцессных взаимодействий второго процесса 161 с первым процессом 134 создают прокси-процесс 135, реализующий все программные интерфейсы второго процесса 161, и назначают политики безопасности для созданного прокси-процесса 135 для контроля доставки сообщений 140 между вторым 161 и первым 134 процессами по разрешенным интерфейсам. Настоящее изобретение позволяет монитору безопасности 120 осуществить контроль доставки сообщений 140 между вторым 161 и первым 134 процессами путем контроля доставки сообщений 140, связанных с упомянутым прокси-процессом 135, с учетом политики безопасности, даже несмотря на наличие небезопасного канала связи 170. За счет этого заявленное изобретение решает указанную техническую проблему и достигает заявленных технических результатов.

В еще одном частном варианте реализации для процессов 161-162 второй ОС 160, между которыми присутствует программный интерфейс для обмена сообщениями 140, с помощью средства создания процесса 280 создают один прокси-процесс 135, единый для обоих упомянутых процессов 161-162. Стоит отметить, что в случае, если процессы 161-162 не связаны между собой, то есть являются отдельными доменами безопасности, для каждого из них будет создан отдельный прокси-процесс. Например, для второго процесса 161 будет создан прокси-процесс 135 для взаимодействия с первым процессом 134. А для третьего процесса 162 будет создан другой прокси-процесс (на фигуре не указан) для взаимодействия с другим процессом (на фигуре не указан) в первой ОС 100.

В частном варианте реализации вторая ОС 160 является одной из:

гостевой ОС, работающей на виртуальной машине под управлением первой ОС 100 на компьютере;

гостевой ОС, работающей на виртуальной машине, при этом первая ОС 100 является второй гостевой ОС, работающей на второй виртуальной машине и связанной с первой виртуальной машиной посредством гипервизора;

второй ОС 160 на втором компьютере, который связан с компьютером, на котором функционирует первая ОС 100, по сети или посредством других каналов связи 170.

В частном варианте реализации, когда второй процесс 161 содержит более одного потока выполнения, для каждого потока второго процесса 161 создают соответствующий поток в прокси-процессе 135. В этом случае поток второго процесса 161, который осуществляет обмен сообщениями межпроцессного взаимодействия, выполняет вызов метода драйвера канала связи 170 (путем системного вызова операций ввода-вывода, например, ioctl), который в свою очередь уведомляет прокси-процесс 135 о необходимости создания потока в прокси-процессе 135 для обмена сообщениями межпроцессного взаимодействия с соответствующим потоком второго процесса 161. После завершения обмена сообщениями 140 между потоками второго процесса 161 и прокси-процесса 135, второй процесс 161, путем вызова метода драйвера канала связи 170, уведомляет прокси-процесс 135 о завершении обмена сообщениями 140 с ним. После этого прокси-процесс 135 завершает выполнение соответствующего потока в прокси-процессе 135.

Драйвер канала связи 170 предназначен для установления канала связи 170 между вторым процессом 161 и прокси-процессом 135, управления потоками для прокси-процесса 135, для реализации вызовов call(), recv(), reply(), причем программный интерфейс прокси-процесса 135 соответствует интерфейсу второго процесса 161, а также для доставки сообщений 140 от второго процесса 161 соответствующему потоку прокси-процесса 135.

Стоит также отметить, что при создании прокси-процессов, например, прокси-процесса 135, для различных процессов второй ОС 160 может быть использован общий шаблон прокси-процесса, однако для различных процессов второй ОС 160 в соответствующем прокси-процессе будет реализован программный интерфейс, соответствующий интерфейсу второго процесса 161. Таким образом, использование общего шаблона прокси-процесса повышает безопасность заявленного изобретения за счет возможности более детальной проверки кода указанного шаблона, а также использования общих политик безопасности. При этом несмотря на то, что некоторые политики безопасности для различных процессов второй ОС 160 будут одинаковыми, часть политик безопасности будет отличаться.

На Фиг. 3а представлен вариант реализации настоящего изобретения на примере второй ОС 160, являющейся гостевой ОС, работающей на виртуальной машине под управлением первой ОС 100 на компьютере (пример компьютера 20 общего назначения представлен на Фиг. 5). В рассматриваемом примере в первой ОС 100 установлен гипервизор 303, являющийся модулем (сервисом) ядра ОС 110 и управляющий виртуальными машинами 301-302. Упомянутые виртуальные машины 301-302 являются приложениями первой ОС 100, исполняющиеся в пространстве пользователя на процессоре компьютере. Гипервизор 303 может использовать любую известную из уровня техники систему виртуализации для обеспечения работы виртуальных машин. Примером гипервизора 303 является Kaspersky Secure Hypervisor (KSH) — безопасная система виртуализации на базе гипервизора второго типа, где первая ОС 100 (например, KasperskyOS) выступает в роли хост-машины. В данном случае гипервизор 303 экспортирует компонентный интерфейс, который используется виртуальными машинами 301-302 для управления сессиями, виртуальными процессорами, памятью и низкоуровневым пробросом устройств. Кроме виртуальных машин в первой ОС 100 могут функционировать другие приложения 331-332. В предпочтительном варианте реализации упомянутые приложения 331-332 и виртуальные машины 301-302 содержат по одному процессу, но также могут быть реализованы с использованием нескольких процессов и исполняются на процессоре компьютера.

В контексте приложения виртуальной машины 301 создают виртуальную машину с гостевой ОС 310, под управлением которой работают гостевые функциональные компоненты, реализованные с использованием гостевых процессов и приложений. В качестве примера в гостевой ОС 310 созданы приложения 311-314, разделенные на два домена безопасности 315-316. В общем случае функциональные компоненты гостевой ОС 310 могут работать в различных доменах безопасности, при этом гостевая ОС 310 обеспечивает изоляцию упомянутых доменов безопасности, а гипервизор 303 обеспечивает изоляцию гостевой ОС 310 от виртуальных машин, представленных приложениями 317-318. Аналогичным образом в контексте приложения виртуальной машины 302 создают виртуальную машину с гостевой ОС 320.

Доставка сообщений 140 межпроцессного взаимодействия от различных доменов безопасности 315-316 гостевой ОС 310, а также от приложения виртуальной машины 301, являющегося отдельным доменом безопасности, контролируются монитором безопасности 120 первой ОС 100 независимо с использованием созданных прокси-процессов для каждого домена безопасности. Аналогичным образом монитор безопасности 120 контролирует доставку сообщений 140 от приложения виртуальной машины 302 и доменов безопасности 325-326 гостевой ОС 320. При этом виртуальная машина 301 осуществляет контроль взаимодействия между доменами безопасности 315-316 внутри гостевой ОС 310, контроль собственных политик безопасности внутри виртуальной машины 301, контроль доступа к оборудованию гостевой ОС 310, контроль управления потоками данных для эмулируемых устройств и другие взаимодействия внутри гостевой ОС 310.

Взаимодействия, контролируемые модулем безопасности 120, обозначены на Фиг. 3а сплошной линией со стрелками. А взаимодействия, неконтролируемые монитором безопасности 120, обозначены штриховой линией — например, взаимодействия между гипервизором 303 и виртуальными машинами 301-302, требующие привилегированного режима ядра ОС 100, которые невозможно реализовать в пользовательском режиме в приложениях виртуальных машин 301-302. При этом взаимодействия между различными виртуальными машинами 301-302 также контролируются монитором безопасности 120.

На Фиг. 3б представлен пример создания прокси-процессов для виртуальной машины 301 и доменов безопасности гостевой ОС 310. Так, будут созданы прокси-процесс 341 для домена безопасности 315 и прокси-процесс 342 для домена безопасности 316. Созданные прокси-процессы 341-342 взаимодействуют с другими процессами первой ОС 100 посредством сообщений межпроцессного взаимодействия 140, доставка которых контролируется монитором безопасности 120. При этом виртуальная машина 301, будучи отдельным доменом безопасности и процессом первой ОС 100, взаимодействует с другими процессами первой ОС 100 посредством сообщений 140, доставка которых также контролируется монитором безопасности 120. То есть для виртуальной машины 301 не требуется создание отдельного прокси-процесса. Также стоит отметить, что созданные прокси-процессы 341-342 будут обладать программными интерфейсами, которые соответствуют программным интерфейсам домена безопасности 315 и домена безопасности 316 соответственно.

Как упоминалось ранее, отправка и получение сообщений 140 процессами первой ОС 100 происходят посредством системных вызовов ядра ОС 110 и по заданным программным интерфейсам.

Системные вызовы могут включать следующие:

• call() — используется процессом 131 для отправки запроса 142 к процессу 132 и получения ответа 143 на осуществление межпроцессного взаимодействия;

• recv() — используется процессом 132 для получения запроса 142;

• reply() — используется процессом 132 для отправки ответа 143 процессу 131.

В частном варианте реализации системный вызов reply() производится в том же потоке процесса, в котором происходил вызов recv().

Для идентификации получателя и отправителя сообщений 140 в гостевой ОС 310 могут быть использованы уникальные идентификаторы, значения которых равны значениям дескрипторов процессов, используемых прокси-процессами 341-342 для обмена сообщениями 140 в первой ОС 100.

В предпочтительном варианте реализации сообщения 140, формируемые вторым, а также другими процессами гостевой ОС 310 (в данном примере — доменами безопасности 315-316 и приложением виртуальной машины 301), представлены в формате сообщений 140, передаваемых в первой ОС 100. В этом случае соответствующие прокси-процессы 341-342, получив сообщения 140 от процессов гостевой ОС 310, являющейся второй ОС 160 (домены безопасности 315-316), осуществят дальнейшую отправку сообщений 140 соответствующим процессам 351-352 первой ОС 100 без изменения. В другом варианте реализации, когда формат сообщений 140 от процессов второй ОС 160 отличен от формата сообщений 140, прокси-процесс осуществит преобразование сообщений 140 от процессов второй ОС 160 в формат сообщений 140.

При обращении второго процесса, например домена безопасности 315 в гостевой ОС 310, к процессу 351 первой ОС 100, домен безопасности 315 получает дескриптор процесса 351 и отправляет сообщение 140 прокси-процессу 341 по каналу связи 170 (удаленный вызов call()). При этом домен безопасности 315 переходит в спящее состояние (англ. sleep) до момента получения сообщения reply() от прокси-процесса 341. Прокси-процесс 341, получив указанное сообщение, преобразовывает его в сообщение 140 и отправляет сообщение 140 процессу 351 с использованием системного вызова ядра ОС 100. При этом доставка сообщения 140 будет проконтролирована монитором безопасности 120 с использованием политик безопасности, назначенных для прокси-процесса 341 и процесса 351. Отправка сообщений 140 от процесса 351 домену безопасности 315 происходит аналогичным образом посредством прокси-процесса 341 и под контролем монитора безопасности 120. После получения сообщения 140 домен безопасности 315 выходит из спящего состояния и завершает вызов call().

Стоит отметить, что упомянутое взаимодействие осуществляется посредством программных интерфейсов домена безопасности 315 и соответствующего программного интерфейса прокси-процесса 341. Программный интерфейс домена безопасности 315 получает набор дескрипторов, необходимых для обмена сообщениями 140, значения которых соответствуют дескрипторам прокси-процесса 341. Поток выполнения домена безопасности 315 производит вызов recv() по указанному интерфейсу к прокси-процессу 341, после чего указанный поток выполнения переходит в спящий режим. Вызов recv() потока выполнения домена безопасности 315 приводит к системному вызову recv() ядра первой ОС 110, который инициирует прокси-процесс 341. После этого прокси-процесс 341 также переходит в спящий режим. После того, как прокси-процесс 341 получает вызов call() от домена безопасности 315 (например, от другого потока выполнения), прокси-процесс 341 выходит из спящего состояния, а полученные ранее при вызове recv() данные отправляет домену безопасности 315 по соответствующему программному интерфейсу. Домен безопасности 315 также выходит из спящего состояния и получает данные, полученные в вызове recv() от прокси-процесса 341. Домен безопасности 315 в том же потоке, в котором производил вызов recv(), производит обработку вызова и отправляет данные, используя вызов reply(). Прокси-процесс 341, получив указанные данные, отправляет их домену безопасности 315. Для осуществления многопоточного обмена сообщениями 140 между вторым процессом (доменом безопасности 315) и прокси-процессом 341, для каждого потока второго процесса создается советующий поток прокси-процесса.

В частном варианте реализации интерфейс прокси-процессов может включать следующие вызовы:

• method() — предназначен для получения идентификатора потока, дескриптора диапазона разделяемой памяти и смещения в пределах этого дескриптора, обработка указанного метода осуществляется отдельным потоком прокси-процесса;

• event() — предназначен для ожидания событий и возвращения описателей событий, обработка указанного метода осуществляется отдельным потоком прокси-процесса, при этом упомянутые события включают ответы на вызовы call() и получение запросов от процессов второй ОС 160 во время ожидания в спящем состоянии на вызов recv().

Упомянутые описатели событий содержат информацию о событии, включая тип события (call(), recv()), идентификатор потока прокси-процесса, в котором произошло событие, дескриптор диапазона разделяемой памяти, в котором были получены данные и др. В случае, когда в буфере событий отсутствуют элементы, в вызове event() происходит ожидание события. В случае, когда буфер событий содержит элементы, вызов event() возвращает описатель из указанного буфера.

На Фиг. 4 представлен способ контроля доставки сообщений 140, передаваемых между по меньшей мере первым 134 и вторым 161 процессами, реализуемый компьютером. Так, на шаге 410 с помощью средства создания процесса 280 для второго процесса 161 создают прокси-процесс 135 в первой ОС 100, предназначенный для обмена сообщениями 140 со вторым процессом 161 во второй ОС 160 и обладающий программным интерфейсом, соответствующим программному интерфейсу второго процесса 161. Затем, на шаге 420 с помощью средства назначения политик 290 назначают по меньшей мере одну политику безопасности созданному прокси-процессу 135 для контроля доставки сообщений 140, связанных с упомянутым прокси-процессом 135, где упомянутые сообщения 140 передают через заданный программный интерфейс. На шаге 430 для первой ОС 100 формируют монитор безопасности 120 с учетом особенностей архитектуры ОС 240, в частности с учетом созданного прокси-процесса 135, а также с учетом требований безопасности для первой ОС 100, которые выражаются в назначенных политиках безопасности из базы политик 121. В итоге, на шаге 440 с помощью сформированного монитора безопасности 120 осуществляют контроль доставки сообщений 140 между по меньшей мере первым 134 и вторым 161 процессами путем контроля доставки сообщений 140, связанных с упомянутым прокси-процессом 135, на основании политик безопасности из базы политик 121. Стоит отметить, что частные варианты, раскрытые ранее, также применимы к способу на Фиг. 4.

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

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20. Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

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

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другими удаленными компьютерами 49. Удаленные 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 5. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

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

В соответствии с описанием, компоненты, этапы исполнения, структура данных, описанные выше, могут быть выполнены, используя различные типы операционных систем, компьютерных платформ, программ.

В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.

Изобретение относится к вычислительной технике. Технический результат заключается в повышении безопасности операционных систем при обмене сообщениями межпроцессного взаимодействия, передаваемыми между первым и вторым процессами из разных операционных систем. Описан способ контроля доставки сообщений межпроцессного взаимодействия, передаваемых между процессами из разных операционных систем, в котором с помощью средства создания процесса создают прокси-процесс в первой ОС, предназначенный для обмена сообщениями между по меньшей мере первым процессом из первой ОС и вторым процессом во второй ОС и обладающий программным интерфейсом, соответствующим программному интерфейсу второго процесса, при этом первая ОС и вторая ОС - это операционные системы, установленные в разных вычислительных средах; с помощью средства назначения политик назначают по меньшей мере одну политику безопасности созданному прокси-процессу для контроля доставки сообщений, связанных с прокси-процессом, где сообщения передают через заданный программный интерфейс; с помощью сформированного монитора безопасности осуществляют контроль доставки сообщений между по меньшей мере первым и вторым процессами путем контроля доставки сообщений, связанных с прокси-процессом, на основании политик безопасности. 2 н. и 20 з.п. ф-лы, 11 ил.

1. Способ контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых между процессами из разных операционных систем (ОС), в котором:

а) с помощью средства создания процесса создают прокси-процесс в первой ОС, предназначенный для обмена сообщениями между по меньшей мере первым процессом из первой ОС и вторым процессом во второй ОС и обладающий программным интерфейсом, соответствующим программному интерфейсу второго процесса, при этом первая ОС и вторая ОС — это операционные системы, установленные в разных вычислительных средах;

б) с помощью средства назначения политик назначают по меньшей мере одну политику безопасности созданному прокси-процессу для контроля доставки сообщений, связанных с прокси-процессом, где сообщения передают через заданный программный интерфейс;

в) с помощью сформированного монитора безопасности осуществляют контроль доставки сообщений между по меньшей мере первым и вторым процессами путем контроля доставки сообщений, связанных с прокси-процессом, на основании политик безопасности.

2. Способ по п. 1, в котором контроль доставки сообщения включает по меньшей мере разрешение или запрет доставки сообщения.

3. Способ по п. 1, в котором сообщения включают по меньшей мере одно из: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.

4. Способ по п. 1, в котором вторая ОС является одной из по меньшей мере следующих:

гостевой ОС, работающей на виртуальной машине под управлением первой ОС на компьютере;

гостевой ОС, работающей на виртуальной машине, при этом первая ОС является второй гостевой ОС, работающей на второй виртуальной машине и связанной с первой виртуальной машиной посредством гипервизора;

второй ОС на втором компьютере, который связан с компьютером, на котором функционирует первая ОС, по сети.

5. Способ по п. 1, в котором монитор безопасности сформирован для первой ОС с использованием средства формирования.

6. Способ по п. 5, в котором формируют монитор безопасности с учетом особенностей архитектуры первой ОС, в частности с учетом созданного прокси-процесса, а также с учетом назначенных прокси-процессу политик безопасности из базы политик.

7. Способ по п. 5, в котором формируют монитор безопасности путем создания кода монитора безопасности, включающего один из исходного кода, промежуточного кода, исполняемого кода.

8. Способ по п. 1, в котором при контроле доставки сообщений монитор безопасности использует программный интерфейс прокси-процесса для определения разрешенных сообщений для прокси-процесса, при этом с помощью средства назначения политик дополнительно задают список разрешенных сообщений в соответствии с программным интерфейсом и назначают политику безопасности, запрещающую доставку сообщений от прокси-процесса в случае, если монитором безопасности была зафиксирована попытка доставки сообщений, отсутствующих в списке разрешенных.

9. Способ по п. 1, в котором при контроле доставки сообщений монитор безопасности использует программный интерфейс прокси-процесса для определения перечня процессов, с которыми разрешен обмен сообщениями прокси-процессу, при этом с помощью средства назначения политик дополнительно назначают политику безопасности, запрещающую обмен сообщениями между прокси-процессом и процессами, отсутствующими в перечне процессов, при этом перечень процессов включает по меньшей мере первый процесс.

10. Способ по п. 1, в котором создают прокси-процесс для по меньшей мере двух процессов второй ОС, если между упомянутыми процессами второй ОС присутствует программный интерфейс для обмена сообщениями.

11. Способ по п. 1, в котором политики безопасности используют по меньшей мере одну из следующих моделей:

а) базовые операции;

б) конечный автомат;

в) временный автомат;

г) ролевое управление доступом;

д) мандатный контроль целостности;

е) регулярные выражения;

ж) дискретные события;

з) мандатные ссылки;

и) темпоральная логика.

12. Система контроля доставки сообщений, передаваемых между процессами из разных ОС, реализуемая компьютером, включающим память и функционально связанный с памятью по меньшей мере один процессор, выполненный с возможностью осуществлять следующие средства:

а) средство создания процесса, предназначенное для создания прокси-процесса в первой ОС, предназначенного для обмена сообщениями между по меньшей мере первым процессом в первой ОС и вторым процессом во второй ОС и обладающего программным интерфейсом, соответствующим программному интерфейсу второго процесса, при этом первая ОС и вторая ОС - это операционные системы, установленные в разных вычислительных средах;

б) средство назначения политик, предназначенное для назначения по меньшей мере одной политики безопасности созданному прокси-процессу для контроля доставки сообщений, связанных с упомянутым прокси-процессом, где заданный программный интерфейс служит для передачи упомянутых сообщений, при этом упомянутые политики сохраняют в базу политик безопасности, которая хранится в памяти;

в) сформированный монитор безопасности, предназначенный для осуществления контроля доставки сообщений между по меньшей мере первым и вторым процессами путем контроля доставки сообщений, связанных с упомянутым прокси-процессом, на основании политик безопасности из базы политик безопасности.

13. Система по п. 12, в которой контроль доставки сообщения включает по меньшей мере разрешение или запрет доставки сообщения.

14. Система по п. 12, в которой сообщения включают по меньшей мере одно из запроса на запуск процесса, запроса и ответа на осуществление межпроцессного взаимодействия, запроса процесса к монитору безопасности.

15. Система по п. 12, в которой вторая ОС является одной из по меньшей мере следующих:

гостевой ОС, работающей на виртуальной машине под управлением первой ОС на компьютере;

гостевой ОС, работающей на виртуальной машине, при этом первая ОС является второй гостевой ОС, работающей на второй виртуальной машине и связанной с первой виртуальной машиной посредством гипервизора;

второй ОС на втором компьютере, который связан с компьютером, на котором функционирует первая ОС, по сети.

16. Система по п. 12, дополнительно содержащая средство формирования, предназначенное для формирования монитора безопасности в первой ОС.

17. Система по п. 16, в которой средство формирование предназначено для формирования монитора безопасности с учетом особенностей архитектуры первой ОС, в частности с учетом созданного прокси-процесса, а также с учетом назначенных прокси-процессу политик безопасности из базы политик.

18. Система по п. 16, в которой средство формирования предназначено для формирования монитора безопасности путем создания кода монитора безопасности, включающего один из исходного кода, промежуточного кода, исполняемого кода.

19. Система по п. 12, в которой при контроле доставки сообщений, монитор безопасности предназначен для использования программного интерфейса прокси-процесса для определения разрешенных сообщений для прокси-процесса, при этом средство назначения политик дополнительно предназначено для задания списка разрешенных сообщений в соответствии с программным интерфейсом и назначения политики безопасности, запрещающей доставку сообщений от прокси-процесса в случае, если монитором безопасности была зафиксирована попытка доставки сообщений, отсутствующих в списке разрешенных.

20. Система по п. 12, в которой при контроле доставки сообщений монитор безопасности предназначен для использования программного интерфейса прокси-процесса для определения перечня процессов, с которыми разрешен обмен сообщениями прокси-процессу, при этом с помощью средства назначения политик дополнительно назначают политику безопасности, запрещающую обмен сообщениями между прокси-процессом и процессами, отсутствующими в перечне процессов, при этом перечень процессов включает по меньшей мере первый процесс.

21. Система по п. 12, в которой средство создания процесса предназначено для создания прокси-процесса для по меньшей мере двух процессов второй ОС, если между упомянутыми процессами второй ОС присутствует программный интерфейс для обмена сообщениями.

22. Система по п. 12, в которой политики безопасности используют по меньшей мере одну из следующих моделей:

а) базовые операции;

б) конечный автомат;

в) временный автомат;

г) ролевое управление доступом;

д) мандатный контроль целостности;

е) регулярные выражения;

ж) дискретные события;

з) мандатные ссылки;

и) темпоральная логика.