В предыдущей статье речь шла о 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 по ссылке.
Использованные материалы
ссылка на оригинал статьи https://habr.com/ru/company/ruvds/blog/532988/
Добавить комментарий