Безопасный Linux вместе с AppArmor14.12.2020 17:47

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

[admin@server ~]$ sudo aptitude install apparmor-utils apparmor-profiles

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

[admin@server ~]$ sudo apparmor_status
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
 /snap/snapd/10492/usr/lib/snapd/snap-confine
 /snap/snapd/10492/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 /usr/bin/man
 /usr/lib/NetworkManager/nm-dhcp-client.action
 /usr/lib/NetworkManager/nm-dhcp-helper
 /usr/lib/connman/scripts/dhclient-script
 /usr/lib/snapd/snap-confine
 /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
 /usr/sbin/tcpdump
   ...
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.

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

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

Содержимое пакета apparmor-profiles находится в папке /usr/share/apparmor/extra-profiles/, готовых профилей там больше ста.

[admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |head
total 484
-rw-r--r-- 1 root system 1724 May 19 2020 README
drwxr-xr-x 3 root system 4096 Dec 8 10:14 abstractions/
-rw-r--r-- 1 root system 1319 May 19 2020 bin.netstat
-rw-r--r-- 1 root system 1815 May 19 2020 etc.cron.daily.logrotate
-rw-r--r-- 1 root system  948 May 19 2020 etc.cron.daily.slocate.cron
-rw-r--r-- 1 root system  722 May 19 2020 etc.cron.daily.tmpwatch
-rw-r--r-- 1 root system 2623 May 19 2020 sbin.dhclient
[admin@server ~]$ ll /usr/share/apparmor/extra-profiles/ |wc -l
118

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

...
#include 
profile ping /{usr/,}bin/{,iputils-}ping flags=(complain) {
  #include 
  #include 
  #include 

  capability net_raw,
  capability setuid,
  network inet raw,
  network inet6 raw,

  /{,usr/}bin/{,iputils-}ping mixr,
  /etc/modules.conf r,

  # Site-specific additions and overrides. See local/README for details.
  #include 
}

Все достаточно понятно, кроме флагов mixr. Описание значений флагов ниже:

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

Можно также указывать Capabilities ядра Linux, которые процессу разрешено использовать. Их полный список есть в соответствующей странице мануала.
Для перехода из режима обучения в принудительный нужно выполнить команду aa-enforce , вернуться - aa-complain . Если теперь после включения принудительного режима ping попробует сделать, что-то непредусмотренное AppArmor его заблокирует.

[admin@server ~]$ sudo aa-enforce ping
Setting /usr/bin/ping to enforce mode.
[admin@server ~]$ sudo cp /usr/bin/man /usr/bin/ping
[admin@server ~]$ /usr/bin/ping ping
/usr/bin/ping: can't open the manpath configuration file /etc/manpath.config

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

Использованные материалы

© Habrahabr.ru