Kerberos a PAM

Kerberos je protokol zaisťujúci autentifikáciu v nezabezpečenej sieti. Je určený pre model klient-server: klient si overí identitu servera a server si overí identitu klienta. Je založený na symetrickej kryptografii a vyžaduje tretiu osobu, ktorej musia dôverovať obaja učastníci spojenia (klient aj server). Kerberos zabraňuje odpočúvaniu spojenia, "replay" útoku (odchytenie a retransmisia údajov útočníkom) a zabezpečuje integritu dát. Za určitých okolností je náchylný na DoS útoky.

V UNIXovom svete sa v súčasnosti bežne vyskytujú 2 implementácie Kerbera -- MIT Kerberos a Heimdal. Vlastnú implementáciu má aj Microsoft. Formálna špecifikácia Kerbera 5 je popísaná v RFC1510 z roku 1993 a najnovsie v RFC4120 z roku 2005.

Kerberos vznikol na MIT ako súčasť projektu Athena. Tento projekt vznikol v roku 1983 a jeho cieľom bolo vytvoriť pre užívateľov jednotné pracovné prostredie nezávislé na použitom hardware a ktoré by bolo maximálne škálovateľné (až 10 000 pracovných staníc).

Verzia 1, 2 a 3 bola určená pre internú potrebu MIT. Od verzie 4 je Kerberos verejne dostupný pod licenciou podobnou BSD, ale vláda USA zakázala jeho distribúciu do zahraničia, pretože obsahoval implementáciu kryptografického algoritmu DES.

Preto vznikla v Kráľovskom technologickom inžtitúte (Kungliga Tekniska Högskolan) v Stockholme alternatívna implementácia Kerbera 4 - KTH-KRB. Je založená na osekanej verzii MIT Kerbera, ktorá neobsahuje kryptografické funkcie.

Heimdal, implementácia Kerbera 5, bola vydaná prakticky tou istou skupinou ľudí ako KTH-KRB.

Kerberos funguje na princípe prideľovania tzv. lístkov (tickets), pomocou ktorých sa preukazuje identita užívateľov. V sieti existuje tzv. Centrum distribúcie kľúčov (Key Distribution Center, KDC), ktoré sa skladá z dvoch logických častí:

• Autentizačný server (Authentication Server, AS)
• Lístkový server (Ticket Granting Server, TGS)

Kerberos si udržuje databázu tajných kľúčov. Každý klient alebo server v sieti zdieľa s Kerberom tajnú informáciu - kľúč. Na základe znalosti tohto kľúča sa preukazuje totožnosť užívateľov. Ak chce klient komunikovať so serverom, Kerberos vygeneruje jednorázový 'session key', ktorý sa použije na zabezpečenie spojenia medzi klientom a serverom.

Podrobnejší popis procesu autentizácie:

1. Užívateľ zadá do systému svoj login a heslo.
2. Počítač (klient) vypočíta hash hesla užívateľa. Tento hash sa stane tajným kľúčom užívateľa.
3. Klient pošle Autentizačnému serveru (AS) "žiadosť o službu" (service request). Žiadosť není šifrovaná a obsahuje login užívateľa, neobsahuje jeho heslo ani tajný kľúč.
4. AS sa pozrie, či má daného užívateľa v databáze. Ak áno, odošle klientovi:
   • "Client/TGS session key" zašifrovaný tajným kľúčom užívateľa.
   • "Ticket-granting ticket" (TGT) zašifrovaný tajným kľúčom TGS. Tento lístok obsahuje:
     • ID klienta
     • sieťovú adresu klienta
     • časovú platnosť lístka
     • "Client/TGS session key"
     • ...
5. Klient dešifruje "Client/TGS session key". Tento kľúč použije na ďalšiu komunikáciu s TGS.
6. Klient požiada TGS server o lístok. Pošle mu 2 správy:
   • "Ticket-granting ticket" a ID požadovanej služby.
   • Autentifikátor zložený z ID klienta a času (timestamp). Je zašifrovaný kľúčom "Client/TGS session key".
7. TGS dešifruje autentifikátor pomocou "client/TGS session key", ktorý dostal v TGT a pošle klientovi:
   • "Client-server ticket" zašifrovaný kľúčom požadovanej služby (kľúčom serveru). Obsahuje:
     • ID klienta
     • sieťovú adresu klienta
     • čas platnosti
     • "Client-server session key"
   • "Client-server session key" zašifrovaný kľúčom "Client/TGS session key".
8. Teraz sa vie klient autentizovať serveru:
   • Pošle "Client-server ticket" zašifrovaný tajným kľúčom serveru.
   • Nový autentifikátor, zašifrovaný pomocou kľúča "Client-server session key". Správa obsahuje :
     • ID klienta
     • timestamp
9. Server dešifruje tiket svojím tajným kľúčom a pošle klientovi správu, ktorou potvrdí svoju identitu. Táto správa obsahuje timestamp, ktorý poslal klient, zväčšený o 1 a je zašifrovaná kľúčom "Client/server session key".
10. Klient dešifruje potvrdenie kľúčom "klient/server session key" a overí, či je timestamp správny. Ak áno, klient môže serveru dôverovať a využívať jeho služby.

TGT a pridelené lístky expirujú v definovanom čase, takže klient musí občas žiadať o obnovenie lístka (ticket renewal). Pomocou TGT lístka klient získava lístky na konkrétne služby od konkrétnych serverov. Prideľovanie týchto dalších lístkov je z hľadiska užívateľa transparentné a nevyžaduje od neho žiadnu dodatočnú interakciu.

V ďalšom texte sú popísané vlastnosti a konfigurácia Heimdalu.

Heimdal používa GNU autoconf, takže je prítomná obligátna trojica ./configure && make && make install. Skript configure akceptuje rôzne prepínače, ktoré ovplivňujú funkcionalitu Heimdalu (dá sa zapnúť napr. podpora IPv6, LDAP, openssl). Všetky prepínače sú popísané v manuáli alebo po zadaní ./configure --help. Alternatívne môzete samozrejme využiť balíčkovací systém vašej obľúbenej distribúcie.

• /etc/krb5.conf
  Konfigurácia Kerbera 5. Tento súbor nemusí byť v /etc, ak je nastavená premenná prostredia KRB5_CONFIG, tento súbor sa hľadá v adresári uvedenom v tejto premennej.
• /var/heimdal/kdc.conf
  Konfigurácia KDC. Tento súbor má rovnakú syntax ako krb5.conf(5) a je načítaný skôr, takže nastavenie uvedené v ňom má vyššiu prioritu.

Kerberos pracuje s administratívnou doménou zvanou realm. Realm obsahuje údaje o tzv. principáloch, čo sú vlastne užívatelia (klienti) a servery, ktorí sa budú chcieť navzájom autentizovať. Údaje o principáloch sú uložené v databáze. Každý užívateľ Kerbera musí mať v databáze svoj záznam a tieto záznamy sú asociované s konkrétnym realmom. Realmov môže byť viac a sú definované v konfiguračnom súbore.

Príklad jednoduchého konfiguračného súboru:

 $ cat /etc/krb5.conf
[libdefaults]
default_realm = LAB.FI.MUNI.CZ
ticket_lifetime = 600            
clockskew = 60
default_etypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_etypes_des = des3-hmac-sha1 des-cbc-crc des-cbc-md5

[appdefaults]
dns_lookup_kdc = false
dns_lookup_realm = false

[realms]
LAB.FI.MUNI.CZ = {
kdc = speo_beta.lab.fi.muni.cz:88
admin_server = speo_beta.lab.fi.muni.cz:749
}

[domain_realm]
.lab.fi.muni.cz = LAB.FI.MUNI.CZ
lab.fi.muni.cz  = LAB.FI.MUNI.CZ

[logging]
kdc = SYSLOG
admin_server = SYSLOG
default = SYSLOG 

Ďalšie možné sekcie sú [kdc] a [kadmin], ktoré definujú nastavenie KDC a administratívneho servera.

Názvy realmov sa podľa konvencie píšu veľkými písmenami a mali by sa zhodovať s doménovým názvom, ak neexistuje pádny dôvod prečo by tomu malo byť inak.

Ak sa zhoduje názov realmu s doménovým názvom, v ktorom máme Kerbera, nemusíme uvádzať sekcie [libdefaults] a [domain_realm]. Ak máme v DNS SRV záznam pre náš realm alebo CNAME záznam v tvare kerberos.my.realm, môžeme vynechať aj sekciu [realm]. Toto chovanie tiež ovplivňujú parametre dns_lookup_kdc a dns_lookup_realm. Viac informacií o konfigurácii DNS je v manuáli Kerbera.

Teraz môžeme vytvoriť databázu, ktorá skladuje údaje o principáloch. Implicitne je databáza uložená vo /var/heimdal, ale v konfiguračnom súbore sa dá cesta predefinovať.

Príkazom kstash sa vygeneruje nový master-key, ktorým bude šifrovaná databáza. Heslo sa zároveň uloží do /var/heimdal/m-key. Práve tento súbor by sme mali zálohovať, pretože bez neho je nám databáza k ničomu.

$ mkdir /var/heimdal
$ kstash
Master key:
Verifying password - Master key: 

Pustíme program kadmin na lokálnu databázu (prepínač -l) a inicializujeme náš realm príkazom init. Nového principála pridáme príkazom add. Ak chceme spravovať iný realm ako defaultný, môžme použiť prepínač -r REALM.

$ kadmin -l
kadmin> init LAB.FI.MUNI.CZ
Realm max ticket life [unlimited]:
Realm max renewable ticket life [unlimited]:
kadmin> add janko_mrkvicka
Max ticket life [1 day]:
Max renewable life [1 week]:
Principal expiration time [never]:
Password expiration time [never]:
Attributes []:
janko_mrkvicka@LAB.FI.MUNI.CZ's Password:
Verifying - janko_mrkvicka@LAB.FI.MUNI.CZ's Password: 

Ďalšie príkazy:

• help
• delete - zmaže principála z databázy.
• get - vypíše záznamy vyhovujúce zadanému výrazu
• modify - zmena atribútov daného principála, napr. max. doba platnosti lístkov, expirácia účtu a pod.
• list - vypíše zoznam principálov v databáze podľa zadanej masky.

Ak máme databázu vytvorenú, môžeme spustiť démonov kdc a kadmind a skúsiť požiadať o TGT:

$ kinit janko_mrkvicka
janko_mrkvicka@LAB.FI.MUNI.CZ's Password:
$ klist
Credentials cache: FILE:/tmp/krb5cc_0
     Principal: janko_mrkvicka@LAB.FI.MUNI.CZ

  Issued           Expires          Principal
Mar 10 09:21:21  Mar 10 09:31:21  krbtgt/LAB.FI.MUNI.CZ@LAB.FI.MUNI.CZ 

Ak chceme na serveri používať autentizáciu pomocou Kerbera, musíme ho správne nastaviť. K tomu potrebujeme dostať na server konfiguračný súbor /etc/krb5.conf a súbor /etc/krb5.keytab. krb5.keytab obsahuje názov principála (názov servera v databáze Kerbera) a svoj tajný kľúč. Kľúč je tajná informácia, takže tento súbor by mal mať reštriktívne prístupové práva.

 kadmin> add --random-key host/my.host.name
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin> ext host/my.host.name
kadmin> exit 

Príkaz ext bez parametrov extrahuje keytab do súboru /etc/krb5.keytab. Pomocou parametru je možné špecifikovať iný cieľový súbor.

Stačí na klienta skopírovať súbor /etc/krb5.conf a možeme používať kerberizované programy (kinit, klist...)

Niekedy je vhodné mať záložné (slave) servery s bežiacim serverom v prípade, že hlavný server prestane fungovať. Je preto žiadúce, aby všetky servery mali rovnakú databázu, čo dosiahneme pomocou replikácie. Na replikáciu databázy slúžia programy hprop a hpropd. hpropd je spúšťaný na slave serveroch zvyčajne démonom inetd. Aby replikácia fungovala, musi byť v databáze na každom slave serveri principál hprop. Existuje tiež inkrementálna replikácia, keď sa na slave servery posielajú len zmeny. Popis nastavenia replikácie je v manuáli.

Čo sa stane, ak klient potrebuje komunikovať so serverom z iného realmu? Lokálny KDC nemá prístup ku kľúčom cudzieho realmu, takže nemôze bezpečne vygenerovať "Client-server session key".

Tento problém sa rieši tak, že klient si od svojho lokálneho KDC vypýta TGT platné v cudzom realme. Lokálne KDC sa spojí s cudzím KDC a získa TGT, ktore pošle klientovi. Klient následne môže požadovať od cudzieho KDC lístky k serverom v cudzom realme. Aby tento mechanizmus fungoval, zúčastnené realmy si musia doverovat. Je možná jednosmerná alebo obojsmerná dovera.

Presný postup konfigurácie je uvedený v manuáli, v podstate spočíva v pridaní špeciálnych pomenovaných principálov do oboch realmov.

• kadmin(8) - administrácia databázy
• kinit(1) - získanie TGT
• klogin(1) - overí totožnosť užívateľa a spustí novú session.
• klist(1) - vypíše aktuálne pridelené lístky.
• kpasswd(1) - zmena hesla
• kdestroy(1) - odstráni pridelené lístky
• ktutil(1) - správa keytabov
• ksu - kerberizovaný su
• hprop(8), hpropd(8) - replikácia databázy

Protokoly, ktoré používajú MIT Kerberos a Heimdal, sú kompatibilné a obe implementacie vedia spolu pekne spolupracovať. Toto však neplatí o protokole, ktorý používa utilitka kadmin. Tento protokol nie je štandardizovaný a obe implementácie majú svoj vlastný kadmin. Teda ak chceme používať obe implementácie zároveň, nesmieme zabudnúť, že s Heimdalom nefunguje kadmin z MIT Kerbera a naopak.

Menšie rozdiely medzi MIT Kerberom a Heimdalom su tiež v API a su popísané v manuáli Heimdalu v kapitole 9.4.

• MIT Kerberos: http://web.mit.edu/kerberos/www/
• Heimdal: http://www.pdc.kth.se/heimdal/
• RFC1510: http://www.ietf.org/rfc/rfc1510.txt
• RFC4120: http://www.ietf.org/rfc/rfc4120.txt

PAM je sada knižníc, ktorá integruje viaceré nízko-úrovňové autentifikačné mechanizmy do jedného API. Použitie stabilného API rozhrania umožňuje oddeliť detaily a spôsob autentizácie od logiky konkrétneho programu. PAM bolo vyvinuté v Sun Microsystems a podporovaný je napr. v systémoch AIX, HP-UX, Solaris, Linux, FreeBSD, MacOS X a NetBSD. PAM je súčasťou štandardu XSSO (X-Open Single Sign-On Service).

PAM sa skladá z knižnice libpam, oproti ktorej sú linkované aplikácie, ktore PAM využívajú, a z rôznych modulov, ktoré poskytujú konkrétne autentizačné funkcie. Moduly sa zvyčajne nachádzajú v /lib/security (Solaris a niektoré UNIXy /usr/lib/security) a sú do pamäti zavádzané dynamicky, Z toho vyplýva, že operačný systém musí podporovať dynamické linkovanie knižníc.

Konfigurácia PAMu je uložená v súbore /etc/pam.conf alebo vo viacerých súboroch v adresári /etc/pam.d. Ak tento adresár existuje, súbor pam.conf sa ignoruje.

Konfiguračný súbor /etc/pam.conf obsahuje riadky vo formáte:

 [service]  [type]  [control]  [module-path]  [module-args]

Syntax súborov v /etc/pam.d/ je rovnaká, až na pole [service]. Toto pole sa neuvádza a namiesto neho sa použije názov konfiguračného súboru.

Každý riadok predstavuje pravidlo, ktoré sa uplatní pri autentizáii v danom programe, pričom pravidlá sa môžu reťaziť. Tým sa môžu kombinovať rôzne autentizačné mechanizmy, ako napriklad zadanie hesla na klávesnicu + snímanie odtlačku prstov a pod.

Polia v konfiguračnom súbore majú nasledovný význam:

[service]
Väčšinou je to názov aplikácie, ktora využíva služby PAMu. Napr. su, login. Existuje tiež kľúčové slovo 'other', ktore nastavuje implicitnú konfiguráciu, ktorá sa použije, keď danému programu nevyhovie žiadna iná konfigurácia (teda neexistuje konfigurácia, kde [service] == "nazov_programu").

[type]
Jedno z kľúčových slov 'account', 'auth', 'password' a 'session'.

• account -- ako overiť existenciu a platnosť užívateľského účtu, práva k danej službe a pod.
• auth -- ako overiť identitu užívateľa.
• password -- zmeny autentizačných mechanizmov (napr. zmeniť heslo a overiť, či je dostatočne silné a pod.)
• session -- definuje, čo sa má stať pred udelením oprávnenia a po jeho odobratí. Napr. pripojenie domovského adresára užívateľa, auditing a pod.

[control]
Može byť jedno z nasledujúcich:

• requisite - zlyhanie modulu spôsobí okamžité ukončenie autentizačného procesu.
• required - zlyhanie modulu spôsobí zlyhanie autentizácie, ale až po skončení ostatných zreťazených modulov.
• sufficient - úspech tohoto modulu postačuje na úspešnú autentizáciu (pokiaľ predtým nezlyhal modul s 'required')
• optional - úspech alebo zlyhanie tohoto modulu sa berie do úvahy iba vtedy, ak je to jediný modul daného typu asociovaného s touto službou.
• include - nová direktíva, spôsobí vloženie pravidiel zo súboru špecifikovaného v [module-path].

Je možné tiež presne špecifikovať, aká akcia sa má vykonať v závislosti na návratovom kóde modulu. Viac v pam(8).

[module-path]
Absolútna alebo relatívna cesta k modulu. Relatívna cesta je relatívna vzhľadom k /lib/security.

[module-arguments]
Argumenty modulu oddelené medzerou. Dokumentované sú pre každý modul zvlášť.

Príklad konfiguračného súboru:

$ cat /etc/pam.d/login
#%PAM-1.0

auth       required     pam_securetty.so
auth       required     pam_stack.so service=system-auth
auth       required     pam_nologin.so

account    required     pam_stack.so service=system-auth

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth

$ cat /etc/pam.d/system-auth
#%PAM-1.0

auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth nullok
auth       required     pam_deny.so

account    required     pam_unix.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password   sufficient   pam_unix.so nullok md5 shadow use_authtok
password   required     pam_deny.so

session    required     pam_limits.so
session    required     pam_unix.so 

• pam_krb5.so -- autentizácia Kerberom.
• pam_time.so -- kontrola prístupu podľa času.
• pam_stack.so -- načítanie konfigurácie zo súboru uvedeného ako argument.
• pam_securetty.so -- kontrola terminálu podľa /etc/securetty.
• pam_nologin.so -- kontrola existencie /etc/nologin.
• pam_unix.so -- štandartný unixový autentizačný modul.
• pam_limits.so -- nastavenie kvót.
• pam_deny.so -- autentizácia vždy zlyhá.
• pam_warn.so -- logovanie.

Na záver malá poznámočka: ak si zmažeme konfiguráciu PAMu, vymkneme sa tým zo svojho vlastného systému. Jeden zo spôsobov, ako sa z toho dostať, je nabootovať v single-user režime a napísať si nový konfiguračný súbor.

• Linux-PAM: http://www.kernel.org/pub/linux/libs/pam/