Система и способ контроля доставки сообщений, передаваемых между процессами из разных операционных систем
SYSTEM AND METHOD FOR CONTROLLING THE DELIVERY OF MESSAGES TRANSMITTED BETWEEN PROCESSES FROM DIFFERENT OPERATING SYSTEMS

Область техники
Изобретение относится к области информационной безопасности.
Уровень техники
Современные операционные системы (далее - ОС) представляют собой сложные информационные системы с множеством установленного программного обеспечения (далее - ПО) для выполнения самого разнообразного функционала. При этом разработчики ПО ведут постоянную работу над исправлением ошибок и расширением функционала ПО. Тем не менее, такое количество и разнообразие ПО влечет за собой существенные риски информационной безопасности из-за наличия уязвимостей в ПО, а также из-за возможности несанкционированной установки вредоносного ПО. Первым уровнем защиты против упомянутых угроз являются особенности архитектуры ОС, а также встроенные в ОС средства защиты, потому что именно ОС предоставляет механизмы обработки и контроля межпроцессных взаимодействий (англ. 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
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
На  представлены схемы межпроцессного взаимодействия с использованием монитора безопасности  на примере ОС  с микроядерной архитектурой. Представленная на  ОС  включает изолированные процессы - приложений ОС , которые взаимодействуют между собой за счет межпроцессного взаимодействия, а также с ядром ОС  посредством программных интерфейсов путем обмена сообщений (также сообщения межпроцессного взаимодействия, IPC-сообщения, на фигуре обозначены стрелкой, начинающейся с точки). Сообщения  включают следующие: запрос на запуск  процесса , запрос  от процесса  или ответ  от другого процесса  (например, вызов процессом  метода процесса ), запрос процесса  к монитору безопасности  (запрос безопасности ). Стоит отметить, что под сообщениями  в настоящем изобретении понимаются сообщения межпроцессного взаимодействия в общем случае, обеспечивающие возможность взаимодействия между различными процессами ОС , в том числе процессами -. Монитор безопасности  — компонент ОС , предназначенный для осуществления контроля доставки упомянутых сообщений . Подробности реализации монитора безопасности будут раскрыты далее по тексту. Также сообщения  могут включать уведомление об ошибке от ядра ОС  в ответ на сообщения  от процессов . При этом упомянутые интерфейсы, реализуемые процессами, представляют собой структуры данных с объявленными в них методами, реализующими функционал соответствующего процесса.
Упомянутые интерфейсы статически описаны, а разрешенные взаимодействия между процессами заданы заранее.
140
131
132
110
Отправка и получение сообщений  процессами - происходят посредством системных вызовов ядра ОС .
Системные вызовы могут включать следующие:
131
142
132
143
• call() — используется процессом  для отправки запроса  к процессу  и получения ответа  на осуществление межпроцессного взаимодействия;
132
142
• recv() — используется процессом  для получения запроса ;
132
143
131
• reply() — используется процессом  для отправки ответа  процессу .
В частном варианте реализации системный вызов 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
100
160
134
161
140
170
120
121
100
140
134
161
134
161
Фиг. 1г
Таким образом, взаимодействие первого процесса  со вторым процессом  осуществляется с использованием канала связи , например компьютерной сети, транспортного механизма виртуальных машин (например, расширения паравиртуализации VirtIO) и другого канала связи в зависимости от вычислительных сред, на которых установлены первая ОС  и вторая ОС . Однако, такой способ взаимодействия первого процесса  со вторым процессом  обладает рядом недостатков, так как доставка сообщений , передаваемых между упомянутыми процессами по каналу связи , не может быть проконтролирована монитором безопасности  на предмет соответствия политике безопасности из базы политик . Это влечет за собой снижение безопасности первой ОС  при обмене сообщениями , передаваемыми между первым  и вторым  процессами. Таким образом, пример взаимодействия между первым  и вторым  процессами, представленный на  не позволяет решить заявленную техническую проблему. В данной связи для решения указанной технической проблемы может быть использовано заявленное изобретение.
Фиг. 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
240
121
220
100
250
220
240
121
240
220
100
100
100
100
120
100
100
Архитектура ОС , база политик , а также средства настройки  могут быть настроены заранее с использованием средства разработки . Для этого средство разработки  может предоставлять набор API (англ. application programming interface — программный интерфейс приложения) или готовые модули для разработки ПО. При этом под интерфейсом далее понимается интерфейс процессов, описанный ранее, а для программного интерфейса приложения будет использовано сокращение API. В частном варианте реализации по меньшей мере часть архитектуры ОС , часть политик безопасности из базы политик , а также часть средств настройки  могут быть общими (шаблонными) для различных ОС . В этом случае разработчик с использованием средств разработки  может настроить средства настройки , архитектуру ОС  и политики безопасности из базы политик  путем добавления в упомянутый шаблон отсутствующих в шаблоне политик безопасности, в архитектуре ОС , а также средств настройки , необходимых для отражения особенностей ОС , или системы разработчика на базе ОС , и требований безопасности к ОС  или соответственно к системе разработчика на базе ОС , для которой упомянутый разработчик формирует монитор безопасности . Кроме того, часть данных из упомянутого шаблона может быть удалена, если она будет не нужна в ОС или соответственно в системе разработчика на базе ОС . Например, могут быть удалены некоторые политики безопасности и приложения.
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
140
120
140
120
140
Политики безопасности из базы политик  могут быть заданы с использованием языка спецификации, например PSL (англ. policy specification language). На примере PSL мандатный контроль целостности задан классом политик Mandatory_integrity_control. Класс (семейство) политик безопасности определяет множество правил, соответствующих правилам модели, используемой в политике безопасности. Спецификация политики безопасности определяет соответствие упомянутых правил и взаимодействий в системе, которые могут быть реализованы путем обмена сообщений  между процессами. При каждой попытке взаимодействия, то есть при проверке монитором безопасности  сообщений , монитор безопасности  исполняет правила для определения решения о допустимости указанного взаимодействия (доставки сообщения ). Для использования класса политик на его основе создают объект политики, для которого указывают конфигурацию.
240
240
140
240
142
131
132
131
132
142
240
140
140
В частном варианте реализации анализ политик безопасности и объектов архитектуры ОС  включает по меньшей мере один из следующих видов анализа: лексический анализ, синтаксический анализ, семантический анализ. В результате указанного анализа политик безопасности определяют объекты архитектуры ОС , в частности, процессы, участвующие в обмене сообщений , для которых применяется упомянутая политика безопасности. То есть будет определено соответствие между определенными объектами архитектуры ОС  и политикой безопасности, применяемой для указанных объектов. Например, если политика безопасности разрешает запрос  от процесса  к процессу , то в результате анализа этой политики безопасности будут определены указанные процессы - и информация о разрешенном запросе . Стоит отметить, что в результате указанного анализа политик безопасности могут дополнительно определить и другие объекты архитектуры ОС , которые проверяют в указанной политике безопасности, например, методы интерфейсов процесса, когда сообщение  адресовано указанному методу и будет передано по указанному интерфейсу процесса. В этом случае политики безопасности будут проверять условие, что при обмене сообщениями  между определенными процессами используются заданные интерфейсы процессов и заданные методы интерфейсов.
121
131
142
132
142
На примере языка PSL, с использованием которого могут быть заданы политики безопасности в базе политик , указание на процесс , являющийся источником запроса , может содержаться в переменной scr. Указание на процесс , являющийся получателем запроса  может содержаться в переменной 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
Политики безопасности также могут использовать конечный автомат, где политика безопасности определяет разрешение или запрет доставки сообщения  в зависимости от состояния конечного автомата и в соответствии с таблицей переходов состояний конечного автомата.
140
140
140
Модель временных автоматов (англ. Timed automata), и в частности временной автомат типа ERA (англ. Event-recording automata), является частным случаем конечных автоматов. В данной модели дополнительно для каждого сообщения  задают параметр времени (таймер), равный времени с момента последнего получения этого сообщения . Например, переход из одного состояния конечного автомата в другое состояние может быть осуществлен, если сообщение  было получено спустя время, определенное таймером.
140
120
240
140
131
132
140
Модель мандатного контроля целостности (англ. Mandatory integrity control) используется для разрешения или запрета доставки сообщения . Согласно модели мандатного контроля целостности с использованием монитора безопасности  объектам архитектуры ОС , участвующим в передаче сообщения , например процессам -, ставят в соответствие два числа, называемые уровнем целостности (англ. Integrity level) и уровнем доступа. При этом для разрешения доставки сообщения  от одного объекта к другому используются политики безопасности на основе мандатного контроля целостности, то есть использующие значения уровней целостности и уровней доступа объектов. Например, может быть использована политика безопасности, согласно которой одному объекту разрешено обращаться к другому объекту, если значение уровня доступа первого объекта не ниже значения уровня целостности другого. На языке спецификаций 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
220
221
121
220
220
В еще одном частном варианте реализации для политик безопасности, использующих различные модели, выбирают различные средства настройки . Например, политики безопасности могут быть объедены в классы политик. Класс политик безопасности — это набор семантически связанных политик, реализующих определенную модель политик безопасности. Первый класс политик может состоять из политик безопасности, использующих конечный автомат, а второй класс политик может состоять из политик безопасности, использующих мандатный контроль целостности. В этом примере для политик безопасности из первого класса будет выбрано средство настройки 1, в то время как для политик безопасности из второго класса будет выбрано средство настройки 2. Описанный вариант реализации позволит разрабатывать средства настройки , предназначенные для настройки модулей проверки  для политик безопасности из одного класса. Кроме того, при добавлении новой политики безопасности в базу политик  будет использовано существующее средство настройки  без необходимости его доработки или добавления нового средства настройки .
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
135
135
161
140
161
135
161
170
135
140
135
135
В частном варианте реализации, когда второй процесс  содержит более одного потока выполнения, для каждого потока второго процесса  создают соответствующий поток в прокси-процессе . В этом случае поток второго процесса , который осуществляет обмен сообщениями межпроцессного взаимодействия, выполняет вызов метода драйвера канала связи  (путем системного вызова операций ввода-вывода, например, ioctl), который в свою очередь уведомляет прокси-процесс  о необходимости создания потока в прокси-процессе  для обмена сообщениями межпроцессного взаимодействия с соответствующим потоком второго процесса . После завершения обмена сообщениями  между потоками второго процесса  и прокси-процесса , второй процесс , путем вызова метода драйвера канала связи , уведомляет прокси-процесс  о завершении обмена сообщениями  с ним. После этого прокси-процесс  завершает выполнение соответствующего потока в прокси-процессе .
170
170
161
135
135
135
161
140
161
135
Драйвер канала связи  предназначен для установления канала связи  между вторым процессом  и прокси-процессом , управления потоками для прокси-процесса , для реализации вызовов call(), recv(), reply(), причем программный интерфейс прокси-процесса  соответствует интерфейсу второго процесса , а также для доставки сообщений  от второго процесса  соответствующему потоку прокси-процесса .
135
160
160
161
160
Стоит также отметить, что при создании прокси-процессов, например, прокси-процесса , для различных процессов второй ОС  может быть использован общий шаблон прокси-процесса, однако для различных процессов второй ОС  в соответствующем прокси-процессе будет реализован программный интерфейс, соответствующий интерфейсу второго процесса . Таким образом, использование общего шаблона прокси-процесса повышает безопасность заявленного изобретения за счет возможности более детальной проверки кода указанного шаблона, а также использования общих политик безопасности. При этом несмотря на то, что некоторые политики безопасности для различных процессов второй ОС  будут одинаковыми, часть политик безопасности будет отличаться.
Фиг. 3а
160
100
20
Фиг. 5
100
303
110
301
302
301
302
100
303
303
100
303
301
302
100
331
332
331
332
301
302
На  представлен вариант реализации настоящего изобретения на примере второй ОС , являющейся гостевой ОС, работающей на виртуальной машине под управлением первой ОС  на компьютере (пример компьютера  общего назначения представлен на ). В рассматриваемом примере в первой ОС  установлен гипервизор , являющийся модулем (сервисом) ядра ОС  и управляющий виртуальными машинами -. Упомянутые виртуальные машины - являются приложениями первой ОС , исполняющиеся в пространстве пользователя на процессоре компьютере. Гипервизор  может использовать любую известную из уровня техники систему виртуализации для обеспечения работы виртуальных машин. Примером гипервизора  является Kaspersky Secure Hypervisor (KSH) — безопасная система виртуализации на базе гипервизора второго типа, где первая ОС  (например, KasperskyOS) выступает в роли хост-машины. В данном случае гипервизор  экспортирует компонентный интерфейс, который используется виртуальными машинами - для управления сессиями, виртуальными процессорами, памятью и низкоуровневым пробросом устройств. Кроме виртуальных машин в первой ОС  могут функционировать другие приложения -. В предпочтительном варианте реализации упомянутые приложения - и виртуальные машины - содержат по одному процессу, но также могут быть реализованы с использованием нескольких процессов и исполняются на процессоре компьютера.
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
Как упоминалось ранее, отправка и получение сообщений  процессамипервой ОС происходят посредством системных вызовов ядра ОС  и по заданным программным интерфейсам.
Системные вызовы могут включать следующие:
131
142
132
143
• call() — используется процессом  для отправки запроса  к процессу  и получения ответа  на осуществление межпроцессного взаимодействия;
132
142
• recv() — используется процессом  для получения запроса ;
132
143
131
• reply() — используется процессом  для отправки ответа  процессу .
В частном варианте реализации системный вызов 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
315
341
341
140
140
351
100
140
120
341
351
140
351
315
341
120
140
315
При обращении второго процесса, например домена безопасности  в гостевой ОС , к процессу  первой ОС , домен безопасности  получает дескриптор процесса  и отправляет сообщение  прокси-процессу  по каналу связи  (удаленный вызов call()). При этом домен безопасности  переходит в спящее состояние (англ. sleep) до момента получения сообщения reply() от прокси-процесса . Прокси-процесс , получив указанное сообщение, преобразовывает его в сообщение  и отправляет сообщение  процессу  с использованием системного вызова ядра ОС . При этом доставка сообщения  будет проконтролирована монитором безопасности  с использованием политик безопасности, назначенных для прокси-процесса  и процесса . Отправка сообщений  от процесса  домену безопасности  происходит аналогичным образом посредством прокси-процесса  и под контролем монитора безопасности . После получения сообщения  домен безопасности  выходит из спящего состояния и завершает вызов call().
315
341
315
140
341
315
341
315
110
341
341
341
315
341
315
315
341
315
341
315
140
315
341
Стоит отметить, что упомянутое взаимодействие осуществляется посредством программных интерфейсов домена безопасности  и соответствующего программного интерфейса прокси-процесса . Программный интерфейс домена безопасности  получает набор дескрипторов, необходимых для обмена сообщениями , значения которых соответствуют дескрипторам прокси-процесса . Поток выполнения домена безопасности  производит вызов recv() по указанному интерфейсу к прокси-процессу , после чего указанный поток выполнения переходит в спящий режим. Вызов recv() потока выполнения домена безопасности  приводит к системному вызову recv() ядра первой ОС , который инициирует прокси-процесс . После этого прокси-процесс  также переходит в спящий режим. После того, как прокси-процесс  получает вызов call() от домена безопасности  (например, от другого потока выполнения), прокси-процесс  выходит из спящего состояния, а полученные ранее при вызове recv() данные отправляет домену безопасности  по соответствующему программному интерфейсу. Домен безопасности  также выходит из спящего состояния и получает данные, полученные в вызове recv() от прокси-процесса . Домен безопасности  в том же потоке, в котором производил вызов recv(), производит обработку вызова и отправляет данные, используя вызов reply(). Прокси-процесс , получив указанные данные, отправляет их домену безопасности . Для осуществления многопоточного обмена сообщениями  между вторым процессом (доменом безопасности ) и прокси-процессом , для каждого потока второго процесса создается советующий поток прокси-процесса.
В частном варианте реализации интерфейс прокси-процессов может включать следующие вызовы:
• method() — предназначен для получения идентификатора потока, дескриптора диапазона разделяемой памяти и смещения в пределах этого дескриптора, обработка указанного метода осуществляется отдельным потоком прокси-процесса;
160
• event() — предназначен для ожидания событий и возвращения описателей событий, обработка указанного метода осуществляется отдельным потоком прокси-процесса, при этом упомянутые события включают ответы на вызовы call() и получение запросов от процессов второй ОС  во время ожидания в спящем состоянии на вызов 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
26
20
24
представляет пример компьютерной системы общего назначения, персональный компьютер или сервер , содержащий центральный процессор , системную память  и системную шину , которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором . Системная шина  реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) , память с произвольным доступом (ОЗУ) . Основная система ввода/вывода (BIOS) , содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера , например, в момент загрузки операционной системы с использованием ПЗУ .
20
27
28
29
30
31
27
28
30
23
32
33
34
20
27
29
31
56
23
55
Персональный компьютер  в свою очередь содержит жесткий диск  для чтения и записи данных, привод магнитных дисков  для чтения и записи на сменные магнитные диски  и оптический привод  для чтения и записи на сменные оптические диски , такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск , привод магнитных дисков , оптический привод  соединены с системной шиной  через интерфейс жесткого диска , интерфейс магнитных дисков  и интерфейс оптического привода  соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера . Настоящее описание раскрывает реализацию системы, которая использует жесткий диск , сменный магнитный диск  и сменный оптический диск , но следует понимать, что возможно применение иных типов компьютерных носителей информации , которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине  через контроллер .
20
36
35
37
38
39
20
40
42
20
46
47
23
48
47
Компьютер  имеет файловую систему , где хранится записанная операционная система , а также дополнительные программные приложения , другие программные модули  и данные программ . Пользователь имеет возможность вводить команды и информацию в персональный компьютер  посредством устройств ввода (клавиатуры , манипулятора «мышь» ). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе  через последовательный порт , который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор  или иной тип устройства отображения также подсоединен к системной шине  через интерфейс, такой как видеоадаптер . В дополнение к монитору , персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
20
49
49
20
Фиг. 5
Персональный компьютер  способен работать в сетевом окружении, при этом используется сетевое соединение с другими удаленными компьютерами . Удаленные  являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера , представленного на . В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
50
20
50
51
20
54
54
23
46
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN)  и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях (также — информационных системах), внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер  подключен к первой сети  через сетевой адаптер или сетевой интерфейс . При использовании сетей персональный компьютер  может использовать модем  или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем , который является внутренним или внешним устройством, подключен к системной шине  посредством последовательного порта . Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В соответствии с описанием, компоненты, этапы исполнения, структура данных, описанные выше, могут быть выполнены, используя различные типы операционных систем, компьютерных платформ, программ.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.