Ihr VPN-Befehl läuft unprivilegiert; der Dienst nicht

Der VPN-Befehl läuft als Ihr Benutzer, es erscheint kein Passwort, und der Tunnel kommt hoch. Diese Abfolge fühlt sich wie eine unprivilegierte Operation an, und meistens ist sie es nicht. Ein getrennter Dienst führt die Netzwerkänderungen aus, und die interessante Frage ist, was dieser Dienst für einen Aufrufer tut, den er nicht überprüft hat. Passwortabfragen zu zählen sagt Ihnen nichts über diese Grenze.

Die Schnittstelle, der Mechanismus und die Prüfung

Die Schnittstelle nimmt Anfragen an: verbinden, trennen, ein Profil wählen. Der Mechanismus besitzt die Netzwerkoperationen: Schnittstellen anlegen, Routen ändern, Filter anwenden. Die Autorisierungsprüfung entscheidet, ob dieser Aufrufer diese Aktion verlangen darf. Diese drei können auf ein Programm, einen Helfer und einen Systemdienst verteilt sein, und der Benutzer sieht nur das erste.

Die Rollen können in einem Programm, in zwei Prozessen oder in einem Client und einem Systemdienst leben, und der Befehl, den der Benutzer sieht, verrät selten, welche. Ein Symbol im Infobereich und ein Systemdienst können wie eine Anwendung aussehen, während sie mit sehr unterschiedlicher Befugnis laufen. Privileg zur Installationszeit und Privileg zur Anfragezeit sind ebenfalls verschiedene Dinge. Ein Installer, der als root lief, kann einen Dienst zurücklassen, der auf spätere Anfragen wartet, lange nachdem der Paketmanager fertig ist. Dieser Dienst, nicht der Befehl, den Sie getippt haben, hält die Befugnis.

Delegation ist der normale Entwurf

Privilegierte Netzwerkarbeit an einen Dienst zu delegieren ist die vernünftige Architektur. Sie hält gewöhnliche Anwendungen unprivilegiert und bündelt die Operationen, die Sorgfalt brauchen. Das Design zahlt sich nur aus, wenn der Dienst auch prüft, wer fragt und wofür. Ohne diese Prüfung ist es nur eine breitere Tür.

NetworkManager ist das konkrete Linux-Beispiel. Seine Konfigurationsanleitung erklärt, wie PolicyKit Anfragen, die nicht von root kommen, in der Standardeinstellung autorisiert. Das zeigt delegierte Autorisierung in einem echten Produkt. Es beweist nicht, dass jeder kommerzielle Client NetworkManager nutzt, und es beschreibt weder den Socket-Pfad noch die Richtlinie eines bestimmten Anbieters.

Das Muster ist Delegation mit einer Richtlinie dahinter. Das Beispiel ist eine Umsetzung dieses Musters, keine allgemeine.

Lesen Sie die Grenze, nicht die Abfrage

Finden Sie den Dienst, den Eigentümer seiner Konfiguration und die lokale Schnittstelle, die die Oberfläche nutzt. Fragen Sie dann, welche Benutzer welche Operationen verlangen dürfen. Ein gespeichertes Profil hoch- und herunterzufahren ist nicht dieselbe Berechtigung wie das Laden einer Konfiguration, die der Betreiber nie geprüft hat. Der Unterschied ist die ganze Sicherheitsfrage.

Beginnen Sie beim Dienstmanager und bei der Sicht des Clients auf seine eigenen Berechtigungen. Die Befehle unten zeigen, ob der Daemon läuft, was der Aufrufer von ihm verlangen darf und was der Daemon unter seinem Laufzeitverzeichnis anbietet.

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

Fragen Sie auch, worauf die Operation wirkt. Ein Menüeintrag, der persönlich aussieht, kann Routen und DNS für die ganze Maschine ändern, was bedeutet, dass er die Sitzungen anderer Benutzer stören kann. Der Wirkungsradius gehört in dieselbe Prüfung wie die Berechtigung, und er entscheidet meist, ob der Dienst eine engere Rolle braucht.

Berechtigungen auf dem unterstützten Weg reparieren

Einen geschützten Steuersocket für alle beschreibbar zu machen oder ein Konto einer breiten administrativen Gruppe hinzuzufügen beseitigt einen Berechtigungsfehler und erzeugt einen größeren. Der Fehler war das Einzige, was Ihnen sagte, dass diese Grenze existiert. Nutzen Sie den dokumentierten Mitgliedschafts- oder Autorisierungsprozess, einschließlich der dafür nötigen Sitzungsaktualisierung. Gruppenmitgliedschaft gilt oft nur für neue Anmeldesitzungen, weshalb eine Änderung bis zur nächsten Anmeldung nichts zu bewirken scheint.

Wenn das Produkt eine engere Rolle für die Operation anbietet, ziehen Sie sie einer pauschalen Erteilung vor. Schreiben Sie die gewählte Rolle und ihren Eigentümer neben den Dienstnamen.

Wie eine gute Trennung aussieht

Gewöhnliche Anwendungen bleiben unprivilegiert, der Dienst führt nur die Einrichtung aus, für die er gebaut wurde, und jeder Aufrufer wird gegen eine Richtlinie geprüft, die jemand besitzt. Das ist ein vertretbares Design. Es ist auch prüfbar, weil die Richtlinie einen Namen daran gebunden hat. Alles Größere verdient eine schriftliche Ausnahme statt einer stillen Berechtigungsänderung.

Der Fehlermodus ist ein Dienst, der jede Anfrage jedes lokalen Benutzers ausführt, weil die Schnittstelle bequem ist. Von der Benutzerseite sieht es identisch aus, und es trägt eine viel größere Befugnis. Testen Sie eine abgelehnte Anfrage, nicht nur die erfolgreiche. Eine Ablehnung, die aus der Richtlinie kommt, ist der Beweis, dass die Richtlinie existiert.