Паттерн Defer to Kernel

Описание

Паттерн Defer to Kernel предполагает использование преимущества контроля разрешений на уровне ядра ОС.

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

Альтернативные названия

Policy Enforcement Point (PEP), Protected System, Enclave.

Контекст

Паттерн Defer to Kernel применим, если система имеет следующие характеристики:

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

Проблема

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

Решение

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

Структура

Работа

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

Рекомендации по реализации

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

• Изоляция

  Необходимо обеспечить полную и гарантированную изоляцию процессов.

• Невозможность обойти ядро

  Абсолютно все IPC-взаимодействия должны контролироваться ядром.

• Самозащита ядра

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

• Доказуемость

  Требуется определенный уровень гарантий безопасности и надежности в отношении ядра.

• Возможность внешнего вычисления разрешений о доступе

  Необходимо, чтобы разрешения о доступе вычислялись на уровне ОС, а не были реализованы в прикладном коде.

  Для этого, в частности, необходимо предоставить инструменты для описания политик доступа, чтобы политики безопасности были отделены от бизнес-логики.

Особенности реализации в KasperskyOS

Ядро KasperskyOS гарантирует изоляцию процессов и представляет собой Policy Enforcement Point (PEP).

Связанные паттерны

Паттерн Defer to Kernel является частным случаем паттернов Distrustful Decomposition и Policy Decision Point. Паттерн Policy Decision Point определяет абстрактный процесс, перехватывающий все запросы к ресурсам и проверяющий их на соответствие заданной политике безопасности. Специфика паттерна Defer to Kernel в том, что эту проверку выполняет ядро ОС – это более надежное и портируемое решение, сокращающее время разработки и тестирования.

Следствия

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

Кроме этого, появляется возможность доказать безопасность решения в целом, доказав правильность работы ядра. Сложность доказуемости правильной работы кода нелинейно растет с увеличением его размера. Паттерн Defer to Kernel минимизирует объем доверенного кода – при условии, что ядро ОС невелико.

Примеры реализации

Пример реализации паттерна Defer to Kernel: Пример Defer to Kernel.

Источники

Паттерн Defer to Kernel подробно рассмотрен в следующих работах:

• Chad Dougherty, Kirk Sayre, Robert C. Seacord, David Svoboda, Kazuya Togashi (JPCERT/CC), "Secure Design Patterns" (March-October 2009). Software Engineering Institute. https://resources.sei.cmu.edu/asset_files/TechnicalReport/2009_005_001_15110.pdf
• Dangler, Jeremiah Y., "Categorization of Security Design Patterns" (2013). Electronic Theses and Dissertations. Paper 1119. https://dc.etsu.edu/etd/1119
• Schumacher, Markus, Fernandez-Buglioni, Eduardo, Hybertson, Duane, Buschmann, Frank, and Sommerlad, Peter. "Security Patterns: Integrating Security and Systems Engineering" (2006).

Пример Defer to Kernel

Пример Defer to Kernel демонстрирует использование паттернов Defer to Kernel и Policy Decision Point.

Пример Defer to Kernel содержит три пользовательские программы: PictureManager, ValidPictureClient и NonValidPictureClient.

В этом примере программы ValidPictureClient и NonValidPictureClient обращаются к программе PictureManager для получения информации.

Только программе ValidPictureClient разрешено взаимодействие с программой PictureManager.

Ядро KasperskyOS гарантирует изоляцию запущенных программ (процессов).

Контроль взаимодействия программ в KasperskyOS вынесен в модуль безопасности Kaspersky Security Module. Эта подсистема анализирует каждый отправляемый запрос и ответ и на основе заданной политики безопасности выносит решение: разрешить или запретить его доставку.

Политика безопасности в примере Defer to Kernel имеет следующие особенности:

• Программе ValidPictureClient явно разрешено взаимодействие с программой PictureManager.
• Программе NonValidPictureClient взаимодействие с программой PictureManager не разрешено явно. Таким образом, это взаимодействие запрещено (принцип Default Deny).

Динамическое создание IPC-каналов

Пример также демонстрирует возможность динамического создания IPC-каналов между процессами. Динамическое создание IPC-каналов осуществляется с помощью сервера имен – специального сервиса ядра, представленного программой NameServer. Возможность динамического создания IPC-каналов позволяет изменять топологию взаимодействия программ "на лету".

Любая программа, которой разрешено взаимодействие с NameServer по IPC, может зарегистрировать в сервере имен свои интерфейсы. Другая программа может запросить у сервера имен зарегистрированные интерфейсы, после чего осуществить подключение к нужному интерфейсу.

При этом все взаимодействия по IPC (даже созданные динамически) контролируются с помощью модуля безопасности.

Файлы примера

Код примера и скрипты для сборки находятся по следующему пути:

Сборка и запуск примера

См. "Сборка и запуск примеров".