В предыдущей статье речь шла о 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 <tunables/global>
profile ping /{usr/,}bin/{,iputils-}ping flags=(complain) {
#include <abstractions/base>
#include <abstractions/consoles>
#include <abstractions/nameservice>
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 <local/bin.ping>
}Все достаточно понятно, кроме флагов mixr. Описание значений флагов ниже:
- r — чтение;
- w — запись
- a — инкрементальная запись в конец файла, от английского append;
- k — блокировка файлов;
- l — создание символических ссылок на исполняемые файлы;
- m — загрузка исполняемых файлов в память;
- cx — переход в профиль нижнего уровня при выполнении;
- Cx — переход в профиль нижнего уровня при выполнении с очисткой переменных окружения;
- ix — наследование исполнения;
- px — требуется определение дискретного профиля безопасности для ресурса;
- Px — требуется определение дискретного профиля безопасности для ресурса, производится очистка переменных окружения;
- ux — не проверять запуск новых процессов;
- Ux — не проверять запуск новых процессов и производить очистку переменных окружения;
Можно также указывать Capabilities ядра Linux, которые процессу разрешено использовать. Их полный список есть в соответствующей странице мануала.
Для перехода из режима обучения в принудительный нужно выполнить команду aa-enforce <prog_name>, вернуться - aa-complain <prog_name>. Если теперь после включения принудительного режима 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 по ссылке.
Использованные материалы
Автор: oldadmin
