Чому 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

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