Все статьи раздела «Системное администрирование»

Настройка политик безопасности SELinux

Краткое описание принципов настройки весьма важной защитной системы в Linux — политик безопасности SELinux на примере решения проблемы с отправкой почты из странички на PHP.

Введение

После установки чистой Fedora Core 9 на очередной сервер обнаружилось, что при отправке письма через стандартную функцию PHP mail. В журнале sendmail (/var/log/maillog) была обнаружена запись вида

sendmail[22284]: NOQUEUE: SYSERR(apache): /etc/mail/sendmail.cf: line 0: cannot open: Permission denied

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

Что такое система безопасности SELinux

SELinux это набор технологий управления безопасностью для Linux, разработанный компаниями Network Associates и MITRE по заказу NSA (Агентства Национальной Безопасности США) в рамках повышения безопасности Linux для использования его в проектах агентства. В 2000 году это расширение было выпущено в виде общедоступного кода и к настоящему моменту существует во всех популярных дистрибутивах. Основная задача, которую позволяет решить SELinux — более тонкая настройка прав на выполнение тех или иных действия в ОС, по сравнению с базовым принципом "одному или всем", который применяется для контроля доступа к объекта файловой системы.

Система безопасности SELinux встроена в ядро операционной системы и контролирует все выполняемые операции, проверяя их на соответствие заданным политикам безопасности. Последние динамически загружаются в ядро в виде скомпилированных двоичных файлов. При выполнении практически любой системной операции (создать, открыть, прочитать, удалить и т.д.) над объектом (файлом, каталогом, сокетом и т.д.) система безопасности проверяет, разрешена ли эта операция запрашивающему субъекту (процессу, действующему от имени определенного пользователя системы). Если разрешена, то операция выполняется, если нет — операция заканчивается с ошибкой, а информация о запросе обычно помещается в специальный журнал /var/log/audit/audit.log. Читая данный журнал администратор может выяснить, что именно пытался сделать процесс (субъект), какое действие над каким объектом было запрещено.

Управление политиками безопасности

Для управления политиками безопасности SELinux в системе предусмотрены графические программы и набор консольных утилит. Поскольку чаще всего к серверу есть только терминальный доступ в текстовом режиме (обычно Xsystem на сервер вообще не ставят), то будем рассматривать только работу в консоли.

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

semodule — инструмент управления модулями политик безопасности в ядре. Позволяет устанавливать, обновлять, включать/выключать и удалять модули, а также получать информацию о текущих загруженных модулях.

checkmodule и semodule_package — "компилятор" и "линкер" модулей безопасности в терминах языков программирования. Позволяют собрать бинарный модуль из текстового файла.

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

Решение практической задачи

Рассмотрим использование всего вышеперечисленного на примере решения задачи, описанной в начале статьи.

Первым делом переходим в режим суперпользователя. Далее нам предстоит выполнить итерационный процесс создания модуля, разрешающего выполнение необходимых для отправки почты операций. Несколько итераций в этом процессе необходимы потому, что разрешив первую из операций мы упремся в следующую запрещенную и так до тех пор, пока не пройдем весь путь отправки почты. Итак:

Читаем журнал аудита
```
tail -f /var/log/audit/audit.log
```
Выполняем действие, вызывающее ошибку (в нашем случае, отправляем почту)
При первом проходе выполняем команду
```
audit2allow -M HttpSendmail && semodule -i HttpSendmail.pp
```
которая создаст два файла HttpSendmail.te (набор правил безопасности в текстовом виде) и HttpSendmail.pp (скомпилированный бинарный пакет), а также установит этот пакет в систему (последнее занимает несколько секунд). После этого первая итерация закончена, начинаем все сначала.
При последующих итерациях выполняем команду
```
audit2allow -M test && cat test.te
```
На стандартный ввод подаем ей появившиеся в журнале аудита строчки, завершаем ввод ^D. Нам печатается содержимое файла конфигурации аудита, устраняющего описанные в журнале проблемы
Добавляем новые сущности и правила в наш файл HttpSendmail.te с помощью обычного текстового редактора. Обратите внимание, что действия для одинаковых сущностей можно писать в фигурных скобках, разделяя через пробел.
Не забываем увеличить версию файла конфигурации в первой строке (увеличиваем, например, число после точки). Иначе получим ошибку "libsemanage.semanage_direct_upgrade: Previous module ... is same or newer."

Пересобираем пакет конфигурации и обновляем правила ядра:

checkmodule -M -m HttpSendmail.te -o HttpSendmail.mod && semodule_package -o HttpSendmail.pp -m HttpSendmail.mod && semodule -u HttpSendmail.pp

Повторяем процесс с первого пункта, пока в логе не будет ошибок. Мне потребовалось около 6 итераций...

Заключение