Система и способ формирования монитора безопасности
SYSTEM AND METHOD FOR FORMING A SECURITY MONITOR

Область техники
Изобретение относится к области информационной безопасности.
Уровень техники
Современные операционные системы (ОС) представляют собой сложные информационные системы (ИС) с множеством установленного программного обеспечения (ПО) для выполнения самого разнообразного функционала. При этом разработчики ПО ведут постоянную работу над исправлением ошибок и расширением функционала ПО. Тем не менее, такое количество и разнообразие ПО влечет за собой существенные риски информационной безопасности из-за наличия уязвимостей в ПО, а также из-за возможности несанкционированной установки вредоносного ПО. Первым уровнем защиты против упомянутых угроз являются встроенные в ОС средства защиты, а также особенности архитектуры ОС, потому что именно ОС предоставляет механизмы обработки и контроля межпроцессных взаимодействий (англ. inter-process communication, IPC), которые могут быть реализованы, в частности, путем обмена сообщений между процессами.
Во многих популярных ОС (например, Windows 9x, Linux, Android и др.) используют монолитное ядро (англ. monolithic kernel), которое обладает рядом преимуществ, например простотой взаимодействия между драйверами и производительностью. Но из-за большого количества программных модулей ядра и, как следствия, высокой вероятности ошибок в коде обеспечение надежности и безопасности ОС с монолитным ядром затруднительно. Как следствие, при наличии уязвимости в ОС или в ПО некоторые нежелательные или вредоносные сообщения между процессами могут быть разрешены средствами обработки и контроля межпроцессных взаимодействий. Примером такого вредоносного сообщения между процессами может служить сообщение, содержащее запрос на доступ к защищенному участку памяти. Другим типом ядра ОС является микроядро (например, KasperskyOS, Symbian и др.), предоставляющее минимальный набор элементарных функций управления процессами и абстракций для работы с оборудованием. Для микроядерной (англ. microkernel) архитектуры ОС характерен небольшой размер микроядра и доверенной вычислительной базы. Это способствует более высокому уровню надежности и безопасности микроядерной архитектуры ОС, так как небольшой объем кода микроядра проще проверить на корректность. Но при этом такая архитектура ОС обладает, как правило, более низкой производительностью. Также существуют ОС с гибридными ядрами (англ. hybrid kernel, например MacOS X, Windows NT и др.), которые позволяют операционной системе использовать преимущества хорошо структурированной микроядерной архитектуры ОС, сохраняя при этом производительность монолитного ядра.
Таким образом, для операционных систем существует актуальная задача обеспечения надежности и безопасности межпроцессных взаимодействий, реализованных путем обмена сообщений между процессами. Поэтому возникает техническая проблема, которая заключается в сложности осуществления контроля доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, на предмет соответствия политике безопасности.
Из уровня техники известен патент US8234686B2, в котором описывают технологию создания политики безопасности криптографического модуля, после этого проверяют упомянутые политики на предмет их возможной подмены. Также известен патент US8650620B2, в котором описаны система и способ контроля запуска приложений на мобильном устройстве путем проверки сертификатов ЭЦП и с использованием мандатного контроля доступа.
Тем не менее, известные технологии не позволяют решить заявленную техническую проблему, так как они не позволяют осуществить контроль доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, на предмет соответствия политике безопасности. Поэтому возникает необходимость в технологии, способной решить заявленную проблему.
Раскрытие сущности изобретения
Первый технический результат заключается в повышении безопасности ОС при обмене сообщениями межпроцессного взаимодействия, передаваемыми процессами приложений ОС за счет формирования монитора безопасности, предназначенного для контроля доставки сообщений с использованием политик безопасности.
Второй технический результат заключается в обеспечении контроля доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, в соответствии с политиками безопасности путем формирования монитора безопасности, обеспечивающего упомянутый контроль.
Согласно варианту реализации используется система формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), при этом указанная система содержит: базу политик, предназначенную для хранения политик безопасности для контроля доставки сообщений; по меньшей мере одно средство настройки, предназначенное для настройки модуля проверки политик на основании полученных от средства формирования политик безопасности, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности; средство формирования, предназначенное для: анализа политик безопасности из базы политик, где анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности; выбора политик безопасности из базы политик для соответствующих средств настройки; передачи по меньшей мере одной политики безопасности соответствующему средству настройки; формирования монитора безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения.
Согласно одному из частных вариантов реализации контроль доставки сообщения включает разрешение или запрет доставки сообщения.
Согласно другому частному варианту реализации при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.
Согласно еще одному частному варианту реализации сообщения включают: запрос на запуск процесса, запрос и ответ на осуществление межпроцессного взаимодействия, запрос процесса к монитору безопасности.
Согласно одному из частных вариантов реализации объекты архитектуры ОС дополнительно включают: предоставляющий сервис процесс, который включает по меньшей мере один программный компонент, предназначенный для реализации программного интерфейса упомянутого процесса, при этом взаимодействие с упомянутым процессом происходит посредством упомянутого интерфейса; перечень программных интерфейсов для каждого процесса; при этом межпроцессное взаимодействие осуществляется с использованием упомянутых интерфейсов процессов.
Согласно другому частному варианту реализации формируют монитор безопасности путем создания кода монитора безопасности, включающего один из: исходный код, промежуточный код, исполняемый код.
Согласно еще одному частному варианту реализации упомянутый анализ включает по меньшей мере один из: лексический анализ, синтаксический анализ, семантический анализ.
Согласно одному из частных вариантов реализации выполняют синтаксический анализ путем построения синтаксического дерева для кода монитора безопасности, при этом включают в синтаксическое дерево код модулей проверки политик, сформированных по меньшей мере одним средством настройки.
Согласно другому частному варианту реализации политики безопасности используют по меньшей мере одну из следующих моделей: базовые операции; конечный автомат; временной автомат; ролевое управление доступом; мандатный контроль целостности; регулярные выражения; дискретные события; мандатные ссылки; темпоральная логика.
Согласно еще одному частному варианту реализации для политик безопасности, использующих различные модели, выбирают различные средства настройки.
Согласно одному из частных вариантов реализации с использованием средства формирования дополнительно включают в монитор безопасности контекст монитора безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого контекста, где контекст монитора безопасности содержит значения параметров политик безопасности.
Согласно другому частному варианту реализации монитор безопасности дополнительно предназначен для изменения упомянутого контекста с учетом упомянутых решений.
Согласно еще одному частному варианту реализации в случае, если сообщению соответствуют по меньшей мере две политики безопасности, дополнительно с использованием монитора безопасности выносят общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутого общего решения.
Согласно одному из частных вариантов реализации настройка модуля проверки политик включает создание кода, обеспечивающего вычисление решения по запросу монитора безопасности для политики безопасности при выполнении упомянутой политики безопасности.
Согласно другому частному варианту реализации монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом упомянутых решений.
Согласно еще одному частному варианту реализации система дополнительно включает сервис аудита, предназначенный для записи в журнал результатов контроля доставки сообщений, при этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита.
Согласно одному из частных вариантов реализации монитор безопасности осуществляет контроль доставки сообщения дополнительно с учетом статуса и текущего состояния аудита.
Согласно варианту реализации используется способ формирования монитора безопасности, предназначенного для контроля доставки сообщений межпроцессного взаимодействия (далее - сообщений), передаваемых процессами приложений операционной системы (далее - ОС), в котором: с помощью средства формирования анализируют политики безопасности из базы политик, где база политик предназначена для хранения политик безопасности для контроля доставки сообщений, при этом анализ заключается, в частности, в определении процессов, для которых используется соответствующая политика безопасности; с помощью средства формирования выбирают политики безопасности из базы политик для соответствующих средств настройки; с помощью средства формирования передают по меньшей мере одну выбранную политику безопасности соответствующему средству настройки; с использованием упомянутых средств настройки выполняют настройку модулей проверки политик, где модуль проверки политик предназначен для вынесения решения о способе контроля доставки сообщения (далее - решение) по запросу монитора безопасности при выполнении политики безопасности; с помощью средства формирования формируют монитор безопасности с использованием настроенных модулей проверки политик, полученных от каждого средства настройки, на основании результатов анализа, при этом монитор безопасности осуществляет контроль доставки сообщения с учетом упомянутого решения.
Согласно одному из частных вариантов реализации контроль доставки сообщения включает разрешение или запрет доставки сообщения.
Согласно другому частному варианту реализации при упомянутом анализе учитывают объекты архитектуры ОС, включающие упомянутые процессы и приложения.
Краткое описание чертежей
Дополнительные цели, признаки и преимущества настоящего изобретения будут очевидными из прочтения последующего описания осуществления изобретения со ссылкой на прилагаемые чертежи, на которых:
Фиг. 1а-1в
На  представлены схемы межпроцессного взаимодействия с использованием монитора безопасности на примере операционной системы с микроядерной архитектурой.
Фиг. 2
На  представлена система формирования монитора безопасности.
Фиг. 3
На  представлен способ формирования монитора безопасности.
Фиг. 4
представляет пример компьютерной системы общего назначения.
Осуществление изобретения
Объекты и признаки настоящего изобретения, способы для достижения этих объектов и признаков станут очевидными посредством отсылки к примерным вариантам осуществления. Однако, настоящее изобретение не ограничивается примерными вариантами осуществления, раскрытыми ниже, оно может воплощаться в различных видах. Сущность, приведенная в описании, является ничем иным, как конкретными деталями, обеспеченными для помощи специалисту в области техники в исчерпывающем понимании изобретения, и настоящее изобретение определяется в объеме приложенной формулы.
Глоссарий
Процесс (англ. process) - последовательность операций при выполнении программы или ее части вместе с используемыми данными, включает один или более потоков (англ. thread) и ассоциированные с ними системные ресурсы.
Межпроцессное взаимодействие (англ. inter-process communication, IPC) - набор способов обмена данными между множеством потоков в одном или более процессах. Процессы могут быть запущены на одном или более компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов.
Асинхронный процесс - процесс, в котором операция не требует отклика для продолжения выполнения.
Синхронный процесс - процесс, в котором операция требует отклика для продолжения выполнения.
Операция - элементарное действие, выполняемое в рамках рассматриваемого процесса (в качестве операции может выступать, например, API-функция).
Современные операционные системы при обмене данными между двумя процессами методами межпроцессного взаимодействия используют как синхронные, так и асинхронные операции.
Конечный автомат (англ. Finite State Machine, FSM) - модель дискретного устройства, характеризующаяся состояниями и переходами от одного состояния к другому. Каждое состояние конечного автомата характеризует одну из возможных ситуаций, в которой может находиться конечный автомат.
Фиг. 1а-1в
120
100
Фиг. 1а
100
131
132
100
110
140
На  представлены схемы межпроцессного взаимодействия с использованием монитора безопасности  на примере операционной системы (ОС)  с микроядерной архитектурой. Представленная на  ОС  включает изолированные процессы - приложений ОС , которые взаимодействуют между собой (IPC), а также с ядром ОС  посредством программных интерфейсов путем обмена сообщений (также сообщения межпроцессного взаимодействия, IPC-сообщения, на фигуре обозначены стрелкой, начинающейся с точки). При этом упомянутые интерфейсы, реализуемые процессами, статически описаны, а разрешенные взаимодействия между процессами заданы заранее.
131
132
110
Отправка и получение сообщений процессами - происходят посредством системных вызовов ядра ОС .
Системные вызовы могут включать следующие:
131
142
132
143
call() - используется процессом  для отправки запроса  к процессу  и получения ответа  на осуществление межпроцессного взаимодействия;
132
142
recv() - используется процессом  для получения запроса ;
132
143
131
reply() - используется процессом  для отправки ответа  процессу .
120
100
140
140
141
131
142
131
143
132
131
132
132
120
144
140
110
131-132
120
140
150
121
140
140
140
150
140
140
150
120
140
Фиг. 2
150
140
Монитор безопасности  - компонент ОС , предназначенный для осуществления контроля доставки упомянутых сообщений . Сообщения  включают следующие: запрос на запуск  процесса , запрос  от процесса  или ответ  от другого процесса  (например, вызов процессом  метода процесса ), запрос процесса  к монитору безопасности  (запрос безопасности ). Также сообщения  могут включать уведомление об ошибке от ядра ОС  в ответ на сообщения от процессов . С использованием монитора безопасности  осуществляют контроль доставки сообщений  с учетом решений , принятых на основании политик безопасности из базы политик . Контроль доставки сообщения  включает разрешение или запрет доставки сообщения  и, соответственно, разрешение или запрет выполнения взаимодействия, осуществляющегося с использованием указанного сообщения . Решение  о способе контроля доставки сообщения  указывает на разрешение или запрет на передачу сообщения  при выполнении политики безопасности. Решение  используется монитором безопасности  или его компонентами для осуществления упомянутого контроля доставки сообщений  (см. ). На основании политик безопасности могут выносить решение  с использованием данных сообщения  (например, имя запускаемого процесса или фактические аргументы вызываемого метода процесса).
150
140
140
140
140
Также решение  о способе контроля доставки сообщения  может зависеть от корректности структуры упомянутого сообщения . Таким образом, если сообщение  имеет недопустимую структуру, передача указанного сообщения  может быть запрещена. В этом случае допустимые структуры сообщений могут быть определены с использованием декларативного описания интерфейса процесса-получателя сообщения. Упомянутая структура может содержать размер сообщения, допустимые аргументы и другие допустимые параметры сообщения.
120
110
120
110
В одном частном варианте реализации монитор безопасности  может быть частью ядра ОС  или отдельным приложением. В другом частном варианте реализации монитор безопасности  исполняется в привилегированном режиме ядра ОС .
100
133
140
133
120
140
133
133
140
131
142
132
133
133
142
120
В частном варианте реализации ОС  дополнительно включает сервис аудита , предназначенный для записи в журнал результатов контроля доставки сообщений . При этом контроль доставки сообщения дополнительно включает выполнение аудита с использованием сервиса аудита . В еще одном частном варианте реализации монитор безопасности  осуществляет контроль доставки сообщений  дополнительно с учетом текущего статуса сервиса аудита . При этом упомянутый статус указывает на готовность сервиса аудита  принимать сообщения . Например, если процесс  выполняет запрос  к защищенному ресурсу (через процесс ), где информация о доступе к защищенному ресурсу всегда должна быть записана в журнал, но при этом статус сервиса аудита  указывает на то, что сервис аудита  в данный момент не сохраняет сообщения, то такой запрос  будет запрещен монитором безопасности  согласно политике безопасности.
100
122
120
120
140
122
122
122
150
122
122
122
В еще одном частном варианте реализации ОС  содержит контекст  монитора безопасности , при этом монитор безопасности  осуществляет контроль доставки сообщения  дополнительно с учетом упомянутого контекста , где контекст  содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста  с учетом решений  на основании политик безопасности. В частном варианте реализации политики безопасности используют модель конечного автомата, модель мандатного контроля целостности или другие модели для реализации политик безопасности. Подробнее об упомянутых моделях будет раскрыто далее. В зависимости от используемых политиками безопасности упомянутых моделей контекст  может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст  будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст  будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.
Фиг. 1б
142
131
132
131
132
131
142
131
142
110
142
120
120
150
150
110
110
150
142
132
На  представлен пример доставки разрешенного запроса  от процесса  к процессу . Процесс  может вызвать метод интерфейса процесса , для этого процесс  отправляет запрос , содержащий входные аргументы вызываемого метода. Процесс  отправляет запрос  посредством ядра ОС , которое в свою очередь передает запрос  на проверку монитору безопасности . Монитор безопасности  выносит решение  «разрешено» на основании политик безопасности и передает указанное решение  ядру ОС . После этого ядро  на основании решения  передает запрос  далее процессу .
132
143
131
143
143
142
132
131
132
143
110
143
120
120
110
110
143
131
В рассматриваемом примере процесс  далее отправляет ответ  процессу , где ответ  содержит выходные аргументы вызываемого метода. Способ отправки ответа  аналогичен способу отправки запроса , но в обратном порядке, от процесса  к процессу . То есть, процесс  отправляет ответ  посредством ядра ОС , которое в свою очередь передает ответ  на проверку монитору безопасности . Монитор безопасности  выносит новое решение «разрешено» на основании политик безопасности и передает указанное новое решение обратно ядру ОС . После этого ядро  на основании нового решения передает ответ  далее процессу .
Фиг. 1в
142
131
132
131
142
110
142
120
120
150
150
110
110
150
131.
142
132
На  представлен пример запрещенного запроса  от процесса  к процессу . Процесс  отправляет запрос  посредством ядра ОС , которое в свою очередь передает запрос  на проверку монитору безопасности . Монитор безопасности  выносит решение  «запрещено» на основании политик безопасности и передает указанное решение  ядру ОС . После этого ядро  на основании решения  направляет уведомление об ошибке процессу  При этом запрос  не будет передан процессу .
Фиг. 2
200
200
100
140
140
120
100
Фиг. 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 - программный интерфейс приложения) или готовые модули для разработки ПО. В частном варианте реализации по меньшей мере часть объектов архитектуры ОС , часть политик безопасности из базы политик , а также часть средств настройки  могут быть общими (шаблонными) для различных ОС . В этом случае разработчик с использованием средств разработки  может настроить средства настройки , объекты архитектуры ОС  и политики безопасности из базы политик безопасности  путем добавления в упомянутый шаблон отсутствующих в шаблоне политик безопасности, объектов архитектуры ОС , а также средств настройки , необходимых для отражения особенностей ОС  или системы разработчика на базе ОС  и требований безопасности к ОС  или соответственно к системе разработчика на базе ОС , для которой упомянутый разработчик формирует монитор безопасности . Кроме того, часть данных из упомянутого шаблона может быть удалена, если она будет не нужна в ОС или соответственно в системе разработчика на базе ОС . Например, могут быть удалены некоторые политики безопасности и приложения.
120
260
100
120
260
100
100
120
100
120
110
100
120
110
100
270
100
270
100
110
100
Сформированный монитор безопасности  вместе с другими компонентами ОС  далее включают в операционную систему . При этом упомянутое включение монитора безопасности  и компонентов ОС  может быть осуществлено известными из уровня техники способами, например на этапе компиляции ОС  с использованием компилятора ОС  или путем установки монитора безопасности  в ОС . Как упоминалось ранее, монитор безопасности  может быть частью ядра ОС  или отдельным приложением ОС . Монитор безопасности  исполняется в привилегированном режиме ядра ОС . Для ОС  также может быть создан установочный образ ОС , необходимый для установки ОС  на компьютерные устройства конечных пользователей. Установочный образ ОС  может быть, например, архивом, исполняемым файлом или установочным пакетом. Установочный пакет представляет собой файл архива, в который входят файлы ОС , управляющие файлы и опционально файлы для настройки процесса установки ОС . Кроме того, в установочный пакет могут входить файлы системы разработчика на базе ОС . Упомянутые файлы могут быть представлены в исходном коде, в промежуточном коде или в исполняемом коде.
Фиг. 3
200
310
210
121
121
240.
121
240
100
320
210
121
220
330
220
340
220
221
221
350
210
120
221
На  представлен способ формирования монитора безопасности . На шаге  с использованием средства формирования  анализируют политики безопасности из базы политик . Упомянутый анализ заключается, в частности, в сопоставлении политик безопасности  и объектов архитектуры ОС Например, будут определены процессы, для которых используется упомянутая политика безопасности. Кроме того, могут быть выбраны лишь те политики безопасности , которые соответствуют существующим процессам в рамках архитектуры ОС  или системы разработчика на базе ОС . Далее на шаге  с использованием средства формирования  выполняют выбор политик безопасности из базы политик  для соответствующих средств настройки  и, на шаге , осуществляют передачу по меньшей мере одной выбранной политики безопасности соответствующему средству настройки . После этого на шаге  с использованием средств настройки  выполняют настройку модулей проверки политик . Упомянутая настройка заключается, в частности, в добавлении выбранных политик безопасности в модули проверки политик . В итоге на шаге  с использованием средства формирования  формируют монитор безопасности  с использованием настроенных модулей проверки политик  на основании результатов анализа.
Таким образом, заявленное изобретение позволяет решить заявленную техническую проблему и достичь заявленные технические результаты, а именно повысить безопасность ОС при обмене сообщениями межпроцессного взаимодействия, передаваемыми процессами приложений ОС за счет формирования монитора безопасности, предназначенного для контроля доставки сообщений с использованием политик безопасности, а также обеспечить контроль доставки сообщений межпроцессного взаимодействия, передаваемых процессами приложений ОС, в соответствии с политиками безопасности путем формирования монитора безопасности, обеспечивающего упомянутый контроль.
120
120
221
120
В частном варианте реализации монитор безопасности  формируют путем создания кода монитора безопасности , где код может быть исходным кодом, промежуточным кодом или исполняемым кодом. В этом варианте реализации модули проверки политик  также являются участками кода, включаемыми в код монитора безопасности .
Описание политик безопасности
В частном варианте реализации политики безопасности используют по меньшей мере одну из следующих моделей:
базовые операции;
конечный автомат;
временной автомат;
ролевое управление доступом;
мандатный контроль целостности;
регулярные выражения;
дискретные события (англ. 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
121
На примере языка PSL, с использованием которого могут быть заданы политики безопасности , указание на процесс , являющийся источником запроса , может содержаться в переменной scr. Указание на процесс , являющийся получателем запроса  может содержаться в переменной dst. Соответственно, именно упомянутый анализ политики безопасности , написанной на языке PSL, позволит определить указанные объекты архитектуры ОС, для которых будет применяться указанная политика безопасности.
121
240
121
В другом частном варианте реализации анализ политик безопасности  также включает проверку типов объектов архитектуры ОС , а также анализ на ошибки в политиках безопасности .
120
120
240
221
110
140
120
240
140
240
120
140
221
140
Результаты упомянутого анализа учитываются при формировании монитора безопасности . Например, в мониторе безопасности  могут быть записаны условия применения политик безопасности - перечень объектов архитектуры ОС , в частности, процессов, и соответствующие указанному перечню политики безопасности, а также модули проверки политик . Поэтому, при получении от ядра ОС  сообщения , сформированный монитор безопасности  определяет объекты архитектуры ОС , участвующие в обмене сообщением , после чего определяет политики безопасности, применимые к указанным объектам архитектуры ОС . После чего монитор безопасности  передает сообщения  модулям проверки политик , соответствующим указанным политикам безопасности, для вынесения решения о способе контроля доставки сообщения .
120
221
220
В еще одном частном варианте реализации выполняют синтаксический анализ путем построения синтаксического дерева для кода монитора безопасности , при этом включают в синтаксическое дерево код модулей проверки политик , сформированных по меньшей мере одним средством настройки .
140
140
131
131
Политики безопасности могут использовать базовые операции, разрешающие или запрещающие передачу сообщения  при условии совпадения параметров сообщения  (например, имя запускаемого процесса или фактические аргументы вызываемого метода) с данными, указанными в политике безопасности. Например, политика безопасности может определить, что процесс  может получать любые сообщения, но при этом процессу  запрещено отправлять сообщения.
140
Политики безопасности также могут использовать конечный автомат, где политика безопасности определяет разрешение или запрет доставки сообщения  в зависимости от состояния конечного автомата и в соответствии с таблицей переходов состояний конечного автомата.
Модель временных автоматов (англ. Timed automata), и в частности временной автомат типа ERA (англ. Event-recording automata), является частным случаем конечных автоматов. В данной модели дополнительно для каждого сообщения задают параметр времени (таймер), равный времени с момента последнего получения этого сообщения. Например, переход из одного состояния конечного автомата в другое состояние может быть осуществлен, если сообщение было получено спустя время, определенное таймером.
140
120
240
140
131
132
Модель мандатного контроля целостности (англ. 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
120
140
122
122
120
122
150
122
122
122
В еще одном частном варианте реализации с использованием средства формирования  дополнительно включают в монитор безопасности  контекст  монитора безопасности , при этом монитор безопасности  осуществляет контроль доставки сообщения  дополнительно с учетом упомянутого контекста , где контекст  монитора безопасности  содержит значения параметров политик безопасности. В другом частном варианте реализации монитор безопасности дополнительно предназначен для изменения контекста  с учетом решений  на основании политик безопасности. В зависимости от используемых политиками безопасности упомянутых моделей контекст  может содержать различные параметры политик безопасности. Например, для политик безопасности на основе модели мандатного контроля целостности контекст  будет содержать значения уровней целостности и уровней доступа к защищаемым объектам. Для политик безопасности на основе конечного автомата контекст  будет содержать текущее значение состояния конечного автомата и таблицу переходов конечного автомата.
140
120
140
131
132
140
120
121
120
120
В частном варианте реализации в случае, если сообщению  соответствуют по меньшей мере две политики безопасности, дополнительно вычисляют общее решение для упомянутых политик безопасности путем конъюнкции решений для каждой из упомянутых политик безопасности, при этом монитор безопасности  осуществляет контроль доставки сообщения  дополнительно с учетом упомянутого общего решения. Когда процесс  или процесс  инициирует взаимодействие путем отправки сообщения , монитор безопасности  вызывает все политики безопасности из базы политик , связанные с этим конкретным взаимодействием. Если все политики безопасности вынесли решение «разрешено», то с использованием монитора безопасности  выносят общее решение «разрешено». Если хотя бы одна политика вынесла решение «запрещено», с использованием монитора безопасности  выносят общее решение «запрещено».
221
150
120
В еще одном частном варианте реализации настройка модуля проверки политик  включает создание кода, обеспечивающего вынесение решения  по запросу монитора безопасности  для политики безопасности при выполнении упомянутой политики безопасности.
120
140
150
140
В частном варианте реализации монитор безопасности  осуществляет контроль доставки сообщения  дополнительно с учетом решений  на основании политик безопасности, связанных с упомянутыми сообщениями .
Фиг. 4
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
Персональный компьютер  в свою очередь содержит жесткий диск  для чтения и записи данных, привод магнитных дисков  для чтения и записи на сменные магнитные диски  и оптический привод  для чтения и записи на сменные оптические диски , такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск , привод магнитных дисков , оптический привод  соединены с системной шиной  через интерфейс жесткого диска , интерфейс магнитных дисков  и интерфейс оптического привода  соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера .
27
29
31
56
23
55
Настоящее описание раскрывает реализацию системы, которая использует жесткий диск , сменный магнитный диск  и сменный оптический диск , но следует понимать, что возможно применение иных типов компьютерных носителей информации , которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине  через контроллер .
20
36
35
37
38
39
20
40
42
20
46
47
23
48
47
Компьютер  имеет файловую систему , где хранится записанная операционная система , а также дополнительные программные приложения , другие программные модули  и данные программ . Пользователь имеет возможность вводить команды и информацию в персональный компьютер  посредством устройств ввода (клавиатуры , манипулятора «мышь» ). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе  через последовательный порт , который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор  или иной тип устройства отображения также подсоединен к системной шине  через интерфейс, такой как видеоадаптер . В дополнение к монитору , персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
20
49
49
20
Фиг. 4
Персональный компьютер  способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами . Удаленный компьютер (или компьютеры)  являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера , представленного на . В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
50
20
50
51
20
54
54
23
46
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN)  и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях (также — информационных системах), внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер  подключен к локальной сети  через сетевой адаптер или сетевой интерфейс . При использовании сетей персональный компьютер  может использовать модем  или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем , который является внутренним или внешним устройством, подключен к системной шине  посредством последовательного порта . Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В соответствии с описанием, компоненты, этапы исполнения, структура данных, описанные выше, могут быть выполнены, используя различные типы операционных систем, компьютерных платформ, программ.
В заключение следует отметить, что приведенные в описании сведения являются примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.