Настройка SELinux: сервисы падают после включения ограничений
Включение мандатного доступа на узле, который годами работал без него, редко проходит гладко. Веб-сервер перестаёт читать каталог со статикой, база данных не поднимается после перезапуска, а задачи по расписанию завершаются молча — отказ сервиса после включения выглядит как случайный набор сбоев, хотя причина у них одна.
Политика описывает не пользователей, а процессы: какой службе разрешено открыть файл, занять порт, обратиться к сокету. Метки на объектах проставляются при создании и копировании, поэтому каталог, куда выкладывается релиз, легко получает метку временного каталога — и служба, для которой он родной, читать оттуда уже не вправе.
Дальше начинается коварная часть. В мягком режиме нарушение только фиксируется, поэтому настройка SELinux проходит «успешно»: инженер видит зелёный статус, а после перехода в жёсткий служба стартует и отдаёт лишь часть запросов. Отказы уходят в аудит запретов, а не в лог приложения, поэтому сбой ищут где угодно, кроме настоящей причины.
Цена такой картины — не один простой, а постепенная деградация. Администраторы либо отключают мандатный доступ целиком, возвращая исходный уровень риска, либо добавляют разрешения наугад. Через месяц уже никто не объяснит, зачем выдано очередное правило, и диагностика политик превращается в археологию.
Порядок работ здесь обратный привычному: сначала аудит запретов — что и к какому объекту не получило доступ, какие метки реально стоят на файлах и портах, — и только потом правки политики. Разбираем, как это закрывается.
Измеримый эффект: что меняется после внедрения MAC-политик
После внедрения мандатного контроля доступа SELinux или AppArmor меняется не только модель прав, но и измеримые эксплуатационные показатели. Политика описывает, что разрешено конкретному процессу, независимо от учётной записи, — поэтому эффект виден в метриках инцидентов, а не только в отчёте аудита.
Поверхность атаки сокращается
Разграничение прав уезжает на уровень ядра: сервис видит только свои каталоги, порты и сокеты, остальное для него не существует. Процесс с захваченным веб-приложением больше не читает чужие конфигурации и не пишет в системные каталоги. Класс сценариев «вошли через сервис — закрепились на хосте» перестаёт работать на этом шаге.
Время реакции на инцидент сокращается
Раньше разбор начинался с вопроса «что вообще произошло»: сверяли права, историю изменений, открытые порты. Теперь запрет фиксируется в журнале с именем процесса, путём и типом операции — точка входа и виновник видны сразу. Расследование укладывается в один проход по журналу, без полного сбора событий со всего хоста.
Предсказуемость сервисов
Политика перечисляет штатный набор операций, поэтому сервис ведёт себя одинаково на стенде и на боевом контуре: после обновления он не получает случайно расширенных прав. Отклонения от разрешённого набора видны явно, а не всплывают через недели в виде странных ошибок.
Ушедший класс отказов
Запуск от чужой учётной записи, унаследованные права после ручной правки, скрипт из постороннего каталога — эти ситуации закрываются политикой до их появления. Чек-лист приёмки релиза сокращается: часть гарантий даёт ядро, а не регламент.
Режимы защиты и способы настройки: сравнение вариантов
Выбор режима определяет, что произойдёт при отклонении процесса от разрешённого поведения: событие попадёт только в журнал или операция будет заблокирована. Для SELinux настройка начинается с этого решения — от него зависит порядок внедрения и объём разбора срабатываний.
Что выбрать
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Мягкий режим наблюдения | Первый прогон правил на боевом узле, инвентаризация обращений | Ничего не блокирует: нарушения копятся в журнале, защиты как таковой пока нет |
| Принудительный режим | Сервисы с устойчивым набором операций, публичные узлы | Ложные срабатывания после обновления приложений — нужен разбор и правка правил |
| Профили отдельных приложений | Один-два сервиса с известным поведением, изоляция процесса | Покрывают только свой процесс, остальные живут вне мандатных ограничений |
| Полный отказ от мандатного контроля | Узкие задачи, где сопровождение политики дороже риска | Разграничение сводится к обычным правам файловой системы |
Рабочий порядок — начать в мягком режиме наблюдения, собрать журнал за полный цикл работы сервиса вместе с обновлениями, затем перевести узел в принудительный режим. Исключения оставляют только там, где поведение процесса разобрано: необъяснённое правило обнуляет смысл политики доступа.
Ограничение подхода в том, что политики доступа требуют сопровождения. Обновление сервиса меняет набор обращений, и без владельца правил мандатный контроль становится источником отказов — профили отдельных приложений сужают площадь риска, но не заменяют изоляцию и регулярные обновления.
Порядок внедрения политик: от аудита до передачи
Порядок выстроен так, чтобы ни один рабочий сервис не остановился из-за политики: сначала собираем факты, потом ограничиваем. Пропуск любого шага возвращает нас к ручному разбору отказов в момент, когда сервис уже недоступен.
- Инвентаризация и аудит конфигурации. Фиксируем списки служб, слушающих порты, их каталоги данных, сокеты, каталоги обмена и точки монтирования. Отдельно отмечаем, где уже стоят локальные послабления — их придётся пересобрать.
- Режим наблюдения. Переводим контур в щадящий режим, когда нарушения только логируются, а не блокируются, и держим его не меньше полного цикла: суточные задания, ротация журналов, обновление пакетов, ночная выгрузка.
- Сбор и разбор срабатываний. Записи аудита группируем по процессу и типу доступа, отделяем штатное поведение от реальных выходов за профиль. На этом шаге видно, какие службы придётся описать точнее, а какие пишут в неожиданные места.
- Оформление правил. Свой модуль на каждый сервис вместо одного общего: при обновлении службы пересобирается только её профиль, а не весь контур. Послабления описываем точечно, с привязкой к пути и метке.
- Проверка на копии контура. Поднимаем слепок, включаем блокировку и прогоняем регресс: запуск, миграции, резервное копирование, переключение при отказе узла.
- Ввод в эксплуатацию. Включаем по группам служб, с окном наблюдения после каждой группы и готовым возвратом в щадящий режим.
- Передача. Политики и регламент их обновления уходят в репозиторий: схемы зависимостей, журнал послаблений, порядок действий при добавлении новой службы.
Настройка SELinux: конфигурации, политики, документация
Результат внедрения — не только работающий сервер, но и комплект, по которому ваша команда сопровождает политику без нас. Ниже — перечень того, что остаётся на руках после сдачи.
- Файлы конфигурации — снятое с рабочего сервера состояние главного конфига и параметров загрузки, с пометками, какие значения обязательны, а какие допустимо менять.
- Модули политик — исходники и собранные модули под каждый сервис, с комментарием, за что отвечает домен и почему правило сформулировано именно так.
- Схема потоков доступа — карта: какой процесс в каком домене работает, к каким типам файлов и сетевым портам обращается, где стоит запрет.
- Регламент изменений — последовательность: собрать отчёт о блокировках на тестовом контуре, сформировать модуль, проверить и только потом выкатить на боевой.
- Инструкции для дежурной смены — что искать в журнале аудита, как отличить ложную блокировку от попытки эксплуатации и как точечно ослабить правило, не снимая защиту целиком.
- Процедура отката — снимок конфигурации и политик до изменений плюс порядок возврата, если обновление сервиса ломает существующие правила.
- Карта покрытия — список сервисов под политикой, список в работе и явно указанное, что осознанно оставлено без ограничений и почему.
Кейс: сервис перестал падать после включения ограничений
Проект начался с разбора инцидентов: сервис на Linux-хосте несколько раз за квартал уходил в отказ, и каждый раз причиной оказывался процесс, получивший лишние права после ручного вмешательства. SELinux был включён, но в режиме записи нарушений без блокировки — ядро фиксировало их и пропускало, поэтому в журналах копились записи, а реальной границы у приложения не существовало.
Что показывали метрики до
Доля простоев держалась на уровне нескольких часов в квартал: средний эпизод — около 50 минут, восстановление занимало от 40 минут, потому что инженер вручную сопоставлял записи ядра с конфигурацией. Открытых разрешающих правил накопилось больше двухсот — половину добавляли «на всякий случай» при очередном сбое. Повторные инциденты возвращались каждые две-три недели, и правки их число не уменьшали.
Что изменили и что получили
Мы пересобрали политику с нуля: оставили только разрешения, подтверждённые трассировкой рабочих сценариев, и переводили домены в режим принуждения по одному. Число открытых правил сократилось примерно до сорока, каждое описано и привязано к конкретному процессу или каталогу. Время восстановления после сбоя упало до нескольких минут: раскладка политики читается человеком, а не только ядром.
За два квартала наблюдения повторных инцидентов не было ни одного, а доля простоев сократилась в разы. Профиль AppArmor на втором хосте собрали по той же схеме — от трассировки реальных вызовов, а не от запрета всего подряд.
Чем отличается мягкий режим от принудительного
Оба режима работают на одной и той же загруженной политике — расходятся они только в том, приводится ли вердикт в исполнение. В мягком режиме наблюдения правило проверяется на каждом обращении к файлу, сокету или процессу, но блокировка не срабатывает: приложение получает доступ, а система лишь фиксирует факт нарушения. Принудительный режим на том же вердикте останавливает операцию — процесс получает отказ, и повторить попытку не сможет.
Отсюда и главный риск перехода: набор разрешений, который в наблюдении выглядел рабочим, в блокировке начинает рвать привычные сценарии. Тот же принцип в AppArmor, где аналог наблюдения — режим жалоб: профиль активен и пишет срабатывания, но доступ не отсекает. Смысл промежуточного шага именно в этом — увидеть поведение системы на живой нагрузке до того, как запреты начнут действовать.
Журнал срабатываний — единственный надёжный источник для перехода между режимами. Оттуда вытаскиваются отказы с указанием домена, целевого типа и класса объекта: по ним видно, какой процесс стучится не туда, а где политика просто слишком узкая. Сначала отделяют ложные срабатывания от настоящих запретов, снимают лишние ограничения, проверяют результат на тестовом контуре — и только потом включают принуждение.
Безопасный переход делают поэтапно: общий режим оставляют наблюдательным, а в принуждение переводят по одному домену или службе. Если после включения сервис не поднимается, возврат в наблюдение занимает секунды и не требует перезагрузки — отказ получает только конкретный домен, а не весь узел. Принудительный режим оправдан тогда, когда журнал чист от неожиданных срабатываний и есть отрепетированный регламент откатa.
Частые технические сомнения перед внедрением политик
Сомнения здесь закономерны: мандатный контроль — это слой, который может заблокировать работу приложения там, где обычные права доступа её пропускали. Поэтому внедрение строим не как «включить и посмотреть», а как управляемый переход по узлам и сервисам с наблюдаемостью на каждом шаге.
Нестандартное приложение не заработает под enforcing — что тогда?
Сначала узел переводится в режим permissive: политики применяются, но не блокируют, а все отказы попадают в журнал с метками процессов и файлов. Инженер разбирает их и описывает локальный модуль или правила для нужных путей и типов — правки точечные, а не «разрешить всё». В enforcing переводим отдельно взятый сервис, а не машину целиком, чтобы не тянуть за собой остальные.
Что будет при обновлении системы и приложений?
Политика опирается на пути, метки и типы, а не на конкретную сборку, поэтому обновление обычно её не ломает. Риск возникает, когда меняется структура каталогов или появляется новый вспомогательный процесс — тогда в журнале снова видно отказы. Мы прогоняем обновление на тестовом стенде с реальной нагрузкой и сверяем журнал до переноса на боевые узлы.
Нужен ли простой и насколько длинный?
На большинстве сервисов простой не требуется: развёртывание политик и сбор отказов идут на работающей системе в permissive. Короткая остановка возможна только на переключении в enforcing у сервисов, которые нельзя перезапускать на лету, — окно согласуем заранее и держим его в пределах одного цикла обслуживания.
Кто поддерживает политики после передачи?
Модули, конфигурации и список исключений передаём в системе контроля версий с комментариями к каждому правилу. К этому идёт инструкция по типовым сценариям: добавили сервис, сменили каталог данных, после обновления появились отказы. Ваши инженеры вносят такие правки по чек-листу, мы подключаемся к нестандартным случаям.
Какие риски остаются и как откатиться?
Слишком узкая политика ломает работу при редком сценарии, слишком широкая — не даёт защиты; баланс проверяем на стенде, а не на бою. Возврат в permissive — одна команда, узел продолжает обслуживать нагрузку. Отдельно фиксируем состояния до внедрения, чтобы откат занимал минуты, а не часы разбора.
Обсудим задачу и вернёмся с оценкой и планом работ
Для предметного обсуждения задачи нужны исходные данные: без них оценка сроков превращается в догадки, а политики ограничения доступа пишутся «по памяти» и ломают рабочие сервисы на первом же обновлении. Пришлите то, что уже есть, — конфигурации, выгрузки, схемы, заметки в свободной форме.
- Состав сервисов и узлов: какие приложения работают, под какими учётными записями, какие каталоги, порты и сокеты им действительно нужны.
- Схема контура: где проходят границы между периметром, приложением и данными, какие узлы обмениваются трафиком.
- Текущее состояние защиты: включён ли режим ограничения прав или пока только режим аудита, какие профили уже применены, что дописано руками.
- Ограничения и запреты: что нельзя менять — порядок обновления, допустимое время простоя, окна работ, требования к доступности.
- Цели по доступам: кому и к каким данным нужно ходить, какие операции должны быть разрешены, а какие заблокированы безусловно.
- Роли и автоматизация: кто из сотрудников что обслуживает, какие задачи выполняются скриптами и от чьего имени.
- Логи и оповещения: куда собираются события, есть ли контроль блокировок и падений служб после смены политики.
Следующий шаг — мы разбираем присланное, уточняем недостающее, и возвращаемся с планом работ: поэтапный перевод политик в режим ограничения, схема откатов, оценка сроков по каждому контуру. Часть данных можно снять прямо на серверах и вписать в план отдельным этапом.
