SELinux на практике: базовая настройка и типовые ошибки

Что такое SELinux и как он дополняет обычные права Linux

SELinux – это дополнительный механизм защиты в Linux. Он не заменяет обычные права на файлы, а работает поверх них и проверяет действия процессов строже.

В классической модели Linux доступ зависит от владельца, группы и прав: кто может читать файл, кто может его изменить, кто может запустить. Например, если у файла стоят права 644, владелец может его читать и менять, а остальные – только читать.

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

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

Как проверить состояние SELinux и безопасно переключать режимы

У SELinux есть три основных состояния:

• Enforcing – SELinux работает и блокирует действия, которые нарушают политику безопасности;
• Permissive – SELinux не блокирует действия, но записывает предупреждения в журнал;
• Disabled – SELinux полностью отключен.

Чтобы проверить, в каком режиме сейчас работает система. Выполните:

getenforce

Она вернет один из вариантов. Например:

Enforcing

Это значит, что SELinux включен и применяет правила.

Более подробную информацию показывает команда:

sestatus

В выводе будет видно, включен ли SELinux, какой режим активен сейчас и какой режим задан в конфигурации.

Временное переключение режима

Для диагностики лучше не отключать SELinux полностью, а временно перевести его в режим Permissive. Так он продолжит фиксировать нарушения, но не будет мешать работе сервисов.

Переключить SELinux в Permissive можно командой:

sudo setenforce 0

А вернуть строгий режим:

sudo setenforce 1

Важно! setenforce меняет режим только до перезагрузки системы – затем SELinux снова возьмет режим из конфигурационного файла.

Если нужно быстро проверить, что проблема связана с SELinux, этот способ для вас. Например, если сервис не запускался в Enforcing, но заработал в Permissive, значит, SELinux что-то блокирует. Дальше нужно смотреть журналы и исправлять контексты, политики или параметры, а не оставлять систему в ослабленном режиме.

Постоянное изменение режима

Постоянный режим SELinux задается в файле:

/etc/selinux/config

В нем есть строка:

SELINUX=enforcing

Ее можно изменить, например, на одно из следующих значений:

SELINUX=enforcing
SELINUX=permissive
SELINUX=disabled

Но отключать SELinux через:

SELINUX=disabled

стоит только в редких случаях. Это не лучший способ исправить проблему, потому что вместе с ошибкой исчезает и дополнительный уровень защиты. Если сервис не запускается или приложение получает отказ в доступе, сначала используйте permissive. Так можно собрать ошибки, проверить журналы и исправить настройки без полного отключения SELinux.

В полном отключении есть смысл в редких случаях: например, если система используется для тестов, где SELinux точно не нужен. На рабочем сервере лучше оставить enforcing.

Настройку SELinux лучше сначала обкатать на отдельном сервере: так проще проверить команды, восстановление контекстов и работу сервисов в разных режимах. В SpaceWeb можно арендовать VPS Linux с root-доступом для настройки SELinux: так вы получите полный доступ к системе, защиту от DDoS и актуальное ПО.

Контексты и метки: почему сервис не видит файл или каталог

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

Причина кроется в том, что SELinux смотрит не только на обычные права Linux. Для него важна еще и метка безопасности – контекст. По ней система понимает, с каким типом объекта работает процесс.

Например, веб-сервер может читать файлы сайта, если они помечены как веб-контент. Но если скопировать файлы из домашнего каталога администратора или распаковать архив в нестандартную директорию, у них может остаться неподходящая метка – тогда SELinux заблокирует доступ, даже если права доступа настроены верно.

Посмотреть контексты можно через ключ -Z:

ls -Z /var/www/html

В выводе отобразится не только владелец и права, но и SELinux-контекст. Например:

-rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.html

Обратите внимание на часть httpd_sys_content_t: она показывает SELinux, что файл относится к содержимому сайта и его можно читать.

Если файл получил другую метку, сервис может его не увидеть. Например, если файл перенесли из домашней директории:

mv ~/index.html /var/www/html/

У файла мог сохраниться старый контекст. Поэтому лучше либо создавать файлы сразу в нужном каталоге, либо восстановить правильные метки.

Чтобы восстановить стандартные контексты, воспользуйтесь командой:

sudo restorecon -Rv /var/www/html

Она сверяет путь с правилами SELinux и возвращает файлам ожидаемые метки.

SELinux ориентируется на заранее заданные правила — и если каталог находится в необычном месте, система не поймет, что это, к примеру, файлы сайта. Поэтому одной команды restorecon будет мало: сначала надо добавить новое правило для этого расположения, чтобы SELinux узнал про него. И только после этого restorecon сможет правильно расставить метки безопасности.

Пример для нестандартного каталога сайта:

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/site(/.*)?"
sudo restorecon -Rv /srv/site

Первая команда говорит SELinux, какой тип должен быть у файлов в этом каталоге. Вторая применяет метки на практике.

Настройка портов для сервисов

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

Например, веб-серверу обычно разрешены порты 80 и 443. Если перенести сайт на нестандартный порт, например 8081, обычной настройки nginx или Apache может быть недостаточно. Сервис настроен правильно, порт свободен, файрвол не мешает, но запуск все равно заканчивается ошибкой. Причина может быть в SELinux: он не считает этот порт подходящим для веб-сервера.

Важно! Не путайте SELinux и файрвол. Последний отвечает за то, можно ли подключиться к порту извне, а SELinux – за то, есть ли у конкретного сервиса право использовать этот порт.

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

Чтобы настроить порты для конкретного сервиса, сначала нужно посмотреть, какие уже разрешены. В случае с HTTP можно выполнить:

sudo semanage port -l | grep http_port_t

В выводе будут порты, которые SELinux считает допустимыми для веб-сервера. Если нужного порта там нет, его нужно добавить:

sudo semanage port -a -t http_port_t -p tcp 8081

Теперь веб-сервер сможет работать на порту 8081.

Для других сервисов используется тот же принцип: нужно найти подходящий тип порта и добавить к нему нужный номер. Например, для SSH используется тип ssh_port_t, для PostgreSQL – postgresql_port_t, для MySQL – mysqld_port_t.

Если порт уже есть в правилах SELinux, но привязан к другому типу, команда добавления может завершиться ошибкой. В таком случае можно изменить существующую запись:

sudo semanage port -m -t http_port_t -p tcp 8081

Если правило больше не нужно, его можно удалить:

sudo semanage port -d -t http_port_t -p tcp 8081

Логические переключатели в SELinux

Логические переключатели booleans в SELinux включают или отключают отдельные разрешения для сервисов. С ними вам не нужно писать собственные правила политики. Нужно только найти подходящий параметр и изменить его значение.

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

Посмотреть все доступные параметры можно командой:

getsebool -a

Чаще всего список большой, поэтому удобнее искать параметры по названию сервиса:

getsebool -a | grep httpd

У веб-сервера могут быть следующие параметры:

httpd_can_network_connect --> off
httpd_can_sendmail --> off
httpd_enable_homedirs --> off

Значение off означает, что разрешение выключено, а on – включено.

Если веб-приложению нужно подключаться к другому сервису по сети, можно включить параметр httpd_can_network_connect:

sudo setsebool -P httpd_can_network_connect on

Ключ -P делает изменение постоянным. Без него настройка будет действовать только до перезагрузки.

Отключается переключатель так же:

sudo setsebool -P httpd_can_network_connect off

Совет! Включайте переключатели SELinux только при необходимости. Не активируйте все параметры сразу. Например, если веб-сервер не отправляет почту, оставьте параметр httpd_can_sendmail выключенным. А если сайту не нужен доступ к домашним каталогам пользователей, не включайте httpd_enable_homedirs.

Как читать ошибки SELinux и находить причину блокировки

Когда сервис не запускается или приложение не работает с файлом, который есть на диске, возможно, SELinux заблокировал какое-то действие. Вместо того чтобы искать причину наугад, нужно узнать, что именно пошло не так.

Первое, что стоит проверить, – журнал аудита. В большинстве случаев сообщения SELinux попадают в файл:

/var/log/audit/audit.log

Искать последние отказы удобно через команду:

sudo ausearch -m avc -ts recent

Здесь avc – это сообщения об отказах доступа, а recent ограничивает вывод недавними событиями. Как правило, этого достаточно, чтобы увидеть, какой процесс пытался выполнить действие, к какому файлу, каталогу или порту он обращался и почему получил запрет.

В сообщении нужно смотреть не на все строки сразу, а на несколько ключевых частей:

denied  { read }  pid=1234 comm="httpd" name="index.html"

По выводу видно, что SELinux запретил чтение файла. Дальше обычно указаны контексты процесса и объекта. Они помогают понять, кто пытался получить доступ и к чему именно.

Например, если веб-сервер не может прочитать файл сайта, в журнале может быть видно, что процесс httpd обращается к файлу с неподходящей меткой. В такой ситуации проблема чаще всего не в правах chmod и не во владельце файла, а в контексте SELinux. Тогда нужно восстановить правильные метки для каталога.

Если нужен более понятный вывод, можно использовать audit2why:

sudo ausearch -m avc -ts recent | audit2why

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

Таким образом, при появлении ошибки нужно:

1. Посмотреть, какой процесс получил отказ.
2. Понять, какое действие было запрещено: чтение, запись, запуск или подключение к порту.
3. Найти объект, к которому был доступ: файл, каталог, сокет или порт.
4. Проверить контекст объекта.
5. Проверить, нет ли готового переключателя политики для этого действия.
6. Исправить причину и повторить проверку.

Не стоит сразу отключать SELinux. Лучше сначала воспроизвести ошибку, посмотреть свежие записи в журнале и понять, что конкретно заблокировано.

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

Типовые ошибки SELinux на практике и быстрые решения

Заключение: как работать с SELinux без риска для сервера

Работая с SELinux, помните: лучше потратить время на грамотную настройку, чем отключать механизм защиты.

Придерживайтесь алгоритма: сначала диагностируйте проблему через логи (/var/log/audit/audit.log), затем тестируйте в режиме permissive, вносите точечные изменения в политики и только после этого включайте режим enforcing. Так вы минимизируете сбои и сохраните высокий уровень защиты.