Перевірте мітки, перш ніж звинувачувати SELinux

Коли застосунок ламається на хості з SELinux у режимі enforcing, рефлекс у багатьох командах полягає в тому, щоб перемкнути SELinux у permissive і рухатися далі. Ми тримаємо його в enforcing на кожному хості, який експлуатуємо, і за нашим досвідом причина зазвичай набагато менша, ніж підказує рефлекс: файл несе неправильну мітку. Ця стаття показує, як швидко це знайти, виправити правильно і не відрізати собі доступ, поки ви це робите.

Що таке мітка і як вона стає неправильною

SELinux ухвалює рішення на основі міток. Кожен файл і кожен процес несе security context, а політика каже, які типи процесів можуть робити що з якими типами файлів. Політика також каже, яку мітку має нести кожен шлях: вміст /var/www має бути httpd_sys_content_t, виконуваний файл під /usr/bin має бути bin_t і так далі. Ці очікувані мітки є правилами file context.

Файл отримує мітку при створенні, зазвичай успадковуючи її від батьківського каталогу або за правилом політики. Це добре працює, доки файли не прибувають незвичним шляхом:

• mv зберігає оригінальну мітку, тож файл, створений у домашньому каталозі й переміщений у web root, досі каже, що належить домашньому каталогу.
• Архіви, розпаковані без атрибутів SELinux, або відновлені з резервної копії, яка їх не зберегла, отримують те, що видає цільовий каталог.
• Вміст, покладений у нестандартне місце, таке як /srv/app, отримує загальну мітку, бо політика ще не має правила для цього шляху.

У кожному з цих випадків політика в порядку. Файл просто носить неправильну мітку, а процесу, якому він потрібен, відмовлено.

Спершу прочитайте відмову

Перш ніж щось змінювати, прочитайте, у чому саме SELinux відмовив:

ausearch -m AVC -ts recent

Кожна відмова називає тип процесу (scontext), тип цілі (tcontext), клас об’єкта і дозвіл. Якщо тип цілі виглядає неправильним для цього файлу (наприклад, web-серверу відмовлено в читанні чогось із міткою user_home_t), ви майже напевно дивитеся на проблему з мітками, а не на прогалину в політиці.

Порівняйте те, що є, з тим, що має бути

Три команди відповідають на питання прямо:

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

restorecon -n нічого не змінює. Воно лише повідомляє різницю між поточною міткою й очікуваною, що робить його ідеальним інструментом аудиту. Запустіть його по цілому дереву після інсталяції, відновлення або міграції:

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Порожній результат означає, що кожен файл під цими шляхами несе мітку, яку очікує політика. Будь-який рядок у виводі є файлом, який її не несе, і цей список зазвичай короткий і дуже промовистий. Ми виконуємо таку перевірку на нових збірках як рутину, а наші шаблони інсталяції перемічують критичні шляхи на кроці після інсталяції, тож новий хост починає життя з правильними мітками ще до того, як хтось увійде.

Виправте правильно

Для файлу, який просто має неправильну мітку, перемітьте його на те, що очікує політика:

restorecon -Rv /path

Для нестандартного місця, про яке політика не знає, спершу навчіть політику правилу, потім перемітьте, щоб виправлення пережило наступне повне перемічування:

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

chcon теж змінює мітки, але лише до наступного перемічування, після якого проблема повертається. Використовуйте його для експериментів, а не для виправлень.

Якщо мітки правильні, а відмова стосується поведінки, перевірте booleans, перш ніж писати політику. Багато поширених потреб, таких як відкриття web-сервером вихідних мережевих з’єднань, є одним перемикачем:

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Ставтеся до audit2allow з підозрою

audit2allow читає відмови й пише модуль політики, який їх дозволяє. Він завжди видасть щось, що працює, і саме в цьому небезпека. Якщо справжня причина є неправильно поміченим файлом, згенерований модуль надає широкий дозвіл, щоб симптом зник, і кожен інший файл і процес цього типу успадковує ослаблену політику. Читайте, що він пропонує. Правило, яке дозволяє одному домену переходити в дуже привілейований або читати все поширеного типу, є сильним натяком, що мітка неправильна, а модуль є неправильним виправленням. Власні модулі іноді правильні, для внутрішнього програмного забезпечення без власної політики, але вони мають бути останнім кроком, а не першим.

Безпечно вмикайте enforcing на віддаленому хості

Перемикання віддаленої машини з permissive в enforcing є однією з тих змін, які можуть відрізати вашу власну сесію, якщо щось досі неправильно помічене. Спершу зведіть запобіжник, щоб хост повернув себе назад, якщо ви втратите доступ:

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

systemd спрацьовує таймер незалежно від того, пережила ваша сесія чи ні. Скасовуйте його лише після того, як новий вхід пройшов успішно. Та сама схема працює для змін firewall, SSH і маршрутизації на машині, до якої ви не можете підійти.

Короткий чекліст

• Запускайте restorecon -Rnv по системних шляхах після кожної інсталяції, відновлення або міграції.
• Читайте відмову AVC і порівнюйте ls -Z з matchpathcon, перш ніж змінювати політику.
• Використовуйте semanage fcontext плюс restorecon для нестандартних шляхів, а не chcon.
• Перевіряйте booleans, перш ніж писати модуль.
• Ставтеся до виводу audit2allow як до запитання, а не до відповіді.
• Ніколи не перемикайте віддалений хост в enforcing без шляху назад за таймером.

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

Related

Пов’язане: Hardening baseline на кожному хості · Екстрене реагування на вразливості того ж дня