Ваша команда VPN працює без привілеїв; служба — ні

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

Інтерфейс, механізм і перевірка

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

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

Делегування — звичайний задум

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

NetworkManager — конкретний приклад у Linux. Його посібник із конфігурації пояснює, як PolicyKit авторизує запити не від root у типовому налаштуванні. Це показує делеговану авторизацію в реальному продукті. Це не доводить, що кожен комерційний клієнт використовує NetworkManager, і не описує шлях сокета чи політику якогось конкретного постачальника.

Зразок — це делегування, за яким стоїть політика. Приклад — одна реалізація цього зразка, не універсальна.

Читайте межу, а не запит

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

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

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

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

Виправляйте дозволи підтримуваним способом

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

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

Як виглядає добрий поділ

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

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