PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : User-based Authentication für NFSv4 via Kerberos



tomiondrums
30.03.10, 23:23
Hi,
ich hab NFS-Clients gebaut, die sich via Kerberos am Server authentifizieren. Dazu benutze ich auf jedem Client eine Keytab-File, wo das Secret für die jeweilige Maschine drinsteht (d.h. ich mache derzeit hostbasierte Authentifizierung, was nicht so prickelnd ist, mit Principals, die so aussehen: nfs/clientname.domain.de)

Gibts eine Möglichkeit mit Kerberos und NFSv4 eine Art Nutzerbasierten Authentifizierung/Authorisierung einzurichten? Ich möchte keine Host-Principal-Secrets mehr auf den Clientmaschinen vorhalten müssen, sondern mich mit den User-Principal-Tickets (nfs/username), die ich beim einloggen ja eh beziehe auch eine Authorisierung beim NFS-Server vornehmen.

Ich mache das Ganze, weil ich NFS (hier im Rahmen eines PC-Pools mit zentralisiertem Login) zum einhängen der Home-Verzeichnisse der Nutzer verwenden möchte. Dabei sind naturgemäß unterschiedliche Nutzer auf einer Workstation unterwegs und ich muß irgendwie verhindern, daß einer des anderen Homeverzeichnis liest oder benutzt. Wenn sich RPC.GSSD nicht so saudumm anstellen würde und nicht jedesmal erst ein Maschinen-Ticket bräuchte um es dann dem NFS-Server vorzulegen, wär das für mich ideal.
Das Szenario sähe dann wie folgt aus:
1. User meldet sich mit Name und Passwort an
2. -> Clientrechner bezieht Ticket vom KDC und Prüft damit, ob Username und Passwort stimmen (soweit funktioniert's auch schon ganz gut)
3. Clientrechner reicht eben empfangenes Ticket an den NFS-Server zur Auth weiter, bzw. weil das wahrsch. nicht geht -> Client bezieht ein Service Ticket für den Nutzer, also nfs/username und legt das dem NFS-Server vor
4. NFS-Server lässt mount von diesem Client auf dessen Homeverzeichnis zu

Geht sowas und wie macht man das?

Vielen Dank schonmal!
Bin für jede Hilfe dankbar!

hessijens
31.03.10, 10:19
Es geht:

Login und Ticket mittels pam_krb5 --> User bekommt Ticket user@REALM

Mount des Homeverzeichnisses mittels pam_mount -- > User erhält Serviceticket nfs/server@REALM (Denkfehler es gibt/braucht kein Ticket nfs/user@REALM). Mögliche Falle: Die Tickets können nicht im Heimatverzeichnis gespeichert werden, werden aber sowieso meistens per default in /tmp gehalten.

Wichtig: Für Server (und Client) bracht man eine Kestab mit dem Tickest nfs/server@REALM bzw. host/server@REALM für den Server und nfs/client@REALM bzw. host/client@REALM für den Client damit sich Client und Server ausweisen können.

tomiondrums
31.03.10, 14:04
Login und Ticket mittels pam_krb5 --> User bekommt Ticket user@REALM

Das hab ich hier schon am Laufen und es klappt wunderbar. Ich hab' mich eben auch gefragt, wieso man nicht dieses Ticket direkt forwarden/etc. könnte... aber egal.



Mount des Homeverzeichnisses mittels pam_mount -- > User erhält Serviceticket nfs/server@REALM (Denkfehler es gibt/braucht kein Ticket nfs/user@REALM). Mögliche Falle: Die Tickets können nicht im Heimatverzeichnis gespeichert werden, werden aber sowieso meistens per default in /tmp gehalten.

pam_mount wollte ich eigentlich als nächstes probieren, nur da hakts ja irgendwie. Seltsamerweise find ich nur Anleitungen zum Einrichten von pam_mount im Zusammenhang mit CIFS, aber nicht für NFS (+Kerberos)...



Wichtig: Für Server (und Client) bracht man eine Kestab [...] und nfs/client@REALM bzw. host/client@REALM [...]

genau das hab ich schon und ich betrachte es als host-based Authentifizierung. Irgendjemand könnte jetzt von einer Live-CD (respektive USB-Stick) starten, die Festplatte mounten (Schreiben auf die Festplatte von einem Fremdsystem aus ließe sich in meiner Umgebung sogar verhindern) und einfach die Keytab mit dem Host-Key klauen.
Diesen Key könnte er dann mit einem fremden System verwenden und hätte logsicherweise dann auch unberechtigt Zugang zu den zu schützenden Daten.

Genau das ist der Grund wieso ich eigentlich eine User-Based-Auth will. Vielleicht hab ich auch bloß was verkehrt verstanden, bitte rückt mich in dem Fall zurecht...:confused:

Vielen Dank schonmal für deine Antwort!
MfG
Tom

hessijens
31.03.10, 18:09
Du must zwischen Usertickets und Servicetickets und Tickets sowie Keys unterscheiden. Ich hoffe ich bekomme das hier richtig zusammen.

Bei der Anmeldung mittels pam_krb5 oder mittels kinit erhält der Benutzer ein Ticket. Dazu wird eine Session beim Kerberos Server angefragt, das Passwort mithilfe der Session verschlüsselt übertragen, geprüft und ein UserTicket mit Schlüssel ausgestellt. (Normalerweise wird alles mit einer Session-ID versehen was ich der Einfachheit halber unterschlage). Als Ergebnis erhält man ein Ticket mit Key für user@REALM.ORG bzw. user/users@REALM.ORG.

Als nächstes mountet der Benutzer einen nfs Mount mit Kerberos. Dazu fragt er beim Ticket Grainting Service TGS des Kerberos eine Serviceticket für den NFSServer an. Der TGS erstellt ein verschlüsseltes Serviceticket ohne Key nfs/nfsserver.org@REALM.ORG für den user@REALM.ORG. Diese ist mittels "klist" dann sichtbar. Mit diesem Serviceticket meldet sich der NFSClient dann beim NFSServer. Das der NFS Server in seiner Keytab den Schlüssel für das nfs/server.org@REALM.ORG Ticket hat kann der Server nun das Ticket entschlüsseln und verifizieren. Der Server kennt nun den Benutzer user@REALM.ORG. Es geht aber weiter, denn als Antwort bekommt der NFSClient nun einen temporären Schlüssel vom NFSServer. Mithilfe diese Schlüssels überprüft der NFSClient nun ob die Antwort auch von server.org gekommen ist.

Die einfache Benutzerauthorisierung "krb5" ist damit zu Ende. Als Erweiterung gibt es nun "krb5i" bzw. "krb5p" wo auch der NFSClient vom NFS Server mittels Serviceticket überprüft wird, die Beschreibung erspare ich mir.

Wie Du siehst steckt in der Keytab nur der Schlüssel zur Überprüfung. Eine gestohlene Keytab ist daher noch nicht besonders tragisch. Viel Schlimmer ist ein gestohlenes Userticket. Der Client legt die Usertickets normalerweise in eine Datei in /tmp ab (z.B. krb_1000_irgendwas). Darin sind sowohl Ticket als auch Schlüssel, wer diese Datei stielt kann sich als der Benutzer des Tickets ausgeben. Wegen der Schreibrechte von /tmp wird oft empfohlen diese temporäre Datei im Homeverzeichnis zu speichern (Geht recht einfach mit einer Option die ich gerade nicht weiß). Wenn Du aber das Homeverzeichnis mit KerberosNFS mounten willst wird das nicht gehen. Ich denke fast dieses Risiko wirst Du eingehen müssen. Immerhin sind die Tickets zeitlich begrenzt und im normalfall nur vom berechtigten Benutzer und Root zu lesen.

tomiondrums
01.04.10, 10:29
Hi hessijens,
das war mir schon zu ca. 85% klar, nur die Sache mit dem temporären Schlüssel vom NFS-Server hat mir bislang noch keiner erklärt. Danke dafür! Ein paar Puzzleteile fehlen jedoch noch immer (man muß wissen, ich warte seit fast einem viertel Jahr völlig verzweifelt auf die bestellte Literatur zum Thema Kerberos und mein Produktivsystem soll in zwei Wochen in Betrieb gehen...):
Die Sache mit dem temporären Schlüssel: Ist das etwas, das NFS dann intern regelt oder ist das, was der NFSClient vom NFSServer bekommt dann auch ein(e Art) Kerberos-Ticket, zu dem dann der Schlüssel von "nfs/client_xyz.domain.name" (aus der Keytab des Clients passt)?

Wie kann ich dem NFS-Server sagen, daß ein Bestimmtes Share ("home_abc") auch nur von jemanden ge-NFS-mountet werden darf, der sich mit einem gültigen NFS-Service-Ticket für den USER "abc" identifizieren kann (ist jetzt etwas unglücklich ausgedrückt, aber ich denke, du verstehst schon was ich damit meine)? (NFS ACLs, oder kann man das vielleicht irgendwie auch in der etc/exports mit angeben, oder noch besser vom LDAP irgendwie beziehen,...?)

hessijens
08.04.10, 16:28
Die Sache mit dem temporären Schlüssel wird eigentlich vom NFS bzw. TGS intern geregelt. Die Kerberos Tickets haben nur eine bestimmte Gültigkeitsdauer, daher ist die exakte Urzeit der Rechner auch so wichtig. Das "nfs/client_xyz.domain.name" Ticket dient nur einer weiteren Überprüfung des Clientrechners durch den NFS-Server und wird nicht immer zwingend benötigt.


Wie kann ich dem NFS-Server sagen, daß ein Bestimmtes Share ("home_abc") auch nur von jemanden ge-NFS-mountet werden darf, der sich mit einem gültigen NFS-Service-Ticket für den USER "abc" identifizieren kann

Das wird so nicht gehen. Jeder, der ein gültiges Ticket für das REALM hat wird den NFS-Share mounten können. Er wird aber die Rechte des Ticketinhabers auf den Mount haben. Die Angabe von Gruppen oder Computern wie beim NIS basierenden NFS geht meines wissens nicht mit dem Kerberos Basierenden Mounts. Was theoretisch geht wären Gruppen user1/user@REALM.ORG user2/admin@REALM.ORG u.s.w., dann kannst Du die Gruppen auf den NFS Mounts entsprechend setzen bzw. auch ACLs verwenden. Nur das Mounten mit einem gültigen Ticket wird sich meines Wissens nicht verhindern lassen.

Ich hoffe meine späte Antwort (Urlaub) hilt Dir noch ein wenig weiter.

microft
05.08.10, 09:12
hallo hessijens

Deine Beiträge hier haben endlich bei mir eine Reihe von Klarheiten beseitigt.

Eine Frage ist allerdings immer noch offen. Im HowTo von Kerberus hab ich gelesen das man auf dem Client einen File hinterlegen muß damit Kerberos mit dem Client überhaupt redet. Dies würde ja bedeuten das nur autorisierte Client-Pcs sich anmelden können, alle anderen nicht, denn den HandtaschenPcs fehlt ja diese "Anmeldung" beim Dienst.

Ist das richtig? Oder hab ich da was mistverstanden.

jürgen