Eine gewöhnliche Linux-App nutzt das VPN, ohne TUN anzufassen

Ein Browser, der ein bereits eingerichtetes Linux-VPN nutzt, öffnet nicht /dev/net/tun. Er öffnet einen Socket, und der Kernel entscheidet, über welche Schnittstelle die Pakete dieses Sockets hinausgehen. Der Prozess, der den Tunnel erstellt hat, verrichtet eine andere Aufgabe als der Prozess, dessen Verkehr er trägt. Diese beiden Rollen getrennt zu halten, beantwortet die meisten Berechtigungsfragen, bevor sie gestellt werden.

Verfolgen Sie ein Paket vom Socket bis zum Tunnel

Eine gewöhnliche Anwendung ruft connect oder send auf, und der Kernel sucht eine Route zum Ziel. Zeigt die gewählte Route auf die Tunnelschnittstelle, wird das Paket an das Gerät eingereiht, das der VPN-Daemon liest. Der Daemon verschlüsselt es und sendet es über die physische Schnittstelle hinaus. Jeder Pfeil in dieser Beschreibung ist eine Stelle, an der eine Berechtigungsfrage beantwortet werden kann.

Nichts auf diesem Weg verlangt, dass die Anwendung das Gerät kennt. Der Daemon hält den Dateideskriptor und führt die Schnittstellenoperationen aus, während die Anwendung nur eine normale Netzwerk-API sieht.

Zeichnen Sie die beiden Hälften einmal, und Berechtigungsfragen lassen sich leichter einordnen. Die obere Hälfte ist die Welt der Anwendungen, die untere gehört dem Daemon.

Entscheiden Sie, wer das Gerät braucht und wer nicht

Das Anlegen einer TUN-Schnittstelle oder das Anhängen an eine erfordert Gerätezugriff plus die Berechtigung, sie zu konfigurieren, weshalb ein unterstützter VPN-Dienst mit Netzwerkverwaltungsrechten startet oder einen privilegierten Helfer nutzt. Diese Anforderung gehört zum Daemon. Sie sagt nichts über den Browser, den Datenbank-Client oder das Dateitransfer-Werkzeug. Ein Dienst, der die Berechtigung braucht, braucht sie für seinen eigenen Einrichtungsschritt, nicht für seine Clients.

Sobald Route und Richtlinie stehen, nutzt ein gewöhnlicher Prozess den entstandenen Weg über seine üblichen Socket-Aufrufe. Er braucht nicht den Geräteknoten und nicht root.

Geräteberechtigungen zu ändern ist kein Weg, einer Anwendung Zielzugriff zu geben. Es verschiebt die Gerätegrenze nur an eine andere Stelle.

Prüfen Sie, in welchem Namensraum die Anwendung tatsächlich läuft

Ein Container oder ein zweiter Netzwerk-Namensraum gibt seinen Prozessen eine eigene Schnittstellenmenge und Routentabelle. Ein Tunnel auf dem Host erscheint dort nicht automatisch, und keine Änderung der Geräteberechtigungen ändert das. Die Anwendung leitet einfach durch das, was dieser Namensraum bietet. Deshalb kann ein Container-Image nicht versehentlich einen Host-Tunnel erben.

Prüfen Sie mit ip netns list und ip -n NAME route oder indem Sie den Namensraum-Link des Prozesses ansehen. Die Antwort ist meist in einem Befehl sichtbar.

Zwei Benutzern auf demselben Host können per Richtlinie auch unterschiedliche Wege gegeben werden. Das ist eine Netzwerkentscheidung und kein Beleg für Geräteeigentum.

Trennen Sie Berechtigungen von der Netzwerkrichtlinie

Manche Werkzeuge brauchen mehr als einen Socket. Das Mitschneiden von Paketen braucht einen Rohsocket, und das Ändern von Routen braucht Verwaltungsrechte. Das sind getrennte Vorgänge mit getrennten Erteilungen, und die Erteilung der einen sollte nicht als pauschale Voraussetzung für die Nutzung des VPN gelesen werden.

Ein Programm, das seinen eigenen Tunnel umsetzt, ist der dritte Fall. Es öffnet tatsächlich TUN, weil es die Rolle des Daemons übernimmt, und deshalb braucht es dessen Privilegien.

Benennen Sie den Vorgang, bevor Sie das Privileg benennen. Beide lassen sich meist leichter trennen, als es aussieht.

Prüfen Sie die Trennung mit zwei Konten

Verbinden Sie den Tunnel als Dienst, führen Sie dann die Anwendung als gewöhnlicher Benutzer aus und bestätigen Sie, dass sie die private Ressource erreicht. Prüfen Sie ip route get für das Ziel aus der Shell dieses Benutzers, um zu sehen, welche Schnittstelle gewählt wurde. Ist die Route richtig und die Verbindung scheitert trotzdem, liegt das Problem in der Richtlinie und nicht im Privileg.

Das Ergebnis ist geringstes Privileg mit einer ausdrücklichen Grenze: eine Komponente besitzt Einrichtung und Tunnelressourcen, Arbeitslasten behalten ihre normalen Konten, und die Netzwerkrichtlinie entscheidet, was passieren darf. Alles als root laufen zu lassen, faltet diese Rollen zusammen, ohne etwas zu erklären.