Внедрение контроля доступа с помощью SELinux или AppArmor в Linux — LFCS часть 20

Чтобы улучшить механизмы безопасности, предоставляемые стандартными разрешениями ugo/rwx и списками контроля доступа, Агентство национальной безопасности США (NSA) разработало метод контроля обязательного доступа (MAC), известный как SELinux (сокращение от Security Enhanced Linux), чтобы ограничить, среди прочего, возможность процессов получать или выполнять другие операции над системными объектами (такими как файлы, каталоги, сетевые порты и т.д.) до наименьшего разрешения, но при этом допускать дальнейшие модификации этой модели.

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

В CentOS 7 SELinux встроен в ядро ​​и включен по умолчанию в режиме принудительного исполнения (подробнее об этом в следующем разделе), в отличие от openSUSE и Ubuntu, которые используют AppArmor.

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

Введение в SELinux и его использование на CentOS 7

Security Enhanced Linux может работать двумя различными способами:

• Enforcing: SELinux запрещает доступ на основе правил политики SELinux — набор рекомендаций, которые контролируют механизм безопасности.
• Permissive: SELinux не запрещает доступ, но отказы регистрируются для действий, которые были бы лишены доступа, если они работали в режиме принудительного исполнения.

SELinux также можно и вовсе отключить. Хотя он и не является режимом работы, он по-прежнему является опцией. Однако научиться использовать этот инструмент лучше, чем просто игнорировать и отключить его. Имейте это в виду!

Чтобы отобразить текущий режим SELinux, используйте getenforce. Если вы хотите переключить режим работы, используйте setenforce 0 (чтобы установить его в Permissive) или setenforce 1 (Enforcing).

Поскольку это изменение не сохранится при перезагрузке, вам нужно будет отредактировать файл /etc/selinux/config и установить переменную SELINUX в состояние enforcing, permissive или disabled для его сохранения после перезагрузки:

Если getenforce возвращает Disabled, вам нужно будет отредактировать /etc/selinux/config с требуемым режимом работы и перезагрузиться. В противном случае вы не сможете установить (или переключить) режим работы с помощью setenforce.

Одно из типичных применений setenforce состоит в переключении между режимами SELinux (от enforcing до permissive или наоборот) для устранения неполадок приложения, которое работает неправильно. Если оно продолжает работать в неисправном режиме после того, как вы установили SELinux в режим Permissive, вы можете быть уверены, что столкнулись с проблемой разрешений SELinux.

Два классических случая, когда мы, скорее всего, будем иметь дело с SELinux:

• Изменение порта по умолчанию, который прослушивает демон или служба.
• Установка директивы DocumentRoot для виртуального хоста вне /var/www/html.

Давайте рассмотрим эти два случая, используя следующие примеры.

ПРИМЕР 1: Изменение порта по умолчанию для демона sshd

Одним из первых, что делают большинство системных администраторов для обеспечения безопасности своих серверов, является изменение порта, который прослушивает демон SSH, в основном для предотвращения сканирования портов и внешних вмешательств. Для этого мы используем директиву Port в /etc/ssh/sshd_config, а затем вводим новый номер порта следующим образом (в этом случае мы будем использовать порт 9999):

Port 9999

После попытки перезапуска службы и проверки её статуса мы увидим, что она не запускается:

# systemctl restart sshd
# systemctl status sshd

Если мы посмотрим на /var/log/audit/audit.log, мы увидим, что sshd не удалось запустить на сервере 9999 с помощью SELinux, поскольку это зарезервированный порт для службы управления JBoss (сообщения журнала SELinux включают в себя слово » AVC «, чтобы их можно было легко идентифицировать среди других сообщений):

# cat /var/log/audit/audit.log | grep AVC | tail -1

На этом этапе большинство людей, вероятно, уже отключили бы SELinux, но мы этого не сделаем. Мы же знаем, что для SELinux есть способ, чтобы изменить порт по умолчанию для демона sshd и всё продолжило работать. Убедитесь, что пакет policycoreutils-python установлен и запущен:

# yum install policycoreutils-python

policycoreutils-python необходим чтобы просмотреть список портов, в которых SELinux позволяет слушать sshd. На следующем скриншоте мы также видим, что порт 9999 зарезервирован для другой службы, и поэтому мы не можем использовать его для наших целей:

# semanage port -l | grep ssh

Конечно, мы могли бы выбрать и этот порт для SSH, но это только если мы уверены, что нам не нужно будет использовать эту конкретную машину для любых связанных с JBoss сервисов, мы можем затем изменить существующее правило SELinux и назначить этот порт для SSH:

# semanage port -m -t ssh_port_t -p tcp 9999

После этого мы можем использовать команду semanage для проверки правильности назначения порта и опцию -lC (сокращение от «list custom»):

# semanage port -lC
# semanage port -l | grep ssh

Теперь мы можем перезапустить SSH и подключиться к сервису с помощью порта 9999. Обратите внимание, что это изменение сохранится даже после перезагрузки.

ПРИМЕР 2: Установка директивы DocumentRoot вне /var/www/html для виртуального хоста

Если вам нужно настроить виртуальный хост Apache, используя каталог, отличающийся от /var/www/html, как в случае с DocumentRoot (скажем, например, /websrv/sites/gabriel/public_html), выполните:

DocumentRoot “/websrv/sites/gabriel/public_html”

Apache откажется обслуживать контент, потому что index.html был помечен SELinux как default_t, а Apache не может получить доступ к такому типу файла:

# wget http://localhost/index.html
# ls -lZ /websrv/sites/gabriel/public_html/index.html

Как и в предыдущем примере, вы можете использовать следующую команду, чтобы убедиться, что это действительно проблема связанная с SELinux:

# cat /var/log/audit/audit.log | grep AVC | tail -1

Чтобы изменить метку /websrv/sites/gabriel/public_html рекурсивно на httpd_sys_content_t, выполните:

# semanage fcontext -a -t httpd_sys_content_t "/websrv/sites/gabriel/public_html(/.*)?"

Вышеупомянутая команда предоставит доступ для Apache только к этому каталогу и всему его содержимому.

Наконец, чтобы применить изменения политики, выполните следующие действия:

# restorecon -R -v /websrv/sites/gabriel/public_html

Теперь вы должны иметь доступ к данному каталогу:

# wget http://localhost/index.html

Для получения дополнительной информации о SELinux рекомендуем ознакомится с: «Fedora 22, SELinux and Administrator guide«.

Введение в AppArmor и использование его на OpenSUSE и Ubuntu

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

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

Как и SELinux, AppArmor запускает профили в двух режимах. В режиме enforce (принудительного применения) приложениям предоставляются минимальные разрешения, необходимые для их запуска, тогда как в режиме complain AppArmor позволяет приложению выполнять ограниченные действия и сохраняет «жалобы», возникающие в результате этих операций, в журнал (/var/log/kern.log, /var/log/audit/audit.log и другие журналы внутри /var/log/apparmor).

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

Текущее состояние AppArmor можно посмотреть, используя:

$ sudo apparmor_status

Приведенный выше скриншот указывает, что профили /sbin/dhclient, /usr/sbin/ и /usr/sbin/tcpdump находятся в режиме принудительного исполнения (это по умолчанию реализовано в Ubuntu).

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

Мы будем использовать профили apparmor, поскольку написание собственных профилей выходит за рамки сертификации LFCS. Однако, поскольку профили представляют собой текстовые файлы, вы можете просматривать их и изучать их при подготовке к созданию собственных профилей в будущем.

Профили AppArmor хранятся внутри /etc/apparmor.d. Давайте рассмотрим содержимое этого каталога до и после установки профилей apparmor:

$ ls /etc/apparmor.d

Если вы снова запустите sudo apparmor_status, вы увидите более длинный список профилей в режиме complain. Теперь вы можете выполнить следующие операции:

Для переключения профиля, находящегося в режиме принудительного исполнения, на режим complain, вам необходимо:

$ sudo aa-complain /path/to/file

и наоборот (complain -> enforce):

$ sudo aa-enforce /path/to/file

В вышеуказанных случаях допускается использование подстановочных знаков. Например:

$ sudo aa-complain /etc/apparmor.d/*

поместит все профили внутрь /etc/apparmor.d в режим complain.

$ sudo aa-enforce /etc/apparmor.d/*

переключит все профили в режим принудительного ввода (enforce).

Чтобы полностью отключить профиль, создайте символическую ссылку в каталоге /etc/apparmor.d/disabled:

$ sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/

Для получения дополнительной информации об AppArmor обратитесь к официальной странице вики AppArmor или к документации, предоставленной Ubuntu.

Итоги 

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

Стать сертифицированным системным администратором Linux, курсы Linux

Спасибо за уделенное время на прочтение статьи!

Если возникли вопросы, задавайте их в комментариях.

Подписывайтесь на обновления нашего блога и оставайтесь в курсе новостей мира инфокоммуникаций!

Чтобы знать больше и выделяться знаниями среди толпы IT-шников, записывайтесь на курсы Cisco, курсы по кибербезопасности,  полный курс по кибербезопасности от Академии Cisco, курсы Linux от Linux Professional Institute на платформе SEDICOMM University (Университет СЭДИКОММ).