🛡️ ОБЯЗАТЕЛЬНЫЙ КОНТРОЛЬ ДОСТУПА LINUX // MAC-СИСТЕМЫ: APPARMOR, SELINUX, TOMOYO/AKARI

D2 · 7 Апр 2025

:smile66: О ЧЕМ СТАТЬЯ

В этой статье рассмотрим, как настраивается AppArmor в Debian Linux: как контролировать доступ приложений к файлам, как создавать свои файлы профилей для новых приложений, готовые профили от Debian и Whonix/Kicksecure, возможность использования полной системной политики (аналогично SELinux в Android), реализация контроля доступа на основе ролей (RBAC), списки контроля доступа (ACL) и кратко коснёмся SELinux, TOMOYO/AKARI MAC, RBAC от GRSecurity и того, как работают Pledge и Unveil в OpenBSD.

:zns3: ВВЕДЕНИЕ

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

MAC на основе пути к файлу довольно легкая форма управления доступом, которая предлагает разрешения на основе пути к файлам. К нему относятся AppArmor (рассматривается как более простая альтернатива SELinux) и TOMOYO/AKARI. Обе эти системы отличаются простотой использования и реализации, требуя очень мало зависимостей. Плюсом является то, что MAC на основе путей может быть реализован на гораздо более широком спектре файловых систем, в отличие от альтернативы на основе меток. Недостатком этого стиля управления доступом является то, что разрешения не переносятся вместе с файлами.

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

APPARMOR

AppArmor активно защищает операционную систему и приложения от внешних и внутренних угроз и даже может смягчить или ограничить "0day", применяя к каждому приложению определенный набор правил. По умолчанию доступ запрещен, если в профиле не указано иное. По умолчанию AppArmor включает несколько политик, а благодаря сочетанию расширенного статического анализа и обучения AppArmor, даже для очень сложных приложений в течение нескольких часов может быть успешно развернут профиль. AppArmor дополняет, а не заменяет дискреционный контроль доступа (DAC, о котором шла речь в предыдущей статье), благодаря чему невозможно предоставить процессу больше привилегий, чем он имел изначально.

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

Каждое нарушение политики приводит к появлению сообщения в системном журнале логов, а сам AppArmor может быть настроен на уведомление о нарушениях, появляющееся на рабочем столе в режиме реального времени. Для упрощения настройки системы в состав AppArmor уже входит набор профилей по умолчанию, которые запускаются после установки. Если же готового профиля не нашлось, то создать его помогут специальные утилиты "aa-genprof" и "aa-logprof". Разработчики AppArmor считают, что безопасность не должна идти в ущерб простоте, ведь чем сложнее система, тем больше вероятность ее неправильной конфигурации.

AppArmor обеспечивает ряд преимуществ:

[+] Защита операционной системы и приложений от внешних и внутренних угроз, включая ограничение или нейтрализацию "0day";

[+] Смягчает последствия эксплуатации неизвестных недостатков приложений;

[+] Политики безопасности AppArmor определяют, к каким системным ресурсам и с какими привилегиями могут обращаться отдельные приложения. Например: доступ к сети, доступ к сокетам, разрешения на чтение, запись или выполнение файлов по определенным путям.

:zns5: УСТАНОВКА APPARMOR

Сначала установим инструменты AppArmor. В некоторых дистрибутивах Linux они устанавливаются по умолчанию вместе с некоторыми профилями, как, например, в Ubuntu или OpenSUSE. В Debian Linux их можно установить с помощью команды:
Bash: Скопировать в буфер обмена

Код:

sudo apt install apparmor apparmor-utils
sudo systemctl enable apparmor
sudo systemctl start apparmor

Для включения AppArmor необходимо добавить дополнительные параметры загрузки. Если в качестве загрузчика используется Grub, то необходимо отредактировать файл "/etc/default/grub" и добавить в строку "GRUB_CMDLINE_LINUX_DEFAULT=" следующие параметры, не ставя запятых при перечислении:
Код: Скопировать в буфер обмена
apparmor=1 security=apparmor

Затем необходимо обновить конфигурацию Grub (после этого также следует перезагрузиться):
Bash: Скопировать в буфер обмена
sudo update-grub

Узнать, включен ли AppArmor, можно с помощью команды (если показывает Y, то включен):
Bash: Скопировать в буфер обмена
cat /sys/module/apparmor/parameters/enabled

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

КОНЦЕПЦИЯ ПРОФИЛЕЙ APPARMOR

Профили AppArmor загружаются при запуске системы. Режим профиля определяет обработку правил если произойдет какое-то событие. AppArmor имеет несколько режимов работы профилей:

[+] Enforce Mode - ядро обеспечивает выполнение правил, указанных в файле профиля, все нарушения блокируются и записываются в файл журнала логов. Проще говоря, операции, нарушающие политику профиля, будут заблокированы;

[+] Complain Mode - режим обучения, AppArmor будет только регистрировать нарушения, ничего не блокируя. Он идеально подходит для тестирования профилей. Возможные ошибки или нарушения доступа могут быть обнаружены и исправлены до перевода профиля в принудительный режим;

[+] Unconfined Mode - ограничения не применяются.

AppArmor предоставляет инструмент командной строки для проверки загруженных профилей. Некоторые профили поставляются в режиме жалоб, чтобы пользователи могли протестировать их, выбрать подходящие и при необходимости улучшить. Можно выполнить команду "aa-status", чтобы увидеть список всех загруженных профилей для приложений и процессов вместе с их статусом:
Bash: Скопировать в буфер обмена

Код:

sudo aa-status

apparmor module is loaded.
25 profiles are loaded.
13 profiles are in enforce mode.
 ...
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

После выполнения команды мы видим, что загружено 25 профилей, 13 из которых находятся в принудительном режиме (Enforce Mode), и 0 в режиме обучения (Complain Mode). При дальнейшем рассмотрении списка можно увидеть, сколько процессов попадает под наши профили. В стандартной установке не нашлось профилей для некоторых процессов, если установить или создать такие профили, то они могут быть запущены в режиме блокировки, и определенные процессы не смогут получить доступ к ресурсам которые не указаны в профиле. Также могут быть процессы, которые не настроены, это связано с тем, что они были запущены до запуска AppArmor, чтобы ими можно было управлять, необходимо просто перезапустить их. Большинство стандартных профилей Debian предназначены только для серверных утилит и браузеров, если мы хотим контролировать другие программы, то должны добавить готовые профили или создать их самостоятельно.

Папка AppArmor "/etc/apparmor.d" имеет следующую структуру:

[+] "/usr.bin.профиль" - файлы профиля для программы. Файлы именуются через точку, что соответствует пути к ним;

[+] "/local/" - каталог для переопределений или расширений профилей AppArmor;

[+] "/abstractions/" - механизм абстракций представляет собой гибкий способ группировки общих требований к доступам AppArmor для всех профилей;

[+] "/tunables/" - каталог переменных;

[+] "/disable/" - каталог, содержащий символические ссылки на отключенные профили;

[+] "/force-complain/" - каталог профилей с принудительным режимом жалоб.

СИНТАКСИС ПРОФИЛЯ APPARMOR

Доступны следующие разрешения:

[+] "r" - разрешить чтение;

[+] "w" - разрешить запись;

[+] "a" - разрешить запись в конец файла;

[+] "px" - разрешить запуск новых процессов, если для них существует профиль;

[+] "Px" - разрешить запуск новых процессов, если для них есть профиль, и очистить переменные окружения;

[+] "ix" - разрешить запуск нового процесса под профилем текущего процесса;

[+] "m" - разрешить загрузку в память и запуск исполняемых файлов;

[+] "l" - разрешить создание символических ссылок на исполняемые файлы;

[+] "k" - разрешить блокировку файлов;

[+] "ux" - не контролировать новые процессы;

[+] "Ux" - не контролировать новые процессы и очистить переменные окружения.

Этих разрешений достаточно для управления, но кроме списка файлов и их разрешений, файл профиля содержит директивы "include" и "capability":

[+] "include" - позволяет включать другие файлы с разрешениями, они находятся в папке "/etc/apparmor.d/abstractions/". Это те же части профиля, со списком файлов и разрешений. Они облегчают создание новых профилей;

[+] "capability" - записи разрешений определяют, какие разрешения может использовать ограниченный процесс. Программа может обращаться к ядру, используя системные вызовы, и Apparmor контролирует и эти вызовы. Просмотреть все доступные вызовы можно с помощью команды "man capabilities";

[+] Записи пути - описывает, к каким файлам в файловой системе имеет доступ приложение;

[+] Сетевые записи - определяет тип соединения. Например: "tcp".

В качестве примера рассмотрим профиль "/etc/apparmor.d/bin.ping":
Код: Скопировать в буфер обмена

Код:

#include <tunables/global>
/bin/ping flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability net_raw,
  capability setuid,
  network inet raw,
 
  /bin/ping mixr,
  /etc/modules.conf r,
}

"#include <tunables/global>" - включает операторы из других файлов. Это позволяет разместить в одном общем файле операторы, относящиеся к нескольким приложениям. "/bin/ping flags=(complain)" - путь к программе, управляемой профилем, также задающий режим жалоб/обучения. "capability net_raw" позволяет приложению получить доступ к возможностям "CAP_NET_RAW". "/bin/ping mixr" - разрешает приложению доступ к чтению и выполнению файла.

СОЗДАНИЕ ПРОФИЛЕЙ APPARMOR

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

Для создания профиля мы будем использовать следующие инструменты:

[+] "aa-autodep" - инициализирует профиль AppArmor (используется при ручном написании профилей);

[+] "aa-genprof" - выполняет наполнение профиля AppArmor правилами и разрешениями (умеет самостоятельно создавать профиль и инициализировать его);

[+] "aa-logprof" - вносит изменения в профиль AppArmor.

Новые профили AppArmor могут быть созданы сразу с помощью "aa-genprof" или сначала с помощью "aa-autodep", а затем настроены с помощью "aa-genprof". Правила создаются в интерактивном режиме с помощью инструмента "aa-logprof", входящего в состав пакета AppArmor. Профиль создается в режиме жалоб, но после тестирования его можно перевести в принудительный режим с помощью команды "aa-enforce". В этом случае политика, заданная правилами соответствующего профиля, будет строго соблюдаться. При необходимости дополнительные правила могут быть добавлены с помощью команды "aa-logprof", а в режим жалобы профиль может быть возвращен командой "aa-complain".

Важно отметить, что "aa-logprof" также содержит запрещающие правила, в которых нет особой необходимости, поскольку базовая логика AppArmor запрещает все, что не разрешено правилом в явном виде. Однако запрещающие правила служат дополнительным целям, например, запрещающие правила имеют приоритет над разрешающими. Они часто используются во многих абстракциях, расположенных в каталоге "/etc/apparmor.d/abstractions", чтобы блокировать любой общесистемный доступ к важным папкам или файлам, несмотря на другие профили AppArmor. Это гарантирует, что случайно созданные правила не дадут профилю лишних опасных разрешений.

Одной из наиболее сложных проблем является определение тех утилит, сервисов и программ, которые требуют защиты. Здесь на помощь приходит утилита "aa-unconfined" из набора инструментов AppArmor. Не секрет, что наибольшую опасность представляют программы, доступ к которым осуществляется по сети. Утилита предоставит список запущенных программ, имеющих открытые TCP и UDP порты, а также укажет наличие или отсутствие профилей для этих программ (опция "--paranoid" рядом с этой командой дополнит список всеми процессами из "/proc", имеющими TCP и UDP порты):
Bash: Скопировать в буфер обмена

Код:

sudo aa-unconfined

2393 /usr/sbin/avahi-daemon not confined
3562 /usr/sbin/cupsd not confined
5380 /usr/sbin/hpiod not confined
6492 /usr/sbin/mysqld not confined
6524 /usr/lib/postfix/master confined
6824 /usr/sbin/dovecot not confined

Процесс автоматического создания профиля выглядит следующим образом: мы используем "aa-genprof" для мониторинга активности приложения во время выполнения, чтобы AppArmor узнал все, что ему необходимо. В процессе нам будет предложено подтвердить и выбрать поведение, которое требуется при определенных обстоятельствах. После создания профиля при необходимости можно использовать утилиту "aa-logprof" для внесения корректировок в ходе тестирования в режиме жалоб, если возникнут какие-либо проблемы. После редактирования профиля его следует перезагрузить.

Сначала установим демон аудирования и запустим его:
Bash: Скопировать в буфер обмена

Код:

sudo apt install auditd
sudo systemctl enable auditd
sudo systemctl start auditd

Проведем профилирование программы, чтобы определить, какие файлы и доступы ей нужны, чтобы добавить их в профиль (в нашем случае для примера "man"):
Bash: Скопировать в буфер обмена
sudo aa-genprof man

Теперь необходимо запустить программу в отдельном окне терминала и выполнить все действия, которые она может делать, или только те, которые мы собираемся использовать, проще говоря, начать пользоваться ею как обычно. После этого необходимо нажать кнопку S (Scan) в первом окне терминала, в котором происходит работа "aa-autodep".:
Bash: Скопировать в буфер обмена
man cat

В процессе профилирования программа будет задавать вопросы о разрешении тех или иных действий или доступа к определенным путям (ответы на вопросы чередуются между Inherit (Наследовать) и Allow (Разрешить)).

ответы на вопросы чередуются между Inherit (Наследовать) и Allow (Разрешить)

Если интересно предварительно посмотреть на профиль, можно нажать V (View), после всех ответов, если все устраивает, нажмем S (Save), а затем F (Finish) для завершения работы утилиты.

AppArmor определит, к чему обращается программа, и добавит все в профиль с определенными разрешениями в зависимости от ответов на заданные вопросы. Если затем потребуется внести дополнительные правки в профиль необходимо воспользоваться "aa-logprof". Однако создание качественных профилей по прежнему осуществляется путем ручного написания политик.

Каждый профиль должен быть загружен в AppArmor, прежде чем он начнет работать. Включим принудительный режим, после чего проверим, работает ли программа (необходимо указать полный путь к профилю программы, в нашем случае "/etc/apparmor.d/usr.bin.man"):
Bash: Скопировать в буфер обмена
sudo aa-enforce /etc/apparmor.d/usr.bin.man

sudo aa-enforce /etc/apparmor.d/usr.bin.man

Если в профиль были внесены изменения, то для вступления изменений в силу его необходимо перезагрузить, для этого необходимо выполнить команду:
Bash: Скопировать в буфер обмена
sudo apparmor_parser -a /etc/apparmor.d/профиль.программы

Перезагрузить все профили можно с помощью команды:
Bash: Скопировать в буфер обмена
sudo systemctl reload apparmor

ГОТОВЫЕ ПРОФИЛИ APPARMOR

Debian предоставляет различные готовые профили AppArmor, в том числе и экспериментальные, для широкого спектра приложений и процессов. Они упакованы в: "apparmor-profiles" и "apparmor-profiles-extra", и расположены по умолчанию в каталоге "/etc/apparmor.d/", приложения также могут автоматически устанавливать свои собственные профили в этот каталог. Некоторые профили находятся в режиме жалоб, поскольку сопровождающие Debian не считают их достаточно зрелыми. Экспериментальные профили находятся в каталоге "/usr/share/apparmor/extra-profiles", но не следует ожидать, что эти профили будут работать из коробки, если они используются, может потребоваться ручное редактирование или использование "aa-logprof".

Начнем с установки профилей в Debian Linux:
Bash: Скопировать в буфер обмена
sudo apt install apparmor-profiles apparmor-profiles-extra

Дополнительные экспериментальные профили, не включенные по умолчанию "apparmor-profiles-extra", находятся в папке "/usr/share/apparmor/extra-profiles/". Посмотреть содержимое этой папки можно командой:
Bash: Скопировать в буфер обмена
ls /usr/share/apparmor/extra-profiles/

Имеются как обычные серверные профили, так и профили для десктопных приложений, таких как браузеры и почтовые клиенты. Если какое-либо из этих приложений используется и есть желание включить для него профиль, необходимо скопировать этот профиль в стандартный каталог профилей:
Bash: Скопировать в буфер обмена
sudo cp /usr/share/apparmor/extra-profiles/профиль /etc/apparmor.d/

Или можно скопировать все экспериментальные профили:
Bash: Скопировать в буфер обмена
sudo cp /usr/share/apparmor/extra-profiles/* /etc/apparmor.d

После этого, если нет уверенности, что профиль будет работать корректно, можно включить его в режиме жалоб:
Bash: Скопировать в буфер обмена
sudo aa-complain /etc/apparmor.d/профиль

Если профиль протестирован или есть уверенность, что он работает корректно, можно включить его в принудительном режиме:
Bash: Скопировать в буфер обмена
sudo aa-enforce /etc/apparmor.d/профиль

Если необходимо отключить конкретный профиль, нужно найти его имя в каталоге "/etc/apparmor.d/" и выполнить команду:
Bash: Скопировать в буфер обмена
sudo aa-disable /etc/apparmor.d/профиль

Можно также включить все профили, например, для тестирования:
Bash: Скопировать в буфер обмена
sudo aa-enforce /etc/apparmor.d/*

Или отключить все профили Apparmor, если это необходимо:
Bash: Скопировать в буфер обмена
sudo aa-disable /etc/apparmor.d/*

ПРОФИЛИ WHONIX/KICKSECURE

Whonix/Kicksecure предоставляют профили, которые можно дополнительно использовать вместе с профилями Debian:

[+] "apparmor-profile-hexchat" - профиль AppArmor для ограничения IRC HexChat;

[+] "apparmor-profile-thunderbird" - профиль AppArmor для ограничения Thunderbird. Этот профиль является расширением исходного профиля Debian AppArmor;

[+] "apparmor-profile-torbrowser" - профиль AppArmor для ограничения Tor Browser;

[+] "apparmor-profiles-kicksecure" - мета-пакет, объединяющий все вышеперечисленные профили.

Установка в Debian Linux. Для начала скачаем ключ подписи репозитория:
Bash: Скопировать в буфер обмена
wget https://www.kicksecure.com/keys/derivative.asc

Затем добавим ключ подписи:
Bash: Скопировать в буфер обмена
sudo cp ~/derivative.asc /usr/share/keyrings/derivative.asc

Добавим репозиторий для Debian 12 Bookworm:
Bash: Скопировать в буфер обмена

echo "deb [signed-by=/usr/share/keyrings/derivative.asc] https://deb.kicksecure.com bookworm main contrib non-free" | sudo tee /etc/apt/sources.list.d/derivative.list

Если нет желания возиться с этими командами, можно воспользоваться утилитой "extrepo", Kicksecure присутствует в ней:
Bash: Скопировать в буфер обмена

Код:

sudo apt install extrepo
sudo extrepo enable kicksecure

Обновим репозитории пакетов и установим:
Bash: Скопировать в буфер обмена
sudo apt update && sudo apt install apparmor-profiles-kicksecure

Затем можно включить необходимые профили:
Bash: Скопировать в буфер обмена
sudo aa-enforce /etc/apparmor.d/профиль

ПОЛНАЯ СИСТЕМНАЯ ПОЛИТИКА APPARMOR

Еще один шаг вперед это создание полной системной MAC политики AppArmor, ограничивающей все процессы пользовательского пространства, как это сделано в Android с помощью SELinux. AppArmor часто развертывается с помощью целевой политики, применяемой только к приложениям, которые считаются чувствительными к безопасности, но большинство других процессов (включая init) запускаются без ограничений. AppArmor также может использоваться для формирования полной системной политики. Это важно и необходимо для создания надежной модели безопасности, реализующей принцип наименьших привилегий. В сочетании с технологиями песочниц (например, bubblewrap), усилением безопасности ядра и виртуализацией можно создать глубоко эшелонированную защиту системы.

Идея состоит в том, чтобы ограничить все процессы пользовательского пространства в системе. AppArmor для "init", загрузка SystemD в "initramfs", который затем применяется ко всем остальным процессам. Для многих системных служб и приложений потребуются специальные политики, чтобы все процессы порождались процессом инициализации и каждый процесс (кроме процессов ядра) автоматически ограничивался, включая все "/" (/usr/bin и т.д.). Таким образом, при установке сомнительной программы она по умолчанию будет максимально ограничена, и если она попытается выполнить недокументированные или вредоносные действия, то будет запрещена к выполнению, а пользователь получит уведомление.

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

Концепция заключается в интеграции со сценариями, запускающими "init" в среде "initramfs" для загрузки в ядро политики, которая будет применяться к "PID 1" в системе. Однако это требует очень большой работы и серьезного тестирования. На данный момент ни в одном дистрибутиве Linux нет ничего приближенного, кроме Android (также по сути это присутствует в отечественном Astra Linux, но только в лицензионных версиях), но приложения для Android гораздо проще и содержательнее по дизайну, что делает возможным общесистемный SELinux. Все, что мы имеем на данный момент в этом направлении, это потрясающая реализация Pledge и Unveil в OpenBSD, разработка "apparmor-profile-everything", тестируемая в Whonix/Kicksecure, и RBAC от GRSecurity, в котором, пожалуй, наиболее развито автоматическое профилирование, но, несмотря на запуск всех программ и использование всех необходимых функций, в нем есть много непонятных ошибок, которые легко исправить (но, к сожалению, GRSecurity поставляется только по лицензии).

APPARMOR-PROFILE-EVERYTHING ОТ WHONIX/KICKSECURE

Это не один профиль, а набор профилей, системных файлов и связанных с ними скриптов. Вместе эти элементы работают как единое целое, ограничивая систему, начиная с "init". Ограничения включают: процесс инициализации SystemD и все порождаемые им дочерние процессы, "apt", используя оболочку с именем "rapt", а также блокировку файлов и каталогов, которые могут представлять значительный риск для безопасности.

Установка в Debian (при условии, что репозиторий включен в соответствии с примером, приведенным в разделе "Профили Whonix/Kicksecure")
Bash: Скопировать в буфер обмена
sudo apt install apparmor-profile-everything

Примечание: "apparmor-profile-everything" все еще находится в стадии разработки и тестирования. Хотя он уже может предотвратить запуск некоторых вредоносных программ, по умолчанию он пока не блокирует опасные модификации файлов.

"initramfs" информируется через хук, так что профиль "init-systemd" выполняется непосредственно перед запуском SystemD. Хук "initramfs-tools" достаточно прост для понимания. Его назначение убедиться в том, что "initramfs" знает, как запустить "init-systemd".

Он также содержит оболочку для ограничения "apt", поскольку "apt" требует прав доступа, которыми можно злоупотреблять для обхода ограничений. При обновлении или установке приложений необходимо использовать команду "rapt" вместо "apt" или "apt-get". Утилита "rapt" полностью ограничивает "apt", допуская при этом нормальное использование.

APPARMOR ДЛЯ УПРАВЛЕНИЯ ДОСТУПОМ НА ОСНОВЕ РОЛЕЙ (RBAC)

Для реализации RBAC в AppArmor используется PAM модуль "pam_apparmor", который прикрепляет профили к пользователям. Он может быть очень гибко интегрирован в любое приложение с поддержкой PAM с помощью соответствующего конфигурационного файла "/etc/pam.d/". Этот модуль был создан для поддержки нескольких различных сценариев использования, включая управление доступом на основе ролей (RBAC) и многоуровневый стиль безопасности (MLS). Например, AppArmor можно использовать, когда пользователи объединены в различные группы, такие как сотрудники или администраторы. Предоставляя общие привилегии в ролях, доступных всем службам (например, sshd, sudo, smbd и т.д.), можно легко ограничить пользователей только теми привилегиями, которые необходимы для их работы. Это означает, что ограниченные среды могут включать любые программы с любой конфигурацией, и можно быть уверенным, что пользователи будут иметь только те привилегии, которые явно предоставлены им в конфигурационном файле.

Идея проста: когда кто-то использует двоичный файл с ограниченным доступом, этот двоичный файл попадает в роль AppArmor через PAM. Профиль AppArmor применяется к исполняемой программе, если программе нужны другие права доступа, она может сменить "hat" (т.е. роль) через "change_hat" на другую роль, также известную как подпрофиль. Этот модуль PAM также позволяет ограничить аутентифицированных пользователей подпрофилями на основе имен групп, имен пользователей или профиля по умолчанию. Для этого "pam_apparmor" должен быть установлен как сеансовый PAM модуль. Таким образом, если, например, "su" настроен на использование с "pam_apparmor", то при вызове пользователем "su" вызывается PAM, и когда начинается сессия PAM, "pam_apparmor" использует "change_hat" для изменения роли на ту, которая соответствует имени пользователя или соответствует основной группе, или на роль по умолчанию, которая обычно обеспечивает элементарную политику, и объявляет о переходе на роль профиля при запуске оболочки пользователя.

"pam_apparmor" использует API "change_hat", который ограничивает его использование следующими условиями: приложение, вызывающее API, должно быть ограничено, а все политики выполняются с ролями ограниченного профиля. Это означает, что каждая программа авторизации, поддерживающая PAM (gdm, getty, ssh и т.д.), может быть настроена индивидуально. Это делается путем назначения отдельного профиля для каждой службы.

НАСТРОЙКА

Сначала нам необходимо установить модуль PAM:
Bash: Скопировать в буфер обмена
sudo apt install libpam-apparmor

Чтобы добавить поддержку "pam_apparmor" в приложение (которое поддерживает PAM), необходимо добавить строку в конфигурационный файл PAM для приложения "/etc/pam.d/приложение":
Код: Скопировать в буфер обмена
session optional pam_apparmor.so

Если сделать "required" вместо "optional", то сессия завершится, если "pam_apparmor" не найдет "hat" (роль) для "change_hat". По умолчанию модуль попытается запустить роль по имени основной группы вошедшего пользователя. Если такой роли не существует, то модуль попытается изменить ее на ту, которая используется по умолчанию. Однако это можно настроить, добавив в PAM файл опцию, изменяющую порядок и атрибуты. Для этого добавим "order=", а затем список ролей, разделенных запятыми, которые стоит попробовать. Доступные типы ролей:

[+] "user" - в качестве имени роли будет использоваться имя пользователя;

[+] "group" - в качестве имени роли будет использоваться основная группа пользователя;

[+] "default" - в качестве роли будет использоваться "DEFAULT". Как правило, к этому следует прибегать в крайнем случае.

Порядок в списке определяет очередность попыток. Пример конфигурации:
Код: Скопировать в буфер обмена
session optional pam_apparmor.so order=group,default

Использовать только имя пользователя:
Код: Скопировать в буфер обмена
session optional pam_apparmor.so order=user

Использовать имя пользователя, затем имя основной группы, затем роль по умолчанию (DEFAULT), если предыдущие роли не существуют в профиле приложения:
Код: Скопировать в буфер обмена
session optional pam_apparmor.so order=user,group,default

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

В качестве примера интегрируем модуль "pam_apparmor" с "su", добавив в файл "/etc/pam.d/su" следующую строку:
Код: Скопировать в буфер обмена
session optional pam_apparmor.so order=user,group,default debug

session optional pam_apparmor.so order=user,group,default debug

КОНФИГУРАЦИЯ

Рассмотрим конфигурацию с использованием "change_hat", которая в дальнейшем может быть расширена для удовлетворения различных требований. В этом примере мы ограничим "su" таким образом, чтобы, когда пользователь использует его для выполнения команд от имени другого пользователя, AppArmor применял контроль доступа. Это можно использовать и с другими двоичными файлами, такими как "sshd" или "login". При настройке "pam_apparmor" лучше всего дополнительно войти в систему под именем Root в отдельном окне терминала, чтобы, если что-то пойдет не так, можно было использовать этот терминал для восстановления работоспособности.

Чтобы упростить управление и избежать путаницы, мы разобьем политику PAM на различные файлы. Для AppArmor не имеет значения, разбиты ли эти файлы на отдельные части или собраны в один монолитный файл. Мы будем использовать следующие файлы:

[+] "/etc/apparmor.d/pam_binaries" - будет содержать политики для двоичных файлов профилей, интегрированных с PAM (в нашем случае "su");

[+] "/etc/apparmor.d/pam_roles" - политики для различных ролей в нашей системе, на которые мы будем ссылаться в "pam/mappings";

[+] "/etc/apparmor.d/pam/mappings" - необходим для сопоставления имен пользователей или групп с ролями.

Создадим файл "/etc/apparmor.d/pam_binaries", чтобы иметь:
Код: Скопировать в буфер обмена

Код:

#include <tunables/global>
/bin/su {
   #include <abstractions/authentication>
   #include <abstractions/base>
   #include <abstractions/nameservice>
   #include <pam/mappings>
   capability chown,
   capability setgid,
   capability setuid,
   owner /etc/environment r,
   owner /etc/shells r,
   owner /etc/default/locale r,
   owner @{HOMEDIRS}/*/.Xauthority rw,
   owner @{HOMEDIRS}/*/.Xauthority-c w,
   owner @{HOMEDIRS}/*/.Xauthority-l w,
   @{HOME}/.xauth* rw,
   owner @{PROC}/sys/kernel/ngroups_max r,
   /usr/bin/xauth rix,
   owner /var/run/utmp rwk,
}

Этот файл будет содержать политику ограничения исполняемых файлов, использующих "libpam-apparmor", а также будет включать файл "pam/mappings" со всеми нашими сопоставлениями имен пользователей и групп с ролями. Затем создадим роли в файле "/etc/apparmor.d/pam_roles":
Код: Скопировать в буфер обмена

Код:

#include <tunables/global>
profile default_user {
   #include <abstractions/base>
   #include <abstractions/bash>
   #include <abstractions/consoles>
   #include <abstractions/nameservice>
   deny capability sys_ptrace,
   owner /** rkl,
   @{PROC}/** r,
   /bin/**  Pixmr,
   /usr/bin/** Pixmr,
   owner @{HOMEDIRS}/ w,
   owner @{HOMEDIRS}/** w,
}

profile confined_user {
   #include <abstractions/base>
   #include <abstractions/bash>
   #include <abstractions/consoles>
   #include <abstractions/nameservice>
   deny capability sys_ptrace,
   owner /** rwkl,
   @{PROC}/** r,
   /bin/**  Pixmr,
   /usr/bin/** Pixmr,
   owner @{HOMEDIRS}/bin/** ixmr,
}

Этот файл будет содержать роли, на которые ссылается "pam/mappings". Пользователь по умолчанию может читать и блокировать свои файлы в любом месте, но перезаписывать только в своем домашнем каталоге, и имеет ограниченные права на запуск файлов. Пользователь с ограниченными правами (confined_users) сможет читать, перезаписывать и блокировать свои файлы в любом месте, а также запускать их.

Теперь создадим файл "/etc/apparmor.d/pam/mappings" для сопоставления имени нашего пользователя (ivan) и группы администраторов (wheel) с ролями, а также назначим "DEFAULT":
Код: Скопировать в буфер обмена

Код:

^DEFAULT {
  #include <abstractions/authentication>
  #include <abstractions/nameservice>
  capability dac_override,
  capability setgid,
  capability setuid,
  /etc/default/su r,
  /etc/environment r,
  @{HOMEDIRS}/.xauth* w,
  /bin/{,b,d,rb}ash Px -> default_user,
  /bin/{c,k,tc}sh Px -> default_user,
}

^ivan {
  #include <abstractions/authentication>
  #include <abstractions/nameservice>
  capability dac_override,
  capability setgid,
  capability setuid,
  /etc/default/su r,
  /etc/environment r,
  @{HOMEDIRS}/.xauth* w,
  /bin/{,b,d,rb}ash Px -> confined_user,
  /bin/{c,k,tc}sh Px -> confined_user,
}

^wheel {
  #include <abstractions/authentication>
  #include <abstractions/nameservice>
  capability dac_override,
  capability setgid,
  capability setuid,
  /etc/default/su r,
  /etc/environment r,
  @{HOMEDIRS}/.xauth* w,
  /bin/{,b,d,rb}ash Ux,
  /bin/{c,k,tc}sh Ux,
}

Этот файл будет содержать сопоставления пользователей с ролями для двоичных файлов, ограниченных AppArmor, сконфигурированных для использования с "libpam-apparmor". Пользователи, не имеющие сопоставлений, не смогут войти в систему. "DEFAULT" содержит права, необходимые только для перехода к оболочке входа пользователя в систему, все остальные права были перенесены в профиль "default_user". "ivan" содержит права, необходимые только для перехода в оболочку входа "ivan", все остальные права были перенесены в профиль "confined_user". "wheel" не будет ограничивать группу администраторов, если они не ограничены отдельным правилом, так как ограничения для администраторов должны настраиваться индивидуально в зависимости от требований и потребностей. Важно отметить, что если служба авторизации не ограничена, то будет применен профиль по умолчанию.

После настройки политики профили и роли должны быть перезагружены:
Bash: Скопировать в буфер обмена
sudo apparmor_parser -r -T -W /etc/apparmor.d/pam_binaries /etc/apparmor.d/pam_roles

Проверим, были ли они загружены:
Bash: Скопировать в буфер обмена

Код:

sudo aa-status

17 profiles are in enforce mode.
/bin/su
/bin/su//DEFAULT
/bin/su//ivan
/bin/su//wheel
...
confined_user

Итак, рассмотрим, как это примерно работает:

[1] Пользователь запускает команду "su - ivan";

[2] Затем "su" выполняет "сhange_hat()" через "pam_apparmor" для "^ivan";

[3] После запуска оболочки "ivan" пользователь переходит в ограниченный профиль "confined_user".

Проще говоря, когда пользователь выполняет команду "su - ivan", он переходит в "confined_user".

Более детальная настройка производится индивидуально. Также возможно расширение списка двоичных файлов, такими как "sshd" и "login", для этого необходимо добавить запись "pam_apparmor.so", как в примере с "su", и политику для двоичного файла в "/etc/apparmor.d/pam_binaries". Чтобы добавить нового пользователя или роль, необходимо настроить "/etc/apparmor.d/pam_roles" для новой роли и скорректировать "/etc/apparmor.d/pam/mappings" для сопоставления имени входа в систему с ролью AppArmor.

УВЕДОМЛЕНИЯ APPARMOR

Демон уведомлений выводит на рабочий стол уведомления, когда AppArmor отказывает программе в доступе. Для начала необходимо запустить платформу аудирования AuditD, выполнив несколько команд (если это не было сделано ранее, следуя примеру из раздела "Создание профилей"):
Bash: Скопировать в буфер обмена

Код:

sudo apt install auditd
sudo systemctl enable auditd
sudo systemctl start auditd

Затем установим демон уведомлений AppArmor и необходимые модули на питоне:
Bash: Скопировать в буфер обмена
sudo apt install apparmor-notify python3-notify2 python3-psutil

После чего мы разрешим пользователю читать журналы аудита "/var/log/audit", добавив его в группу пользователей "audit" (где "ivan" имя пользователя):
Bash: Скопировать в буфер обмена

Код:

sudo groupadd -r audit
sudo gpasswd -a ivan audit

После этого необходимо обозначить это, добавив строку в файл "/etc/audit/auditd.conf":
Код: Скопировать в буфер обмена
log_group = audit

Теперь создадим ярлык автозапуска для демона уведомлений AppArmor с помощью команд:
Код: Скопировать в буфер обмена

Код:

mkdir ~/.config/autostart
touch ~/.config/autostart/apparmor-notify.desktop

В него следует внести стандартные параметры ярлыка и настроить команду, которая будет автоматически выполняться после запуска системы:
Код: Скопировать в буфер обмена

Код:

[Desktop Entry]
Type=Application
Name=AppArmor Notify
TryExec=aa-notify
Exec=aa-notify -p -s 1 -w 60 -f /var/log/audit/audit.log
StartupNotify=false
NoDisplay=true

Где содержимое после "Exec=" это команда запуска демона уведомлений AppArmor. Рассмотрим параметры для редактирования:

[+] "-p" - опрашивать журналы AppArmor и выводить уведомления на рабочий стол;

[+] "-s" - показывать сводку за определенное количество дней;

[+] "-w" - подождать определенное количество секунд перед отображением уведомлений;

[+] "-f" - путь к журналам AppArmor.

Готово, теперь необходимо перезагрузиться. Проверить, работает ли демон уведомлений, можно с помощью команды:
Bash: Скопировать в буфер обмена
pgrep -ax aa-notify

ОТКЛЮЧЕНИЕ APPARMOR

Если Apparmor больше не нужен, чтобы программа не расходовала системные ресурсы, или его просто нужно отключить для отладки. Очистим кэш профилей и остановим службу управления AppArmor:
Bash: Скопировать в буфер обмена

Код:

sudo systemctl disable apparmor
sudo systemctl stop apparmor

Но эта команда не остановит уже запущенные профили, для их выгрузки необходимо выполнить:
Bash: Скопировать в буфер обмена
sudo aa-teardown

Чтобы просто отключить профиль, необходимо выполнить следующие команды (apparmor_parser -R или --remove):
Bash: Скопировать в буфер обмена

Код:

sudo ln -s /etc/apparmor.d/профиль /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/профиль

Для повторного включения соответствующего профиля безопасности необходимо выполнить следующие команды (apparmor_parser -r или --replace):
Bash: Скопировать в буфер обмена

Код:

sudo rm /etc/apparmor.d/disable/профиль
sudo apparmor_parser -r /etc/apparmor.d/профиль

После этого профиль должен отображаться в "aa-status" как работающий в режиме жалоб. При необходимости он может быть переведен в принудительный режим. Удаление профилей безопасности AppArmor функционально эквивалентно их отключению. Можно также полностью удалить связанный с ним файл из файловой системы. Если профиль был удален без предварительного удаления из ядра (с помощью команды "apparmor_parser -R"), то для очистки потерянных записей можно воспользоваться командой "aa-remove-unknown".

SELINUX

SELinux зародился в недрах АНБ и реализован на основе ролевого управления доступом (RBAC), многоуровневой безопасности и принудительного назначения типов, что является центральной концепцией всего SELinux. Каждому файлу назначается контекст безопасности, определяющий, какие процессы и пользователи могут с ним работать. Как и AppArmor, SELinux является реализацией системы MAC, основанной на архитектуре модулей безопасности Linux. Несмотря на очень высокий уровень защиты и поддержку со стороны АНБ и RedHat, эта система не смогла завоевать широкую популярность из-за очень сложной процедуры настройки.

Пользователь в SELinux не эквивалентен пользователю Linux. При смене пользователя через "su" или "sudo" пользователь SELinux не меняется. Обычно несколько пользователей Linux являются одним пользователем SELinux, но возможно и сопоставление один к одному, как это сделано для Root. Пользователи могут иметь роль, одну или несколько. Например, непривилегированный пользователь или администратор базы данных. Объекты также могут иметь роль, и обычно это роль "object_r". Тип или домен является основным средством определения доступа, а также способом категоризации приложения или ресурса.

Классы объектов или категории объектов, такие как "dir" для каталогов или "file" для файлов, используются в политике для более точного определения типов разрешенного доступа. Каждый класс объектов содержит набор разрешений и определяет варианты доступа к объекту. Например, "file" содержит разрешения на создание (create), чтение (read), запись (write) и удаление (unlink), а класс "unix_stream_socket object" имеет разрешения на создание (create), установление соединения (connect) и отправку данных (sendto).

Также, как и в AppArmor, существует "permissive" (режим жалоб), в котором приложениям разрешен доступ к ресурсам, но все обращения записываются в журнал логов. Это позволяет затем создать профиль для приложения. Разница заключается в том, что этот режим является общесистемным, в то время как в AppArmor он может быть выборочно включен для конкретных приложений.

Ключевое различие между AppArmor и SELinux заключается в том, что AppArmor привязывает политику к пути файла, в то время как SELinux опирается на дескриптор файла. Если заблокировать выполнение файла, а затем переместить его, AppArmor разрешит запуск файла, а SELinux нет. Если файл будет перезаписан по исходном пути, уже AppArmor заблокирует его, а SELinux разрешит выполнение. Избежать подобных недоразумений можно, включив политику "блокировать все, кроме явно разрешенного". В двух словах о различиях можно сказать, что разработчики SELinux делали упор не на простоту использования, а на безопасность.

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

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

СПИСКИ КОНТРОЛЯ ДОСТУПА (ACL)

Стандартный режим управления разрешениями в Linux покрывает большинство потребностей. ACL более сложный, но гибкий инструмент управления доступом. Он позволяет сегментировать категорию "other" и разрешить работу с файлом или каталогом нескольким конкретным пользователям и группам. В зависимости от целей администрирования, опция может применяться как к отдельной файловой системе, так и к данным SMB и NFS серверов.

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

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

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

Сначала установим его:
Bash: Скопировать в буфер обмена
sudo apt install acl

Для работы файловая система должна быть смонтирована с опцией "acl", но есть вероятность, что она уже активна как одна из опций монтирования по умолчанию в файловой системе Btrfs или Ext4. Для проверки наличия этой опции можно использовать следующую команду (где "диск" это sda или sdb и т.д., а "0" цифра корневого раздела):
Bash: Скопировать в буфер обмена

Код:

sudo tune2fs -l /dev/диск0 | grep "Default mount options:"

Default mount options:    user_xattr acl

Если опция не активна, включим ее для корневого раздела с помощью команды:
Bash: Скопировать в буфер обмена
sudo mount -o remount,acl /

Рассмотрим практические примеры использования команды "setfacl" для управления правами доступа к файлам:
Bash: Скопировать в буфер обмена

Код:

sudo setfacl -R -m user:ivan:rx Documents
sudo setfacl -m group:sys_adm:r /var/log/apt/
sudo setfacl -m user:guest:0 Passwords.kdbx

Первая команда устанавливает права на запуск и чтение для "ivan" в каталоге "Documents" и всем его содержимом. Вторая команда разрешает участникам группы "sys_adm" читать файлы журнала ошибок "apt". Третья команда полностью запрещает пользователю "guest" доступ к файлу "Passwords.kdbx".

sudo setfacl -R -m user:ivan:rx Documents

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

Код:

sudo setfacl -m user:guest1:rwx work_dir
sudo setfacl -d -m user:guest1:rwx work_dir
sudo setfacl -m user:guest2:rx work_dir
sudo setfacl -d -m user:guest2:rx work_dir

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

Для просмотра разрешений используем команду:
Bash: Скопировать в буфер обмена
getfacl файл/каталог

Для удаления всех записей ACL необходимо выполнить:
Bash: Скопировать в буфер обмена
sudo setfacl -b файл/каталог

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

ПАРУ СЛОВ ОБ ОСТАЛЬНЫХ: TOMOYO/AKARI

Еще несколько хороших реализаций MAC, с которыми может справиться каждый. TOMOYO и AKARI похожи на AppArmor, но менее распространены. AKARI это вариант реализации TOMOYO, и в настоящее время они являются одними из четырех стандартных модулей безопасности Linux, наряду с SELinux и AppArmor. Они могут сосуществовать с другими модулями безопасности, такими как SELinux и AppArmor. TOMOYO/AKARI ориентированы на поведение системы, позволяя каждому процессу назначать поведение и ресурсы, необходимые для достижения его цели. Они могут использоваться как средства системного анализа, и как средства разграничения доступа. Цель безопасности TOMOYO/AKARI предоставить MAC, удовлетворяющий практическим требованиям большинства пользователей и остающийся пригодным для использования. Им часто отдают предпочтение, поскольку они являются инструментами не только для специалистов, но и для обычных пользователей, относительно легко настраиваются и обеспечивают разнообразные варианты использования. По сути, они имеют тот же принцип работы, что и AppArmor, с обучающим режимом и аналогичными инструментами. Однако конфигурационные файлы менее структурированы, чем у AppArmor, и база данных профилей меньше.

Основные особенности включают:

[+] Системный анализ;

[+] Автоматическое создание политики;

[+] Простой синтаксис;

[+] Простота.

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

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

RBAC ОТ GRSECURITY

В RBAC от компании GRSecurity впервые реализована система профилирования, позволяющая автоматически генерировать полные системные политики с наименьшими привилегиями. Легко читаемые политики, правила и журналы внешне похожи на AppArmor. В журналах отображаются полные пути к процессу нарушителю и его родительскому процессу, а также в доступной форме описывается характер нарушения. Роли применяются к пользователям или группам. Эти роли содержат набор тем, описывающих политики для двоичных файлов и скриптов в системе. Темы содержат набор объектов, представляющих собой файлы, такие как утилиты, сетевые сокеты и ресурсы, которые разрешено использовать процессу. В сочетании с легко читаемыми политиками многие обнаруживают, что могут сразу же приступить к созданию значимых политик безопасности или выполнить полную системную настройку. GRSecurity поставляется в виде отдельных патчей, что позволяет использовать его совместно с SELinux.

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

К сожалению, с 2017 года этот проект доступен только по лицензии. После перепрофилирования проекта были попытки создания его форков, но все они прекратили разработку.

PLEDGE И UNVEIL В OPENBSD

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

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

PLEDGE

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

По сути, Pledge это обещание, что программа будет использовать только определенные ресурсы. Например, программа обязуется не использовать никаких портов, кроме "port 63", или программа обязуется не использовать никаких системных вызовов, кроме "lseek()" и "fork()". В этом случае вместо традиционной блокировки доступа к несанкционированным системным вызовам применяется иной подход, при котором в случае обнаружения несанкционированного поведения приложение принудительно завершается. По мнению разработчиков, такой подход значительно затрудняет исследование возможных путей обхода ограничений в ходе атаки.

Существует типичный сценарий использования системных вызовов: на этапе инициализации используется достаточно большое количество системных вызовов, после чего доступ к ним существенно сокращается. Обычно для обеспечения защиты достаточно добавить вызов "pledge()" в участок кода после инициализации, но до начала главного цикла. К классам системных вызовов относятся stdio (ввод/вывод), rpath (только для чтения), wpath (запись файлов), cpath (создание файлов), tmppath (работа с временными файлами), inet (сетевые сокеты), unix (сокеты unix), dns (резолвинг в DNS), getpw (доступ на чтение базы пользователей), ioctl (вызов ioctl), proc (управление процессами), exec (запуск процессов), id (управление правами доступа) и т.д.

Например, для программы "cat", которая только читает файлы, можно указать: pledge("stdio rpath", NULL), для "mkdir": pledge("stdio rpath cpatch wpatch fattr", NULL), а для "patch": pledge("stdio rpath cpatch wpatch tmpath fattr", NULL). Такие ограничения позволят работать с файлами, но не позволят создавать сокеты и запускать другие приложения. Насколько проще реализовать Pledge, можно судить по утилите "file", когда при использовании "systrace" для ограничения системных вызовов требуется 300 строк кода, а Pledge позволяет обойтись двумя вызовами "pledge()".

Рассмотрим, как это работает, например, есть условная программа, которой для системного вызова требуется только "read". В код программы добавляется правило "pledge()", чтобы использовать только "read" и ничего больше. Кто-то обнаружил, что в программе есть уязвимость, которая может быть использована для вызова оболочки Root. Использование программы для запуска оболчки Root приведет к тому, что ядро завершит процесс с сообщением "SIGABRT" (которое нельзя перехватить или проигнорировать) и сгенерирует журнал, который можно найти с помощью "dmesg".

Pledge обычно находится непосредственно в коде программы:
Код: Скопировать в буфер обмена
int pledge(const char *promises, const char *execpromises);

Пример кода "cat" из OpenBSD:
Код: Скопировать в буфер обмена

Код:

........
#include <unistd.h>
........
int ch;
if (pledge("stdio rpath", NULL) == -1)
    err(1, "pledge");

while ((ch = getopt(argc, argv, "benstuv")) != -1)
..........

UNVEIL

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

Поддерживаются флаги ограничения доступа, т.е. можно открыть отдельно доступ на чтение, запись и выполнение, запретить создание или удаление файлов. Например, можно открыть доступ на запись к "/tmp", на запуск "/bin/sh" и доступ на чтение "/var/spool". Блокирование осуществляется за счет интеграции дополнительных фильтров, работающих на уровне системных вызовов, связанных с файловыми операциями ("open()", "chmod()", "rename()" и т.д.).

Unveil работает почти так же, как Pledge, за исключением того, что передаются пути и разрешения для них:
Код: Скопировать в буфер обмена
int unveil(const char* путь, const char* разрешение);

"Путь" - может быть как файлом, так и каталогом. Если это каталог, то разрешения будут применяться к любому файлу в этом каталоге. "Разрешение" - это строка, содержащая ноль или:

[+] "r" - доступ на чтение;

[+] "w" - доступ на запись;

[+] "c" - создать или удалить;

[+] "x" - выполнить.

Как и в Pledge, права можно только уменьшать, но не увеличивать. Еще одно важное отличие заключается в том, что, в отличие от Pledge, попытка открыть файл, который не виден из-за Unveil, не приведет к завершению работы программы. Вместо этого попытка будет просто провалена. В качестве примера можно привести файл "/bin/man" из OpenBSD:
Код: Скопировать в буфер обмена

Код:

if (unveil("/usr/share/man", "r") < 0) {
    perror("unveil");
    return 1;
}

unveil(nullptr, nullptr);

Эта программа заранее знает, что будет читать только файлы внутри "/usr/share/man". Второй вызов Unveil с нулем сообщает ядру, что мы закончили и больше не нужно указывать пути, после чего Unveil уже не может быть вызван.

:smile10: ЗАКЛЮЧЕНИЕ

В заключение стоит повторить, что AppArmor отличается высокой степенью безопасности и гораздо проще в настройке, чем SELinux. А относительно простая реализация функции самостоятельного создания профилей только усиливает его преимущества, особенно когда речь идет о создании политик безопасности или переключении между разрешающим (permissive) и запрещающим (non-permissive) режимами. SELinux может переключать эти режимы только для всей системы, в то время как AppArmor делает это на уровне приложений. С другой стороны, выбор между этими двумя решениями может отсутствовать, поскольку некоторые основные дистрибутивы Linux поддерживают либо одно, либо другое решение. Конечно, они не спасут от выхода из песочницы браузера через ошибку в системном вызове с возможностью записи в адресное пространство ядра, но от вредоносных действий в пользовательском пространстве они могут помочь.

🛡️ КАК НЕ ДОПУСТИТЬ ЭСКАЛАЦИЮ ПРИВИЛЕГИЙ LINUX // БЕЗОПАСНОСТЬ ROOT, SUDO, USERS

https://xss.is/threads/93544/

🛡️ ОБЯЗАТЕЛЬНЫЙ КОНТРОЛЬ ДОСТУПА LINUX // MAC-СИСТЕМЫ: APPARMOR, SELINUX, TOMOYO/AKARI

D2

:smile66: О ЧЕМ СТАТЬЯ​

:zns3: ВВЕДЕНИЕ​

APPARMOR​

:zns5: УСТАНОВКА APPARMOR​

КОНЦЕПЦИЯ ПРОФИЛЕЙ APPARMOR​

СИНТАКСИС ПРОФИЛЯ APPARMOR​

СОЗДАНИЕ ПРОФИЛЕЙ APPARMOR​

ГОТОВЫЕ ПРОФИЛИ APPARMOR​

ПРОФИЛИ WHONIX/KICKSECURE​

ПОЛНАЯ СИСТЕМНАЯ ПОЛИТИКА APPARMOR​

APPARMOR-PROFILE-EVERYTHING ОТ WHONIX/KICKSECURE​

APPARMOR ДЛЯ УПРАВЛЕНИЯ ДОСТУПОМ НА ОСНОВЕ РОЛЕЙ (RBAC) ​

НАСТРОЙКА​

КОНФИГУРАЦИЯ​

УВЕДОМЛЕНИЯ APPARMOR​

ОТКЛЮЧЕНИЕ APPARMOR​

SELINUX​

СПИСКИ КОНТРОЛЯ ДОСТУПА (ACL)​

ПАРУ СЛОВ ОБ ОСТАЛЬНЫХ: TOMOYO/AKARI​

RBAC ОТ GRSECURITY​

PLEDGE И UNVEIL В OPENBSD​

PLEDGE​

UNVEIL​

:smile10: ЗАКЛЮЧЕНИЕ​

:smile66: О ЧЕМ СТАТЬЯ

:zns3: ВВЕДЕНИЕ

APPARMOR

:zns5: УСТАНОВКА APPARMOR

КОНЦЕПЦИЯ ПРОФИЛЕЙ APPARMOR

СИНТАКСИС ПРОФИЛЯ APPARMOR

СОЗДАНИЕ ПРОФИЛЕЙ APPARMOR

ГОТОВЫЕ ПРОФИЛИ APPARMOR

ПРОФИЛИ WHONIX/KICKSECURE

ПОЛНАЯ СИСТЕМНАЯ ПОЛИТИКА APPARMOR

APPARMOR-PROFILE-EVERYTHING ОТ WHONIX/KICKSECURE

APPARMOR ДЛЯ УПРАВЛЕНИЯ ДОСТУПОМ НА ОСНОВЕ РОЛЕЙ (RBAC)

НАСТРОЙКА

КОНФИГУРАЦИЯ

УВЕДОМЛЕНИЯ APPARMOR

ОТКЛЮЧЕНИЕ APPARMOR

SELINUX

СПИСКИ КОНТРОЛЯ ДОСТУПА (ACL)

ПАРУ СЛОВ ОБ ОСТАЛЬНЫХ: TOMOYO/AKARI

RBAC ОТ GRSECURITY

PLEDGE И UNVEIL В OPENBSD

PLEDGE

UNVEIL

:smile10: ЗАКЛЮЧЕНИЕ