Sicherer Datenaustausch über NFS mit gssproxy
Entkoppelt
Über die Pflicht zur Kerberos-Implementierung in NFS4 ist das Protokoll sicherer geworden. Der aus dem Fedora-Umfeld stammende Daemon gssproxy rüstet Komfortfunktionen nach und macht moderne Kerberos-Erweiterungen zur Impersonifizierung auch unter Linux salonfähig.
Theoretisch ist NFS ein sicheres Protokoll zum Datenaustausch, denn seit Version 4 muss jede Implementierung starke Authentifizierung, Integritätsprüfung und Verschlüsselung per Kerberos anbieten [1]. In der Praxis relativiert sich die Sicherheit, weil Inkompatibilitäten, Implementierungsschwächen, mitunter aber auch grundlegende Widersprüche den Einsatz von NFS in Verbindung mit Kerberos verhindern. Denn der Kerngedanke ist gleichzeitig das Kernproblem: Nutzer eines Dateisystems müssen sich stark authentifizieren. Das bereitet immer dann Schwierigkeiten, wenn ein System Tätigkeiten ausführen soll, für die gerade kein Nutzer greifbar ist.
Derlei Beispiele existieren viele: Cron-Jobs, Backupsysteme, Web-Gateways mit Dateisystemzugriff oder die Batch-Jobs eines HPC-Clusters müssen ohne unmittelbare Interaktionen eines Nutzers zurechtkommen. Sind solche Programme auf Daten in NFS-Laufwerken angewiesen, legt ihnen Kerberos eine zusätzliche Hürde in den Weg. Denn auch sie benötigen jetzt Tickets für den kerberisierten NFS-Zugriff. Die Gültigkeitsdauer dieser Tickets orientiert sich aber primär an der Dauer interaktiver Nutzersitzungen und liegt daher üblicherweise im Stundenbereich. Verglichen mit der Laufzeit von HPC-Berechnungen oder gar für stetig wiederkehrende Cron-Jobs ist das zu kurz. Tickets ausschließlich interaktiv bereitzustellen, ist daher keine praktikable Option.
Manuelles Ticket-Handling als Hürde
Bei Projekten zur Einführung von Kerberos-Sicherheit in NFS-Umgebungen geht es so stets auch darum, eine Lösung zu finden für den weiteren Betrieb bestehender nicht interaktiver Prozesse, die auf NFS-Mounts zugreifen müssen. Technisch benötigen die Accounts, unter denen diese Prozesse auf den NFS-Clients laufen, dafür jederzeit gültige Tickets.
Interaktive Linux-Nutzer erhalten ihre Kerberos-Tickets entweder direkt beim Login oder explizit über das Kommando kinit. Für nicht interaktive Prozesse sieht Kerberos sogenannte Keytab-Dateien vor. Sie enthalten passwortähnliche kryptografische Informationen, mit denen sich automatisiert Tickets anfordern lassen. Früher nutzten Administratoren das Kommando kinit mit der Option –k oder komfortablere Alternativen wie k5start, um in Skripten über die Keytab-Datei einen Ticket-Cache zu initialisieren und aktuell zu halten. Zeitgemäße Kerberos-Implementierungen können die Keytab direkt verwenden.
Gerade für Serviceaccounts ist das ein übliches Vorgehen, wenn auch mit dem Schönheitsfehler, dass der Account dabei direkten Zugriff auf seine kryptografischen Schlüssel benötigt. Das grundsätzliche Problem beschränkt sich aber nicht auf solche Serviceaccounts. Auch normale Nutzer wollen nicht interaktive Jobs mit NFS-Zugriffen ausführen, und für die sind Keytabs nicht praktikabel.
Mehr Sicherheit und Komfort mit gssproxy
Gänzlich unlösbar sind die durch die Kerberos-Sicherheit entstehenden praktischen Probleme zwar nicht, wohl aber unhandlich und mit viel Zusatzaufwand für Nutzer oder Systemverwalter verbunden. Abhilfe verspricht auf Linux-Systemen gssproxy, ein im Fedora-Umfeld entwickelter Dienst, der zentrale Lösungen für verschiedene typische Anwendungsszenarien bereitstellt und so die Einstiegshürde für sicheres NFS deutlich senkt (siehe ix.de/ix1904112, [2]).
Dabei ist der ursprüngliche Verwendungszweck des gssproxy eigentlich nur ein Bugfix für ein ganz anderes Problem aufseiten des NFS-Servers: Der nämlich kann unter Linux aufgrund eines Implementierungsdetails der Schnittstelle zwischen Kernel und Userland-Prozess rpc.svcgssd Tickets nur bis zu einer maximalen Größe verarbeiten. Speziell in Active-Directory-Umgebungen treten jedoch im Regelbetrieb immer wieder übergroße Tickets auf, die im Zusammenspiel mit NFS-Servern unter Linux Zugriffsfehler verursachen. Auslöser ist das Privilege Attribute Certificate (PAC) – eine optionale Liste von Autorisierungsdaten, die die Domain-Controller in einem bestimmten Ticket-Feld hinterlegen. Für NFS selbst ist das PAC zwar unnötig und lässt sich prinzipiell abstellen; laufen auf demselben Server aber andere Dienste, die auf das PAC angewiesen sind, ist dieser Ausweg verbaut.