Отключение apparmor ubuntu 20

Обновлено: 03.07.2024

AppArmor - это реализация Модуля безопасности линукс по управлению доступом на основе имен. AppArmor ограничивает отдельные программы набором перечисленных файлов и возможностями в соответствии с правилами Posix 1003.1e.

AppArmor устанавливается и загружается по умолчанию. Он использует профили приложений для определения какие файлы и права доступа требуются приложению. Некоторые пакеты устанавливают свои собственные профили, а дополнительные профили можно найти в пакете apparmor-profiles.

Для установки пакета apparmor-profiles наберите в терминале:

Профили AppArmor имеют два режима выполнения:

Фиксации/Обучения: нарушения профиля разрешаются и сохраняются в журнале. Полезно для тестирования и разработки новых профилей

Предписаний/Ограничений: принуждает следовать политике профиля, при этом также записывает нарушения в журнал.

Использование AppArmor

Пакет apparmor-utils содержит утилиты командной строки, которые можно использовать для изменения режима выполнения AppArmor, поиска статуса профиля, создания новых профилей и т.п.

1. apparmor_status используется для просмотра текущего статуса профиля AppArmor.

2. aa-complain переводит профиль в режим обучения (complain).

3. aa-enforce переводит профиль в режим ограничений (enforce).

4. Профили AppArmor расположены в каталоге /etc/apparmor.d. Его можно использовать для управления режимом всех профилей. Введите следующую команду для перевода всех профилей в режим обучения:

Перевод всех профилей в режим ограничений:

6. /etc/init.d/apparmor служит для перезагрузки всех профилей:

7. Директория /etc/apparmor.d/disable может использоваться совместно с опцией apparmor_parser -R для отключения профиля.

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

9. Для повторной активации AppArmor введите:

Замените profile.name на имя вашего профиля, которым вы хотите управлять. Также необходимо заменить /path/to/bin/ на реальный путь выполненяемого файла. Например, для команды ping используйте /bin/ping

Профили

Профили AppArmor - это простые текстовые файлы, которые расположены в /etc/apparmor.d/. Файлы профиля называются соответственно полному пути до исполняемого файла, которым они управляют, с заменой символа «/» на «.». Например /etc/apparmor.d/bin.ping - это профиль AppArmor для команды /bin/ping.

Существует два основных типа правил, используемых в профиле:

1. Записи путей (Path entries): которые описывают к каким файлам приложение имеет доступ в файловой системе. 2. Записи разрешений (Capability entries): определяют какие права ограничиваемый процесс имеет право использовать.

В качестве примера посмотрим /etc/apparmor.d/bin.ping:

/bin/ping flags=(complain): путь к программе, управляемой профилем, также устанавливающий режим обучения.

capability net_raw,: разрешает приложению доступ к возможностям CAP_NET_RAW Posix.1e.

/bin/ping mixr,: разрешает приложению доступ на чтение и выполнение файла.

После редактирования файла профиля, он должен быть перезагружен. Для детальной информации обратитесь к разделу Использование AppArmor

Создание профиля

1. Разработка плана тестирования: Попробуйте подумать о том как приложение будет выполняться. План тестирования стоит разделить на маленькие тестовые блоки. Каждый тестовый блок должен иметь краткое описание и перечень шагов выполнения. Некоторые стандартные тестовые блоки:

Тестирование всех команд, поддерживаемых сценарием инициализации.

2. Создание нового профиля: Используйте aa-genprof для создания нового профиля. Команда в терминале:

3. Чтобы получить ваш новый профиль в составе пакета apparmor-profiles, зарегистрируйте проблему в Launchpad для пакета AppArmor:

Включите ваш план тестирования и тестовые блоки.

Обновление профилей

Ссылки

Смотрите AppArmor Administration Guide для дополнительных опций настройки.

Для уточнения использования AppArmor с другими выпусками Ubuntu смотрите страницу AppArmor Community Wiki.

Мануал

AppArmor является мандатной системой контроля доступа или MAC.

Он использует модуль безопасности Linux для ограничения программ.

AppArmor создает набор профилей приложений по умолчанию для защиты сервисов Linux.

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

В Ubuntu приложение AppArmor установлено и включено по умолчанию.

Профили apparmor загружаются при запуске системы.

AppArmor работает в следующих двух типах режимов профиля:

Enforce – В режиме Enforce система начинает применять правила и сообщать о попытках нарушения в syslog или auditd (только если auditd установлен), и операция не будет разрешена.
Complain – режиме Complain система не применяет никаких правил. Она будет только регистрировать попытки нарушения.

Дополнительные профили можно найти в пакете apparmor-profiles.

Просмотр статуса Apparmor

Вы можете просмотреть текущее состояние apparmor и всех загруженных профилей, как показано ниже:

Если мы проверим вышеприведенный вывод, мы увидим, что 5 профилей находятся в режиме Enforce.

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

Например, /sbin/dhclient с PID 585 работает в режиме enforce

Изменить режим профиля

Чтобы установить профиль в режиме complain, сначала установите пакет apparmor-utils, если он еще не установлен.

Используйте команду aa-complain, чтобы настроить профиль в режиме complain.

Например, для включения режима complain для mysqld выполните следующие действия.

Теперь, когда вы выполните apparmor_status, вы увидите mysqld в режиме complain

Вы можете изменить профиль обратно в режим enforce, используя команду aa-enforce, как показано ниже.

Файлы профилей AppArmor

Файлы названы по имени полного пути к исполняемому файлу, но они заменяют «/» на «.».

Например, команда ping находится в /bin/ping.

Аналогичный файл профиля AppArmor будет называться bin.ping

Ниже приведены различные типы правил, которые используются в профилях.

Элементы пути. Это информация о файлах, к которым приложение имеет доступ.
Записи Capability : определяет привилегии, которые разрешены ограниченному процессу.
Сетевые записи: определяет тип подключения. Например: tcp. Для сети пакетного анализатора может быть raw или packet и т. д.

Внутри фигурных скобок <> у нас есть другие операторы include, а также включает разрешения / режимы доступа [read (r) / write (w) / execute (x) (k) lock (требуется r или w, в AppArmor 2.1 и более поздняя версия)], чтобы различные файлы и каталоги, которые включают регулярное выражение, включающее агенты include с фигурными фигурными скобками <>, помогают загружать компоненты профилей Novell 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:

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

Рисунок 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 уже существует в том же месте, что и сценарий:

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

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

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

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

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

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

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

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

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

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

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

Теперь мы должны вернуться к терминалу 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 :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы отключить или включить профиль, мы использовали команду 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, которые действуют локально в системе на уровне приложения. Когда дело доходит до защиты приложений и компьютерных систем от внешнего мира, в игру вступают брандмауэры. Далее мы рассмотрим брандмауэры.

В предыдущей статье речь шла о SELinux. Моё впечатление об этой системе безопасности двоякое. С одной стороны безопасности в ИТ много не бывает, и SELinux содержит все необходимое для защиты ОС и приложений от несанкционированного доступа. С другой же стороны он выглядит чересчур громоздким и неоправданно сложным, что делает его применение непрактичным. Не раз и не два в руководствах пользователя по установке коммерческого ПО я видел рекомендации выполнить setenforce 0 перед началом установки.

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

Так же, как и SELinux AppArmor является реализацией системы Mandatory Access Control (MAC), основанной на архитектуре Linux Security Modules (LSM). Модель безопасности Apparmor заключается в привязке атрибутов контроля доступа не к пользователям, а к программам. AppArmor обеспечивает изоляцию с помощью профилей, загружаемых в ядро, как правило, при загрузке.

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

DAC и MAC

Архитектура Discretionary Access Control (DAC) ограничивает доступ к критически важным ресурсам, в зависимости от атрибутов субъектов или группы, к которой они принадлежат. Эти атрибуты определяют права доступа к ресурсам файловой системы. Каждому админу хорошо известно значение привилегий чтение (Read), запись (Write), и исполнение (eXecute).
Эти атрибуты распространяются на три категории пользователей: пользователь (owner), группа (group), остальные (other). Категория владелец относится к одному единственному пользователю ОС, в то время как группа может содержать множество пользователей ОС. В категорию остальные входят те пользователи, которые не принадлежат к первым двум.
DAC модель дает владельцу ресурса право определять тип доступа для указанных категорий пользователей. Такое разграничение доступов подходит для защиты от непреднамеренных действий пользователей и позволяет ответить на следующие вопросы:

Какие ресурсы ФС доступны данному пользователю ОС для чтения, записи и исполнения?
Какие ресурсы ФС доступны данной группе для чтения, записи и исполнения?
Какие ресурсы ФС доступны остальным пользователям для чтения, записи и исполнения?
Кто из пользователей обладает достаточными правами для запуска данного процесса?

Рис. 1 Системы безопасности DAC и MAC.

Система безопасности Mandatory Access Control (MAC) предполагает централизованный контроль над правилами политики доступа, при котором рядовые пользователи не имеют возможность вносить в них какие-либо изменения. Разработчик политики определяет, какие программы или процессы могут выполнять определенные действия с системными ресурсами. MAC фокусируется в большей степени на программах, нежели на пользователях и решает задачу разграничения доступа процессов к ресурсам ОС.
В сущности дизайн MAC старается копировать разграничение привилегий доступа к документации в физическом мире. Если некий сотрудник имеет права читать документы с грифом «совершенно секретно», то к стандартным конфиденциальным и внутренним документам он тоже имеет доступ. Обратное однако не верно. То же самое имеет место в контексте привилегий доступа процессов ОС в архитектуре MAC. Так, если программа может читать файл /etc/sudoers, то доступ к /etc/hosts у нее тоже имеется, но обратное также неверно.

Установка и настройка AppArmor

Базовые элементы AppArmor предустановлены в Ubuntu Server, что касается инструментов управления и набора профилей приложений, то их нужно устанавливать отдельно.

Проверка статуса перед настройкой.

В последних строках указаны режимы enforce и complain. Что вкратце из себя представляют эти режимы?

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

Перед тем как профиль станет активным необходимо перенести его из папки /usr/share/apparmor/extra-profiles/ в /etc/apparmor.d/ . Теперь его можно изучить и при желании изменить. Возьмем что-нибудь попроще, например /etc/apparmor.d/bin.ping .

r — чтение;
w — запись
a — инкрементальная запись в конец файла, от английского append;
k — блокировка файлов;
l — создание символических ссылок на исполняемые файлы;
m — загрузка исполняемых файлов в память;
cx — переход в профиль нижнего уровня при выполнении;
Cx — переход в профиль нижнего уровня при выполнении с очисткой переменных окружения;
ix — наследование исполнения;
px — требуется определение дискретного профиля безопасности для ресурса;
Px — требуется определение дискретного профиля безопасности для ресурса, производится очистка переменных окружения;
ux — не проверять запуск новых процессов;
Ux — не проверять запуск новых процессов и производить очистку переменных окружения;

Если нужно создать новый профиль, то это не сложно. Сначала надо создать шаблон с помощью команды aa-autodep , а затем его наполнить, запустив aa-genprof . Пример интерактивного диалога aa-genprof free по ссылке.

Читайте также: