Паттерн Privilege Separation

Описание

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

Паттерн Privilege Separation является частным случаем паттерна Distrustful Decomposition.

Пример

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

Контекст

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

Проблема

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

Решение

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

Работа

Работа паттерна делится на две фазы:

• Pre-Authentication. Клиент еще не аутентифицирован. Он отправляет запрос к привилегированному мастер-процессу. Мастер-процесс создает дочерний процесс, лишенный привилегий (в том числе, доступа к файловой системе), который выполняет аутентификацию клиента.
• Post-Authentication. Клиент аутентифицирован и авторизован. Привилегированный мастер-процесс создает новый дочерний процесс, обладающий привилегиями, соответствующими правам клиента. Этот процесс отвечает за все дальнейшее взаимодействие с клиентом.

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

На этапе Pre-Authentication мастер-процесс может хранить состояние каждого непривилегированного процесса в виде конечного автомата и изменять состояние автомата при аутентификации.

Запросы дочерних процессов к мастер-процессу выполняются с использованием стандартных механизмов IPC. При этом контроль взаимодействий осуществляется с помощью модуля безопасности Kaspersky Security Module.

Следствия

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

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

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

Пример реализации паттерна Privilege Separation: Пример Device Access.

Источники

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

• 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

Пример Device Access

Пример Device Access демонстрирует использование паттерна Privilege Separation.

Архитектура примера

Пример содержит три программы: Device, LoginManager и Storage.

В этом примере программа Device обращается к программе Storage для получения информации и к программе LoginManager для авторизации.

Программа Device получает доступ к программе Storage только после успешной авторизации.

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

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

• Программа Device имеет возможность обращаться к программе LoginManager для авторизации.
• Вызовами метода GetInfo() программы Storage управляют методы модели безопасности Flow:
  • Конечный автомат, описанный в конфигурации объекта session, имеет два состояния: unauthenticated и authenticated.
  • Исходное состояние – unauthenticated.
  • Разрешены переходы из unauthenticated в authenticated и обратно.
  • Объект session создается при запуске программы Device.
  • При успешном вызове программой Device метода Login() программы LoginManager состояние объекта session изменяется на authenticated.
  • При успешном вызове программой Device метода Logout() программы LoginManager состояние объекта session изменяется на unauthenticated.
  • При вызове программой Device метода GetInfo() программы Storage проверяется текущее состояние объекта session. Вызов разрешается, только если текущее состояние объекта – authenticated.

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

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

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

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