Паттерн Distrustful Decomposition

Описание

При использовании монолитного приложения появляется необходимость дать все необходимые для его работы привилегии одному процессу. Эту проблему решает паттерн Distrustful Decomposition.

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

Использование паттерна Distrustful Decomposition уменьшает:

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

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

Privilege Reduction.

Контекст

Различные функции приложения требуют разного уровня привилегий.

Проблема

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

Решение

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

Структура

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

Работа

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

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

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

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

В универсальных ОС (например Linux, Windows) этот паттерн не использует ничего, кроме стандартной модели процессов/привилегий, уже существующей в этих ОС. Каждая программа выполняется в собственном пространстве процессов с потенциально разными привилегиями пользователя в каждом процессе, однако атака на ядро ОС снижает ценность применения этого паттерна.

Специфика применения этого паттерна при разработке под KasperskyOS состоит в том, что контроль над процессами и IPC возложен на микроядро, атака на которое сложна. Для контроля IPC используется модуль безопасности Kaspersky Security Module.

За счет использования механизмов KasperskyOS достигается высокий уровень надежности программной системы при том же или меньшем объеме усилий разработчика в сравнении с использованием этого же паттерна в программах под универсальные ОС.

Кроме этого, KasperskyOS предоставляет возможность гибкой настройки политик безопасности. При этом процесс задания и изменения политик безопасности потенциально независим от процесса разработки самих приложений.

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

Использование паттерна Distrustful Decomposition предполагает использование паттернов Defer to Kernel и Policy Decision Point.

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

Примеры реализации паттерна Distrustful Decomposition:

• Secure Logger
• Separate Storage

Источники

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

• 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

Пример Secure Logger

Пример Secure Logger демонстрирует использование паттерна Distrustful Decomposition для решения задачи разделения функциональности чтения и записи в журнал событий.

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

Цель безопасности в примере Secure Logger заключается в том, чтобы предотвратить возможность искажения или удаления информации в журнале событий. В примере для достижения этой цели безопасности используются возможности, предоставляемые KasperskyOS.

При рассмотрении системы журналирования можно выделить следующие функциональные шаги:

• генерация информации для записи в журнал;
• сохранение информации в журнал;
• чтение записей из журнала;
• предоставление записей в удобном для потребителя виде.

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

Для этого пример Secure Logger содержит четыре программы: Application, Logger, Reader и LogViewer.

• Программа Application инициирует создание записей в журнале событий, поддерживаемом программой Logger.
• Программа Logger создает записи в журнале и записывает их на диск.
• Программа Reader читает записи с диска для передачи программе LogViewer.
• Программа LogViewer передает записи пользователю.

IPC-интерфейс, который предоставляет программа Logger, предназначен только для записи в хранилище. IPC-интерфейс программы Reader предназначен только для чтения из хранилища. Архитектура примера выглядит следующим образом:

• Программа Application использует интерфейс программы Logger для сохранения записей.
• Программа LogViewer использует интерфейс программы Reader для чтения записей и предоставления их пользователю.

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

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

• Программа Application имеет возможность обращаться к программе Logger для создания новой записи в журнале событий.
• Программа LogViewer имеет возможность обращаться к программе Reader для чтения записей из журнала событий.
• Программа Application не имеет возможности обращаться к программе Reader для чтения записей из журнала событий.
• Программа LogViewer не имеет возможности обращаться к программе Logger для создания новой записи в журнале событий.

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

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

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

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

Пример Separate Storage

Пример Separate Storage демонстрирует использование паттерна Distrustful Decomposition для решения задачи раздельного хранения данных для доверенных и недоверенных приложений.

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

Пример Separate Storage содержит две пользовательские программы: UserManager и CertificateManager.

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

• Программа UserManager работает с данными из файла userlist.txt;
• Программа CertificateManager работает с данными из файла certificate.cer.

Каждая из этих программ использует собственный экземпляр программы VFS для доступа к отдельной файловой системе. При этом каждая программа VFS включает в себя драйвер блочного устройства, связанный с отдельным логическим разделом диска. Программа UserManager не имеет доступа к файловой системе программы CertificateManager и наоборот.

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

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

• Программа UserManager имеет доступ к файловой системе только через программу VfsUser.
• Программа CertificateManager имеет доступ к файловой системе через только через программу VfsCertificate.

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

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

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

Чтобы запустить пример на QEMU, перейдите в директорию с примером, соберите пример и выполните следующие команды:

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

Подготовка SD-карты для запуска на Raspberry Pi 4 B

Для запуска примера Separate Storage на Raspberry Pi 4 B необходимы следующие дополнительные действия:

• SD-карта, помимо загрузочного раздела с образом решения, должна также содержать 2 дополнительных раздела с файловой системой ext2 или ext3.
• первый дополнительный раздел должен содержать файл userlist.txt из директории ./resources/files/
• второй дополнительный раздел должен содержать файл certificate.cer из директории ./resources/files/