Чому переміщення сертифіката VPN ламає його мітку SELinux

Сертифікати можуть лежати в правильному каталозі з читабельним режимом і власником root, а служба все одно може повідомити, що не може відкрити файл. У системі SELinux таке поєднання вказує на один конкретний механізм, а не на права. Мітка переїхала разом із файлом, бо перейменування не створює нового об’єкта. Inode зберіг контекст безпеки, який мав на старому шляху, а політика нового шляху так і не отримала можливості призначити свій.

Що перейменування насправді робить із міткою

Файл несе свій контекст SELinux як дані атрибута, прив’язані до inode. Перейменування в межах однієї файлової системи змінює запис каталогу і більше нічого, що швидко й атомарно, і саме тому контекст переживає переміщення. Жодна політика не запитується, жодне значення за замовчуванням не застосовується і жодне попередження не друкується.

Копіювання поводиться інакше. Копія створює новий inode у цільовому каталозі, і політика призначає контекст за типом цього каталогу, тому скопійований сертифікат зазвичай отримує правильну мітку, а переміщений залишається неправильним. Саме ця єдина відмінність пояснює більшу частину плутанини в цьому класі заявок.

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

Прочитайте поточну мітку напроти очікуваної

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

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

Відновіть зіставлення замість того, щоб вигадувати виняток

Для стандартного розташування політика вже зіставляє шлях, тому restorecon застосовує його, і робота завершена. Тримайте область у межах каталогу, який ви ремонтуєте; перемаркування всієї файлової системи повільне, руйнівне і ховає початкову помилку під дуже великою зміною.

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

Чому chcon не є рішенням

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

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

Коли мітка правильна, а доступ усе одно не працює

Почніть із батьківських каталогів. Дозвіл на прохід перевіряється на кожному компоненті шляху, тому правильно позначений сертифікат у каталозі, куди служба не може увійти, залишається нечитабельним. І SELinux, і звичайний дозвіл мають дозволяти кожен крок, і виправлення одного не виправляє іншого.

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

Пам’ятайте, що правила dontaudit можуть пригнічувати повідомлення про відмову, тому порожній журнал аудиту — слабкий доказ, а не доказ. Якщо політика виглядає правильною, а доступ усе одно не працює, дослідіть, перш ніж створювати широкий модуль дозволів, і не вимикайте SELinux, щоб симптом зник. Обидва короткі шляхи дають систему, яка здається робочою, і позицію безпеки, яку ніхто не може описати. Коротке розслідування краще за будь-який із них.