Ваша команда VPN работает без привилегий; служба — нет

Команда VPN работает от вашего пользователя, пароль не появляется, и туннель поднимается. Эта последовательность ощущается как операция без привилегий, и обычно ею не является. Сетевые изменения выполняет отдельная служба, и интересный вопрос в том, что эта служба сделает для вызывающего, которого она не проверила. Подсчёт запросов пароля ничего не говорит вам об этой границе.

Интерфейс, механизм и проверка

Интерфейс принимает запросы: подключиться, отключиться, выбрать профиль. Механизм владеет сетевыми операциями: создание интерфейсов, изменение маршрутов, применение фильтров. Проверка авторизации решает, может ли этот вызывающий запросить это действие. Эти три могут быть распределены между двоичным файлом, помощником и системной службой, и пользователь видит только первое.

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

Делегирование — обычный замысел

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

NetworkManager — конкретный пример в Linux. Его руководство по конфигурации объясняет, как PolicyKit авторизует запросы не от root в настройке по умолчанию. Это показывает делегированную авторизацию в реальном продукте. Оно не доказывает, что каждый коммерческий клиент использует NetworkManager, и не описывает путь сокета или политику какого-либо конкретного поставщика.

Образец — это делегирование, за которым стоит политика. Пример — одна реализация этого образца, а не универсальная.

Читайте границу, а не запрос

Найдите службу, владельца её конфигурации и локальный интерфейс, который использует фронтенд. Затем спросите, какие пользователи могут запрашивать какие операции. Возможность поднять и опустить один сохранённый профиль — не то же разрешение, что загрузка конфигурации, которую оператор никогда не просматривал. Разница — это и есть весь вопрос безопасности.

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

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

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

Исправляйте разрешения поддерживаемым способом

Сделать защищённый управляющий сокет записываемым для всех или добавить учётную запись в широкую административную группу — значит устранить одну ошибку разрешения и создать большую. Ошибка была единственным, что говорило вам о существовании этой границы. Используйте документированный процесс членства или авторизации, включая требуемое им обновление сеанса. Членство в группе часто действует только для новых сеансов входа, поэтому изменение может выглядеть безрезультатным до следующего входа.

Если продукт предлагает более узкую роль для операции, предпочтите её общему предоставлению. Запишите выбранную роль и её владельца рядом с именем службы.

Как выглядит хорошее разделение

Обычные приложения остаются без привилегий, служба выполняет только ту настройку, для которой создана, и каждый вызывающий проверяется по политике, которой кто-то владеет. Это защитимая конструкция. Она также поддаётся аудиту, потому что у политики есть связанное с ней имя. Всё большее заслуживает письменного исключения, а не тихого изменения разрешений.

Режим отказа — это служба, которая выполняет любой запрос любого локального пользователя, потому что интерфейс удобен. Со стороны пользователя это выглядит одинаково, и оно несёт гораздо большие полномочия. Проверьте один отклонённый запрос, а не только успешный. Отказ, приходящий из политики, и есть доказательство того, что политика существует.