Inhaltsverzeichnis
Umgang mit Kerberos
Kerberos-Ticket
Wenn man sich einloggt, bekommt man automatisch ein Kerberos-Ticket. Mit dem Befehl klist erhält man eine Liste der aktuellen Tickets:
$ klist Ticket cache: FILE:/tmp/krb5cc_53541_om4344 Default principal: wyneken2@PUBLIC.ADS.UNI-FREIBURG.DE Valid starting Expires Service principal 01/30/13 15:57:29 01/31/13 15:57:29 krbtgt/PUBLIC.ADS.UNI-FREIBURG.DE@PUBLIC.ADS.UNI-FREIBURG.DE renew until 01/31/13 15:57:29 01/30/13 15:57:29 01/31/13 01:57:29 nfs/sunfs4.public.ads.uni-freiburg.de@PUBLIC.ADS.UNI-FREIBURG.DE renew until 01/31/13 15:57:29
Lebensdauer der Tickets
Die Default-Lebensdauer der Tickets werden in /etc/krb5.conf definiert. Die Angaben im Abschnitt [pam] gelten für das Einloggen direkt an der Konsole. [Und auch über ssh?] Die Werte im Abschnitt [libdefaults] gilt für alles andere.
Wenn ein Ticket ausläuft, kann man auf das Homeverzeichnis nicht mehr zugreifen. In diesem Fall kann man sich mit mit dem Befehl kinit ein neues Ticket holen. Bei kinit ist eine Passworteingabe erforderlich.
Mit der Option -l kann man eine andere Lebensdauer angeben, z.B.:
kinit -l 30d kinit -l 25h
Vgl. man kinit für weitere Details.
Tickets automatisch erneuern für einen längeren Job
Wenn man einen Job hat, der länger geht als der aktuelle Ticket es erlaubt, setzt man den Befehl krenew ein.
Zunächst richtet man eine neue Datei ein, in der man den Ticket speichert:
export KRB5CCNAME=/tmp/mykerbcred
Der Dateiname in /tmp kann natürlich auch anders sein.
Dann kinit aufrufen:
kinit -r28day
Das generiert einen Ticket, der 28 Tage lang gültig ist.
Schließlich starte man den Job mit krenew:
krenew -k /tmp/mykerbcred -t <jobname>
Mehr Details mit man krenew.
"Stolen Tickets" und Ticket-Verlängerung
Die Tickets werden in einer Datei im Verzeichnis /tmp gehalten, wie man bei der Ausgabe von klist sieht. Wenn ein Fremder die Ticketdatei kopieren kann, kann er das Ticket für dessen Lebensdauer benutzen. Aus diesem Grund sollte man die Lebensdauer eines Tickets nicht zu lange definieren. Allerdings kann im Prinzip nur root die Ticketdatei kopieren.
Es ist möglich, sich ein erneuerbares Ticket erstellen zu lassen:
kinit -r 30d
Mit diesem Befehl holt man sich ein Ticket, das 30 Tage lang mit dem Befehl klist -R - ohne Passworteingabe - immer wieder erneuert werden kann. Somit ist die Gefahr bei einem gestohlenen Ticket zeitlich begrenzt, aber man hat die Möglichkeit, die Lebensdauer ohne Passworteingabe zu verlängern. Mit folgendem Script als cron-Job kann man die Verlängerung automatisieren:
#!/bin/sh
PATH=/usr/bin
export PATH
curr_principal=`klist 2>/dev/null|egrep "Default principal" |awk '{print $3}'`
if [ "x$curr_principal" != "x" ]
then
kinit -R
fi
Tickets löschen
Mit dem Befehl kdestroy löscht man alle Tickets.
Die Tickets werden aber noch eine Weile gecachet, und man kann noch eine bis 1 1/2 Stunde auf das Homeverzeichnis zugreifen.
Es heißt, dass man eigentlich beim Ausloggen etwa in .logout den Befehl kdestroy ausführen sollte, damit alte Tickets nicht geklaut werden können. Allerdings scheint es so zu sein, dass die Tickets beim Ausloggen automatisch gelöscht werden.
Kerberos und Condor
Das ist ein potentielles Problem, aber es heißt, man kann Condor so einrichten, dass es in einer Kerberos-Umgebung gut funktioniert. Momentan ist das also „work in progress“.
Infos und Links zu Schwachstellen von Kerberos
One practical problem with Kerberos is that the tickets eventually expire. A practical balance has to be made between the desire to reduce the usefulness of stolen tickets (short lifetime) versus the ease-of-use for the user (long lifetime). This problem becomes a much larger issue when dealing with long-running user processes. Jobs run on some supercomputer systems can run for days or weeks, but having tickets that last that long can be a security nightmare. The compromise for this problem that was introduced in Kerberos 5 is the support for renewable tickets. Renewable tickets have expiration times, like normal tickets. However, they also have a maximum renewable lifetime. A renewable ticket can be renewed by asking the KDC for a new ticket with an extended lifetime. However, the ticket itself has to be valid (in other words, you cannot renew a ticket that has expired; you have to renew it before it expires). A renewable ticket can be renewed up until the maximum renewable ticket lifetime.
Subject: 1.18. Are there any known weaknesses in Kerberos?
Kerberos makes no provisions for host security; it assumes that it is running on trusted hosts with an untrusted network. If your host security is compromised, then Kerberos is compromised as well. However, the degree to which Kerberos is compromised depends on the host that is compromised. If an attacker breaks into a multi-user machine and steals all of the tickets stored on that machine, he can impersonate the users who have tickets stored on that machine …. but only until those tickets expire. Kerberos uses a principal's password (encryption key) as the fundamental proof of identity. If a user's Kerberos password is stolen by an attacker, then the attacker can impersonate that user with impunity. Since the KDC holds all of the passwords for all of the principals in a realm, if host security on the KDC is compromised, then the entire realm is compromised. In Kerberos 4, authenticators are valid for 5 minutes. If an attacker sniffs the network for authenticators, they have a 5 minute window in which they can re-use it and gain access to the same service you used. Kerberos 5 introduced a replay cache which prevents any authenticator from being used more than once. Since anybody can request a TGT for any user, and that ticket is encrypted with the user's secret key (password), it is simple to perform a offline attack on this ticket by trying to decrypt it with different passwords. Kerberos 5 introduced preauthentication to solve this problem.
Kerberos doesn't work well in a time-sharing environment. Kerberos is designed for an environment in which there is one user per workstation. Because of the difficulty of sharing data between different processes running on the same UNIX computer, Kerberos keeps tickets in the /tmp directory. If a user is sharing the computer with several other people, it is possible that the user's tickets can be stolen, that is, copied by an attacker. Stolen tickets can then be used to obtain fraudulent service
Your Kerberos tickets are proof that you are indeed yourself, and tickets could be stolen if someone gains access to a computer where they are stored. If this happens, the person who has them can masquerade as you until they expire. For this reason, you should destroy your Kerberos tickets when you are away from your computer.
