Root у терміналі, відмова під SELinux: чому hook не спрацьовує

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

Та сама команда, два різні домени безпеки

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

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

Класична форма цієї несправності — помічник, який викликає зовнішній інструмент. Сам hook може бути дозволений, тоді як інструмент, який він викликає, має мітку, яку домен служби не може виконати, або пише в каталог, мітка якого це забороняє.

Прочитайте запис AVC поруч із помилкою hook

Відмова AVC називає поля, які вирішують справу: контекст джерела процесу, контекст цілі об'єкта, клас об'єкта й конкретний відхилений дозвіл. Прочитайте всі чотири, перш ніж будувати теорію, бо відмова на виконання й відмова на запис потребують зовсім різних виправлень.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

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

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

Мітка, конфігурація або політика: три виправлення

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

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

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

Чому старий модуль allow не є відповіддю

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

Він також приховує наступну невдачу. Модуль, що дозволяє широкий клас операцій, змусить цю помилку зникнути й перетворить наступну на щось значно важче пов'язуване. Видалення модуля пізніше — теж зміна, яку ніхто не хоче планувати, тож короткий шлях має властивість ставати постійним.

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