Не нашаровуйте посилення systemd на скидання user у OpenVPN

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

Дві моделі, один власник перемикання

Перша модель належить демону. Параметри OpenVPN зі збірки спільноти user і group змінюють ідентичність після налаштування тунелю та ключів, а persist-key разом із persist-tun зберігають ці ресурси придатними до використання після цього.

Друга модель належить менеджеру служб. Налаштування systemd User= або Group= визначає ідентичність, під якою стартує процес, а директиви можливостей визначають, що він може утримувати. Вибір між моделями — це питання пакування раніше, ніж питання безпеки, і супровідник пакета вже на нього відповів. Ваше завдання — знайти цю відповідь, а не вигадати третій варіант.

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

Вирішіть, де змінюється ідентичність

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

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

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

Можливості — це межі, а не дарунок

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

Те, що справді поміщає можливість в оточення служби, — це AmbientCapabilities=. довідник із виконання systemd документує ці дві директиви окремо, і ця різниця пояснює більшість плутаних порад про можливості в інтернеті.

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

Розподіліть повноваження на життєвий цикл

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

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

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

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

Запишіть план і збережіть доступ для відновлення

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

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

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