====== 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
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 =====
* Von http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html
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.
----
* http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html
**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.
----
* http://www.diablotin.com/librairie/networking/puis/ch19_06.htm
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
----
* http://web.mit.edu/Kerberos/krb5-current/doc/user/tkt_mgmt.html
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.