Знакомство с AppArmor: как работать с модулем безопасности на примерах

Введение в AppArmor

AppArmor - это LSM (Linux Security Module), основанный на модели MAC, который ограничивает приложения строго заанным набором ресурсов. AppArmor использует ACM на основе профилей безопасности (политиках безопасности), загруженных в ядро. Каждый профиль содержит набор правил для доступа к различным системным ресурсам. AppArmor можно настроить либо для принудительного контроля доступа, либо просто для подачи жалоб на нарушения контроля доступа.

Linux Security Modules (LSM)

Модули безопасности Linux (LSM) - это структура, позволяющая ядру Linux без предвзятости поддерживать различные модели компьютерной безопасности. LSM находится под лицензией GNU General Public License и является стандартной частью ядра Linux, начиная с Linux 2.6. AppArmor, SELinux, Smack и TOMOYO Linux - это утвержденные в настоящее время модули безопасности в официальном ядре.



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

AppArmor встроен в основное ядро ​​Linux, начиная с версии 2.6.36, и в настоящее время поставляется с Ubuntu , Debian , OpenSUSE и подобными дистрибутивами.

В следующих разделах мы будем использовать среду Ubuntu 20.04, чтобы продемонстрировать несколько практических примеров с AppArmor. Большинство связанных утилит командной строки будут работать одинаково на любой платформе с установленным AppArmor.

Работа с AppArmor

Утилиты командной строки AppArmor обычно требуют прав суперпользователя.

Следующая команда проверяет текущий статус AppArmor:

sudo aa-status

Вот выдержка из вывода команды:

Получение статуса AppArmor

Рисунок 1 - Получение статуса AppArmor

Команда aa-status (или apparmor_status) предоставляет полный список загруженных в данный момент профилей AppArmor (не показан в предыдущем отрывке). Далее мы рассмотрим профили AppArmor.

Представляем профили AppArmor

В AppArmor процессы ограничиваются (или ограничиваются) профилями. AppArmor профили загружаются при запуске системы и работать либо в режиме enforce mode или complain mode. Мы объясним эти режимы позже.

Enforce mode (Принудительный режим)

AppArmor не позволяет приложениям, работающим в режиме Enforce mode, выполнять ограниченные действия. Нарушения доступа сигнализируются записями журнала в системном журнале . Ubuntu по умолчанию загружает профили приложений в Enforce mode.

Complain mode (Режим жалобы)

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

Помня об этих вводных замечаниях, давайте создадим простое приложение с профилем AppArmor.

Создать профиль

В этом разделе мы создадим простое приложение, защищенное AppArmor. Мы надеемся, что это упражнение поможет вам получить четкое представление о внутренней работе AppArmor. Назовем это приложение appackt . Мы сделаем это простым скриптом, который создает файл, записывает в него, а затем удаляет файл. Цель состоит в том, чтобы AppArmor предотвращал доступ нашего приложения к любым другим путям в локальной системе. Чтобы попытаться понять это, подумайте об этом как о тривиальной переработке журналов.

Вот сценарий appackt , прошу прощения за бережливую реализацию:

Скрипт appackt Рисунок 2 - Скрипт appackt

Мы предполагаем, что каталог log уже существует в том же месте, что и сценарий:

mkdir ./log

Сделаем скрипт исполняемым и запустим его:

 

chmod a+x appackt

./appackt

Результат выглядит следующим образом:
Выходные данные скрипта appackt

Рисунок 3 - Выходные данные скрипта appackt

Теперь давайте поработаем над защитой и обеспечением выполнения нашего скрипта с помощью AppArmor. Прежде чем мы начнем, нам нужно установить пакет apparmor-utils - набор инструментов AppArmor :

sudo apt-get install -y apparmor-utils

Мы воспользуемся парой инструментов для создания профиля:

  • aa-genprof : создает профиль безопасности AppArmor.
  • aa-logprof : обновляет профиль безопасности AppArmor.

Мы используем aa-genprof для мониторинга нашего приложения во время выполнения и чтобы AppArmor узнал об этом. В процессе нам будет предложено подтвердить и выбрать поведение, которое требуется в определенных обстоятельствах.

Как только профиль будет создан, мы будем использовать утилиту aa-logprof для внесения дальнейших корректировок во время тестирования в режиме complain mode, если возникнут какие-либо нарушения.

Начнем с aa-genprof . Нам нужны два терминала: один для сеанса мониторинга aa-genprof (в терминале 1 ), а другой для запуска нашего скрипта (в терминале 2 ).

Мы начнем с терминала 1 и выполним следующую команду:

sudo aa-genprof ./appackt

Нас ждет первая подсказка. Затем, пока запрос в терминале 1 ожидает, мы переключимся на терминал 2 и выполним следующую команду:

./appackt

Теперь мы должны вернуться к терминалу 1 и ответить на запросы , отправленные aa-genprof , следующим образом:

Подсказка 1 - Ожидание сканирования

В этом случае предлагается просканировать системный журнал на наличие событий AppArmor, чтобы обнаружить возможные жалобы (нарушения).

Ответ : S (Scan):

Ожидание сканирования с помощью aa-genprof

Рисунок 4 - Подсказка 1 - Ожидание сканирования с помощью aa-genprof

Давайте посмотрим на следующую подсказку.

Подсказка 2 - Выполнить разрешения для / usr / bin / bash

Это приглашение запрашивает разрешения на выполнение для процесса ( /usr/bin/bash ), запускающего наше приложение.

Ответ : I (Inherit):

Подсказка 2 - Выполнение разрешений для / usr / bin / bash

Рисунок 5 - Подсказка 2 - Выполнение разрешений для /usr/bin/bash

Давайте посмотрим на следующую подсказку.

Подсказка 3 - разрешения на чтение / запись в / dev / tty

Это приглашение запрашивает разрешения на чтение / запись для приложения для управления терминалом ( /dev/tty ).

Ответ : A ( Разрешить ):

 Подсказка 3 - Разрешения на чтение / запись в / dev / tty

Рисунок 6 - Подсказка 3 - Разрешения на чтение / запись в /dev/tty

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

Подсказка 4 - сохранить изменения

В приглашении предлагается сохранить или просмотреть изменения.

Ответ : S ( Сохранить ):

Подсказка 4 - Сохранить изменения 

Рисунок 7 - Подсказка 4 - Сохранить изменения

На этом мы закончили сканирование с помощью aa-genprof и можем ответить F (Finish) на последнее приглашение. Наше приложение ( appackt ) теперь принудительно применяется AppArmor в режиме complain mode (режим "жалобы", используется по умолчанию). Если мы попытаемся запустить наш скрипт, мы получим следующий результат:

 Первый запуск appackt с ограниченным AppArmor

 Рисунок 8 - Первый запуск appackt с ограниченным AppArmor

Судя по выходным данным, пока что не совсем так. Здесь на помощь приходит инструмент aa-logprof . Для остальных шагов нам понадобится только одно окно терминала.

Давайте запустим команду aa-logprof для дальнейшей настройки нашего профиля безопасности appackt :

sudo aa-logprof

Мы снова получим несколько запросов, аналогичных предыдущим, с запросом дополнительных разрешений, необходимых нашему сценарию, а именно для команд touch , cat и rm . При необходимости запросы чередуются между   Inherit (Наследовать) и Allow (Разрешить). Мы не будем здесь вдаваться в подробности из-за недостатка места. К настоящему времени вы должны иметь общее представление об этих подсказках и их значении. Тем не менее, всегда рекомендуется обдумывать запрашиваемые разрешения и действовать соответственно.

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

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

 Остатки итеративного процесса

 Рисунок 9 - Остатки итеративного процесса

Все они будут названы в соответствии с путем к нашему приложению ( /home/packt /appackt ). Мы можем очистить эти записи с помощью следующей команды:

sudo aa-remove-unknown

Теперь мы можем убедиться, что наше приложение действительно защищено AppArmor:

sudo aa-status

Соответствующий отрывок из вывода выглядит следующим образом:

 приложение в режиме жалобы

Рисунок 10 - приложение в режиме жалобы

Наше приложение (/home/packt/appackt ), как и ожидалось, отображается в режиме complain. Два других относятся к системным приложениям и не имеют для нас отношения.

Затем нам нужно убедиться, что наше приложение соответствует политикам безопасности, применяемым AppArmor. Давайте отредактируем сценарий appackt и изменим путь LOG_FILE в строке 6 на следующий:

LOG_FILE="./logs/appackt"

Мы изменили каталог вывода с log на logs . Создадим каталог logs и запустим наше приложение:

mkdir logs

./appackt

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

 appackt, действующий за пределами границ безопасности

 Рисунок 11 - appackt, действующий за пределами границ безопасности

Давайте отменим предыдущие изменения и заставим скрипт appackt работать нормально. Теперь мы готовы запустить наше приложение в режиме enforce, изменив режим его профиля с помощью следующей команды:

sudo aa-enforce /home/packt/appackt

Результат выглядит следующим образом:

 

Рисунок 12 - Изменение профиля appackt для принудительного режима

Мы можем убедиться, что наше приложение действительно работает в режиме enforce, с помощью следующей команды:

sudo aa-status

Соответствующий вывод выглядит следующим образом:

 

Рисунок 13 - приложение, работающее в принудительном режиме

Если бы мы хотели внести дополнительные изменения в наше приложение, а затем протестировать его с соответствующими изменениями, нам пришлось бы изменить режим профиля на  complain (жаловаться), а затем повторить шаги, описанные ранее в этом разделе. Следующая команда устанавливает для профиля приложения complain mode (режим жалобы):

sudo aa-complain /home/packt/appackt

Профили AppArmor - это простые текстовые файлы, хранящиеся в каталоге /etc/apparmor.d/ . Создание или изменение профилей AppArmor обычно включает в себя ручное редактирование соответствующих файлов или процедуру, описанную в этом разделе, с использованием инструментов aa-genprof и aa-logprof .

Далее давайте посмотрим, как отключить или включить профили приложений AppArmor.

Отключение и включение профилей

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

Во-первых, нам нужно найти профиль приложения, который мы хотим отключить (например, appackt ). Связанный файл находится в каталоге /etc/apparmor.d/ , и его имя соответствует его полному пути, с точками ( . ) Вместо косой черты ( / ). В нашем случае это файл /etc/apparmor.d/home.packt.appackt .

Чтобы отключить профиль, мы должны выполнить следующие команды:

sudo ln -s /etc/apparmor.d/home.packt.appackt /etc/apparmor.d/disable/

sudo apparmor_parser -R /etc/apparmor.d/home.packt.appackt

Если мы запустим команду aa-status , мы больше не увидим наш профиль appackt . Соответствующий профиль все еще присутствует в файловой системе по адресу /etc/apparmor.d/disable/home.packt.appackt :

 Отключенный профиль appackt

Рисунок 14 - Отключенный профиль appackt

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

sudo rm /etc/apparmor.d/disable/home.packt.appackt

sudo apparmor_parser -r /etc/apparmor.d/home.packt.appackt

Appackt профиль теперь должен отображаться в aa-status выхода , как работает в режиме complain mode. Мы можем перевести его в  режим enforce mode следующим образом:

sudo aa-enforce /home/packt/appackt

Чтобы отключить или включить профиль, мы использовали команду apparmor_parser помимо связанных операций с файловой системой. Эта утилита помогает загружать ( -r , --replace ) или выгружать ( -R , --remove ) профили безопасности в ядро ​​и из него.

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

Давайте завершим наше относительно краткое изучение внутреннего устройства AppArmor некоторыми заключительными мыслями.

Заключительные соображения

Работать с AppArmor относительно проще, чем с SELinux, особенно когда речь идет о создании политик безопасности или переключении между разрешающим (permissive) и запрещающим (non-permissive) режимами . SELinux может переключать разрешающий контекст только для всей системы, в то время как AppArmor делает это на уровне приложения. С другой стороны, может и не быть выбора между ними, поскольку некоторые основные дистрибутивы Linux поддерживают либо один, либо другой. AppArmor - это чудо Debian, Ubuntu и, недавно, OpenSUSE, а SELinux работает на RHEL / CentOS. Теоретически вы всегда можете попробовать перенести соответствующие модули ядра в разные дистрибутивы, но это нетривиальная задача.

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

Вас заинтересует / Intresting for you:

Краткая история UNIX и языка С
Краткая история UNIX и языка С 2655 просмотров Андрей Волков Tue, 08 Jan 2019, 16:23:27
Модель файлового ввода-вывода ...
Модель файлового ввода-вывода ... 1302 просмотров Doctor Tue, 22 Jan 2019, 17:12:52
Linux: перезагрузка и выключен...
Linux: перезагрузка и выключен... 2917 просмотров Андрей Волков Wed, 05 Dec 2018, 10:15:41
LILO и GRUB - выбираем и настр...
LILO и GRUB - выбираем и настр... 3029 просмотров Андрей Волков Thu, 22 Nov 2018, 15:21:00
Войдите чтобы комментировать