Почему nosuid мешает помощнику VPN стать root

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

Два несвязанных свойства

Шифрование диска отвечает на вопрос, кто может читать блоки, когда машина выключена. Опция монтирования отвечает на вопрос, что ядро сделает с битами режима файла, когда кто-то его запустит. Ничто в первом не ограничивает второе, и полностью зашифрованный ноутбук может смонтировать файловую систему со всеми ограничениями на месте.

Чтение их как одного свойства и порождает теорию о том, что зашифрованный домашний каталог мешает доступу root. Эта теория держится потому, что оба симптома появляются на одной машине, а не потому, что у них общая причина.

Что на самом деле подавляет переход

Справочная страница execve описывает, как исполняемый файл с set-user-ID меняет действующий идентификатор нового процесса на владельца файла. Там же перечислены условия, которые подавляют этот переход, и их эквивалент для идентификаторов групп: настройка no_new_privs, файловая система, смонтированная с nosuid, и процесс, который трассируется. Возможности файла игнорируются при тех же условиях. Эти четыре правила охватывают почти каждый отчёт такого рода.

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

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

Чего делать не стоит

Ставить биты set-user-ID на непроверенный бинарник и переставлять его с места на место, пока ограничение не исчезнет, — это не починка. Это заменяет политику, которую вы не поняли, привилегией, которую вы не можете проверить, а тот же приём, применённый к помощнику, — известный путь повышения прав. Убирать nosuid из монтирования хуже, потому что это затрагивает каждую программу в этой файловой системе, а не только одну.

Поддерживаемый путь — это документированная установка помощника или службы клиента, выполняемая администратором, которая помещает бинарник туда, где его ожидает политика. Так остаётся один механизм привилегий вместо двух.

Подтвердите реальный контекст запуска

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

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

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

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