Warum nosuid einen VPN-Helfer daran hindert, root zu werden

Festplattenverschlüsselung und ein nosuid-Mount klingen wie Varianten derselben Idee, und sie haben überhaupt nichts miteinander zu tun. Das eine schützt Daten im Ruhezustand, das andere entscheidet, ob der Kernel ein Privilegienbit in dem Moment respektiert, in dem ein Programm startet. Ein Helfer, der die erwartete Identität nicht erreicht, beschwert sich über das zweite. Die Annahme, das erste sei verantwortlich, schickt Leute los, Clients neu zu installieren, die nie defekt waren.

Zwei Unabhängige Eigenschaften

Festplattenverschlüsselung beantwortet, wer die Blöcke lesen kann, wenn die Maschine aus ist. Eine Mount-Option beantwortet, was der Kernel mit den Modusbits einer Datei tut, wenn jemand sie ausführt. Nichts am ersten schränkt das zweite ein, und ein vollständig verschlüsseltes Notebook kann ein Dateisystem mit allen Einschränkungen mounten.

Sie als eine Eigenschaft zu lesen erzeugt die Theorie, ein verschlüsseltes Home verhindere Root-Zugriff. Diese Theorie überlebt, weil die beiden Symptome auf derselben Maschine auftreten, nicht weil sie eine Ursache teilen.

Was den Übergang Tatsächlich Unterdrückt

Die execve-Referenz beschreibt, wie eine ausführbare Datei mit set-user-ID die effektive Identität des neuen Prozesses auf den Eigentümer der Datei ändert. Dieselbe Seite listet die Bedingungen, die diesen Übergang unterdrücken, und das Gegenstück für Gruppen-IDs: eine no_new_privs-Einstellung, ein mit nosuid gemountetes Dateisystem und ein Prozess, der verfolgt wird. Dateifähigkeiten werden unter denselben Bedingungen ignoriert. Diese vier Regeln decken fast jeden Bericht dieser Art ab.

Diese Liste erklärt, warum der von ls ausgegebene Modus nie die ganze Autorisierungsgeschichte ist. Sie sagt nicht, welche Bedingung eine bestimmte Fehlermeldung verursacht hat, und die Anwendung meldet möglicherweise einen unabhängigen Anmeldedatenschritt mit demselben Wortlaut. Notieren Sie das genaue Programm, den Starter und die Fehlerfolge, bevor Sie einen Schluss ziehen.

Ermitteln Sie die ausführbare Datei, die das unterstützte Paket installiert hat, ihren Eigentümer, ihren realen Pfad und die Richtlinie des Dateisystems, das sie enthält. Eine Kopie im Download-Ordner ist nicht der installierte Helfer, was auch immer ihr Modus sagt.

Was Man Besser Nicht Tut

Set-user-ID-Bits auf eine ungeprüfte Binärdatei zu setzen und sie so lange zu verschieben, bis die Einschränkung verschwindet, ist keine Reparatur. Es ersetzt eine Richtlinie, die Sie nicht verstanden haben, durch ein Privileg, das Sie nicht prüfen können, und dieselbe Technik auf einen Helfer angewandt ist ein bekannter Eskalationsweg. nosuid von einem Mount zu entfernen ist schlimmer, weil es jedes Programm auf diesem Dateisystem betrifft, nicht nur eines.

Der unterstützte Weg ist die dokumentierte Installation des Helfers oder Dienstes durch den Client, ausgeführt von einem Administrator, die die Binärdatei dorthin legt, wo die Richtlinie sie erwartet. So bleibt ein Privilegienmechanismus statt zwei.

Den Echten Startkontext Bestätigen

Starten Sie den Helfer nach einer autorisierten Korrektur so, wie das Produkt ihn startet, und nicht aus einer Root-Shell. Ein Erfolg als root beweist nichts über den Weg eines normalen Benutzers, und der Unterschied zwischen diesen beiden Kontexten ist genau das, worum es beim Fehler ging.

Bestätigen Sie dann die Netzwerkoperation, für die der Helfer existiert. Ein Helfer, der startet, aber die Schnittstelle nicht konfigurieren kann, hat das Problem eine Stufe weiter geschoben, nicht gelöst.

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

Notieren Sie die Mount-Optionen und die Eigentümerschaft des Helfers in derselben Notiz. Sonst wiederholt die nächste Person, die das debuggt, die Verschlüsselungstheorie von vorn.