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