AppArmor проактивно защищает приложения и ресурсы операционной системы от внутренних и внешних угроз, включая атаки нулевого дня, предотвращая использование как известных, так и неизвестных уязвимостей.
AppArmor встроен в основное ядро Linux, начиная с версии 2.6.36, и в настоящее время поставляется с Ubuntu , Debian , OpenSUSE и подобными дистрибутивами.
В следующих разделах мы будем использовать среду Ubuntu 20.04, чтобы продемонстрировать несколько практических примеров с AppArmor. Большинство связанных утилит командной строки будут работать одинаково на любой платформе с установленным AppArmor.
Работа с AppArmor
Утилиты командной строки AppArmor обычно требуют прав суперпользователя.
Следующая команда проверяет текущий статус AppArmor:
sudo aa-status
Вот выдержка из вывода команды:
Рисунок 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 , прошу прощения за бережливую реализацию:
Рисунок 2 – Скрипт appackt
Мы предполагаем, что каталог log уже существует в том же месте, что и сценарий:
mkdir ./log
Сделаем скрипт исполняемым и запустим его:
chmod a+x 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):
Рисунок 4 – Подсказка 1 – Ожидание сканирования с помощью aa-genprof
Давайте посмотрим на следующую подсказку.
Подсказка 2 – Выполнить разрешения для / usr / bin / bash
Это приглашение запрашивает разрешения на выполнение для процесса ( /usr/bin/bash ), запускающего наше приложение.
Ответ : I (Inherit):
Рисунок 5 – Подсказка 2 – Выполнение разрешений для /usr/bin/bash
Давайте посмотрим на следующую подсказку.
Подсказка 3 – разрешения на чтение / запись в / dev / tty
Это приглашение запрашивает разрешения на чтение / запись для приложения для управления терминалом ( /dev/tty ).
Ответ : A ( Разрешить ):
Рисунок 6 – Подсказка 3 – Разрешения на чтение / запись в /dev/tty
Теперь давайте посмотрим на последнее приглашение.
Подсказка 4 – сохранить изменения
В приглашении предлагается сохранить или просмотреть изменения.
Ответ : S ( Сохранить ):
Рисунок 7 – Подсказка 4 – Сохранить изменения
На этом мы закончили сканирование с помощью aa-genprof и можем ответить F (Finish) на последнее приглашение. Наше приложение ( appackt ) теперь принудительно применяется AppArmor в режиме complain mode (режим “жалобы”, используется по умолчанию). Если мы попытаемся запустить наш скрипт, мы получим следующий результат:
Рисунок 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, таким образом проверяя наш профиль:
Рисунок 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 :
Рисунок 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, которые действуют локально в системе на уровне приложения. Когда дело доходит до защиты приложений и компьютерных систем от внешнего мира, в игру вступают брандмауэры. Далее мы рассмотрим брандмауэры.
Свежие комментарии