Ich habe ein kleines Netzwerk, das ein NAS umfasst, auf dem ich mit einigem Aufwand einen Kerberos-Server bereitgestellt habe. Der Kerberos-Server ermöglicht es Linux-Hosts im Netzwerk, sichere NFS-Mounts zu erstellen. Auf dem KDC erstellte Dienstschlüssel werden an entsprechende Hosts verteilt und Mounts werden mit Kerberos-Sicherheit konfiguriert. Unsichere Mounts werden durch die auf dem NAS konfigurierte Richtlinie blockiert.
Unpraktischerweise können Benutzer nur dann auf Dateien auf den Mounts zugreifen, wenn sie aktive Tickets vom KDC auf dem Host haben. Diese Anforderung ist restriktiv, da sie unpraktisch ist und insbesondere den Zugriff auf die Mounts durch automatisierte Aufgaben, die mit regulären Benutzerberechtigungen ausgeführt werden, einschränkt.
In den Anfangstagen von NFS wurden Dateien auf einem Remote-Volume ab dem Bootvorgang und während der gesamten Systemsitzung als lokal angezeigt. Sicherheit und Identitätsmanagement sind wichtige Vorteile von Kerberos in NFS, aber es ist oft unnötig, Benutzern Tickets zuzuweisen. Da die Schlüsselverteilung und der kontrollierte Zugriff auf die Hosts unerwünschten Zugriff auf die NFS-Mounts verhindern, brauche ich keine Benutzertickets.
Im Idealfall möchte ich, dass Benutzer auf Mounts mit Kerberos-Sicherheit zugreifen können, ohne ein Ticket vom KDC anzufordern oder einen darauf registrierten Principal zu benötigen. Jeder Benutzer hätte jederzeit Zugriff auf jede Datei, vorausgesetzt, der Zugriff wäre nicht durch Dateiberechtigungen eingeschränkt.
Wie nahe können wir diesem Zielszenario mit den vorhandenen Werkzeugen kommen?
Antwort1
Die kurze Antwort ist, dass der aktuelle NFS Kerberos-Authentifizierungsmechanismus (RPCSEC_GSS) dies nicht unterstützt. Der Principal, der den Anruf tätigt, ist derjenige, der Zugriff erhält. Wenn Sie also nicht möchten, dass BenutzermanuellTickets erhalten, dann müssen Sie den Host automatisch Tickets erhalten lassenfürihnen.
In der Zukunft könnte das neuere RPCSEC_GSSv3-Protokoll Optionen enthalten, die es Hosts ermöglichen, sich als beliebige Benutzer auszugeben. Dieses Verfahren ist jedoch noch nicht fertiggestellt oder implementiert.
Wenn Sie Hosts erlauben möchten, jede UID zu imitieren, benötigen Sie Kerberos überhaupt nicht – wechseln Sie zurück zum sec=sys
Sicherheitsmodus, der „früher“ verwendet wurde. In diesem Modus kann der Host buchstäblich eine symbolische Kennung des Benutzers angeben. (Berechtigungsprüfungen finden natürlich weiterhin statt.)
Letztendlich besteht kein funktionaler Unterschied zwischen dem Zulassen, dass ein Host jeden beliebigen Benutzer über Kerberos imitiert (Authentifizierung mithilfe der Datei /etc/krb5.keytab des Hosts) und dem Zulassen, dass ein Host jeden beliebigen Benutzer über einen einfachen UID-Anspruch imitiert (Authentifizierung mithilfe des privaten IPsec- oder WireGuard-Schlüssels des Hosts oder) – und Letzteres bietet eine viel höhere Leistung als GSSAPI erreichen kann.
Wenn Sie innerhalb von Kerberos nur vorhandene Tools verwenden (ohne direkt eine Art Host-Level-Authentifizierung für RPC zu implementieren), ist das, was dem am nächsten kommt,eingeschränkte Delegation mit Protokollübergang(S4U2Self + S4U2Proxy), wobei ein Dienst im Namen eines Benutzers Tickets für bestimmte andere Dienste abrufen darf. Es wird häufig in Active Directory-Umgebungen verwendet, wird aber auch von MIT Kerberos KDCs unterstützt (undwahrscheinlichHeimdal KDCs – der Code ist dank Samba da, aber ich weiß nicht, wie ich ihn auf Heimdal aktivieren kann).
Um dies in einem MIT Kerberos KDC zu aktivieren, müssen Sie das LDAP-Backend verwenden; das dateibasierte HDB-Backend unterstützt das Speichern der zusätzlichen Felder nicht.
Setzen Sie das Principal-Flag auf dem Host-Principal des Clients (kann über kadmin oder durch OR-Verknüpfung mit dem LDAP-Attribut
ok_to_auth_as_delegate
erfolgen ).0x200000
krbTicketFlags
kadmin.local modprinc +ok_to_auth_as_delegate host/foo.example.com
Legen Sie das LDAP-Attribut des Client-Principals
krbAllowedToDelegateTo
auf eine Liste von NFS-Dienstprincipals fest, für die es gefälschte Tickets erstellen kann. (Ein Dienst pro Wert.)ldapmodify <<EOF dn: krbPrincipalName=host/[email protected],cn=EXAMPLE.COM,ou=Kerberos,o=Example add: krbAllowedToDelegateTo krbAllowedToDelegateTo: nfs/fs1.example.com - EOF
Testen Sie als Root, ob die S4U-Funktionen funktionieren:
# Acquire host credentials using system keytab host_cc=FILE:/tmp/krb5cc_host kinit -c $host_cc -k klist -c $host_cc # Acquire NFS tickets on behalf of the user using S4U2Proxy kvno -c $host_cc -I $user_name -P nfs/fs1.example.com klist -c $host_cc # Do the same, but put the tickets in that user's cache # so that rpc.gssd would be able to find them user_cc=FILE:/tmp/krb5cc_$(id -u $user) kvno -c $host_cc -I $user -P nfs/fs1.example.com --out-cache $user_cc chown $user: $user_cc
Installierengss-proxyauf dem Client und bearbeiten Sie den Inhalt,
nfs-client.conf
um S4U2Proxy anstelle einzelner Client-Keytabs zu verwenden:[service/nfs-client] mechs = krb5 cred_store = keytab:/etc/krb5.keytab cred_store = ccache:FILE:/var/lib/gssproxy/clients/krb5cc_%U impersonate = yes allow_any_uid = yes trusted = yes euid = 0
Dieses Beispiel basiert aufhttps://github.com/gssapi/gssproxy/blob/main/docs/NFS.md#user-impersonation-via-constrained-delegation.
Konfigurieren Sie den Clientrpc.gssdDaemon zur Verwendung von GSS-Proxy, indem Sie
GSS_USE_PROXY=1
der Umgebung Folgendes hinzufügen:# systemctl edit rpc-gssd [Service] Environment=GSS_USE_PROXY=1 # systemctl restart rpc-gssd
Wenn Kerberos ausschließlich für NFS verwendet wird und jeder Host nur eine begrenzte Anzahl von Benutzern benötigt, kann der HostClient-Keytabs(die die aus dem Passwort abgeleiteten Schlüssel enthalten) für diese Benutzer. Dies entspricht in etwa dem Speichern der Passwörter der Benutzer, da die Keytab