Kerberos, PAM

Pavel Radkovič, 98710@mail.muni.cz

Obsah

• Kerberos
• PAM

Kerberos

Úvod

Kerberos je autentizační a autorizační systém, který má zaručit bezpečné využívání síťových zdrojů.
Hlavní myšlenka spočívá v tom, že se předpokládá, že celá síť je nedůvěryhodná. Kerberos pak definuje "jeden" velmi zabezpečený počítač, který zajišťuje autentizační a autorizační služby a je důvěryhodný pro celou síť. Tento počítač obsahuje informace o heslech a přístupových právech pro každého uživatele sítě.
Jestliže chce uživatel využívat nejaké síťové služby nebo prostředku, nejprve se musí autentizovat u tohoto důvěryhodného počítače. Ten mu vydá jakýsi lístek, který ho opravňuje využívat jemu dostupné služby nebo zdroje.

Verze

Systém Kerberos byl původně vyvinutý v počítačových laboratořích MIT (Massachusetts Institute of Technology) v rámci projektu Athena, na kterém práce probíhaly v letech 1983 až 1991.
První veřejná verze byla uvolněna v roce 1987 pod názvem Kerberos v4. Než se odstranily první nedostatky, systém prošel zhruba šestiletým vývojem. Poté byla vydána současná verze Kerberos v5.
Původní Kerberos (z laboratoří MIT) měl bohužel dveře na cestě do Evropy zavřené, protože platily přísné pravidla omezeného exportu šifrovacích algoritmů ze Spojených států. Proto vzniká evropský, volně šiřitelný klon s názvem Heimdal.
I když má Heimdal jiný kód, podporuje API MIT Kerbera. Proto vám programy, které zkompilujete pro verzi MIT budou fungovat pro Heimdal. Nekompatibilní je část týkající se správy KDC
Kerberos Heimdal si můžete stáhnout zde http://www.pdc.kth.se/heimdal/ a Kerberos MIT zde http://web.mit.edu/kerberos/www/dist/index.html

Autentizační proces

V systému Kerberos tedy neprobíhá autentizace přímo, ale využívá se jakési třetí důvěryhodné strany (KDC, Key Distribution Center).
KDC je rozdělen na dva podsystémy.

• Autentifikační server - AS (authentication server)
• Server poskytující lístky - TGS (ticket-granting server)

• 1) Klientský proces (nazývaný jako přihlašovací klient) požádá uživatele o jeho identifikační údaj (uživatelské jméno). Tento údaj pak vyšle klient k AS čistě v textové podobě. Tím žádá AS, aby mu vydala lístek.
  
  
• 2) AS přijme tento údaj a začne prohledávat databázi Kerbera. K uživatelskému jménu nalezne heslo, ze kterého vyheneruje hash funkcí tajný klíč. Dále vytvoří TGT lístek (ticket granting ticket).
  TGT lístek obsahuje:
  • jméno klienta - které bylo zasláno AS
  • jméno TGS - který bude vydávat lístky k oprávnění používání určitého zdroje
  • adresa klienta
  • dočasný klíč - bude použit pro komunikaci mezi klientem a TGS
  
  
• 3) Dále AS klientovi zasílá nazpět dvě informace.
  • Dočasný klíč, který je zašifrovaný pomocí tajného klíče nalezeného v databázi+hash.
  • TGT lístek, který je zašifrovaný pomocí speciálního tajného klíče TGS (tento klíč zná jenom TGS a AS)
  
  
• 4) Klient přijme tyto dvě zprávy. Pomocí hesla, které je stejné jako v databázi Kerberos, (stejným způsobem jako AS šifrovalo) dešifruje dočasný klíč. Dočasný klíč pak dále používá ke komunikaci s TGS. V tuto chvíli má tedy klient dočasný klíč a TGT lístek, díky kterému mu bude TGT vydávat speciální lístky povolující využívat jednotlivé služby.
  
  
• 5) Pokud chce v tuto chvíli klient využít určitou službu, vytvoří nejprve authenticator.
  authenticator obsahuje:
  • jméno klienta
  • adresa klienta
  • časovou známku - z důvodu větší bezpečnosti
  Pomocí dočasného klíče zašifruje authenticator a posílá jej TGS. Dále také posílá TGT lístek a název požadované služby.
  
  
• 6) TGS vše přijme a dešifruje TGT lístek, který byl původně zašifrovaný pomocí speciálního tajného klíče TGS (viz. výše). Z TGT lístku tedy zjistí informace o klientovi a dočasný klíč. Dočasným klíčem dešifruje authenticator a porovná zda se položky z TGT a authenticatoru rovnají.
  Dále vygeneruje jiný, dočasný klíč pro komunikaci mezi klientem a serverem (službou).
  vytvoří Serverový lístek, obsahující:
  • jméno klienta
  • jméno serveru
  • adresa klienta
  • životnost tohoto lístku - po jakou dobu je lístek platný
  • časovou známku
  • jím vygenerovaný dočasný klíč
  Serverový lístek zašifruje pomocí speciálního klíče, který sdílí jen se serverem a pošle klientovi. Dále mu také posílá jím vygenerovaný klíč šifrovaný pomocí dočasného klíče, který přijal od klienta.
  
  
• 7) Klient vše přijme a rozšifruje dočasný klíč generovaný v předchozím kroku. V tuto chvíli má klient dočasný klíč pro komunikaci se serverem a Serverový lístek. Nyní vytvoří ještě jeden authenticator pro komunikaci se serverem obsahující:
  • jméno klienta
  • adresu klienta
  • časovou známku
  Pomocí obdrženého dočasného klíče authenticator zašifruje a spolu se Serverovým lístkem jej pošle serveru, jenž poskytuje žádanou službu.
  
  
• 8) Server vše dešifruje a ověří platnost těchto informací.

Konfigurace

• instalovat krb5-libs, krb5-server, krb5-workstation
• editovat konfigurační soubory /etc/krb5.conf, /var/kerberos/krb5kdc/kdc.conf
• vytvořit databázi klíčů pro oblast: /usr/kerberos/sbin/kdb5_util create -s
• pro správu databáze vytvořit alespoň jednoho administratora: /usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"
• spustit krb5kdc a kadmind

• instalovat krb5-libs, krb5-workstation
• editovat konfigurační soubory /etc/krb5.conf

Výpisy konfiguračních souborů

     [logging]
      default = FILE:/var/log/krb5libs.log
      kdc = FILE:/var/log/krb5kdc.log
      admin_server = FILE:/var/log/kadmind.log
     [libdefaults]
      ticket_lifetime = 24000
      default_realm = FI.MUNI.CZ
      dns_lookup_realm = false
      dns_lookup_kdc = false
     [realms]
      FI.MUNI.CZ = {
        kdc = doto-alpha.fi.muni.cz:88
	admin_server = doto-alpha.fi.muni.cz:749
	default_domain = fi.muni.cz
      }
     [domain_realm]
      .fi.muni.cz = FI.MUNI.CZ
      fi.muni.cz = FI.MUNI.CZ
     [kdc]
      profile = /var/kerberos/krb5kdc/kdc.conf
     [appdefaults]
      pam = {
       debug = false
       ticket_lifetime = 36000
       renew_lifetime = 36000
       forwardable = true
       krb4_convert = false
      }

   [kdcdefaults]
    acl_file = /var/kerberos/krb5kdc/kadm5.acl
    dict_file = /usr/share/dict/words
    admin_keytab = /var/kerberos/krb5kdc/kadm5.keytab
    v4_mode = nopreauth
   [realms]
    FI.MUNI.CZ = {
      master_key_type = des-cbc-crc
      supported_enctypes = arcfour-hmac:normal arcfour-hmac:norealm arcfour-hmac:onlyrealm des3-hmac-sha1:normal des-hmac-sha1:normal des-cbc-md5:normal des-cbc-crc:normal des-cbc-crc:v4 des-cbc-crc:afs3
    }

odkazy

PAM

Úvod

Autentizace uživatelů v Unixu byla nejprve prováděna pomocí souboru /etc/passwd. Díky tomu, že /etc/passwd musí byt '644', může si každý uživatel systému zakódovaná hesla přečíst a následně se pokusit hrubou silou rozkódovat. Vznikl tedy další soubor, který již není běžnému uživateli čitelný - /etc/shadow. Tento způsob autentizace je ale v rozporu se zásadami unixu - "... male programy ktere delaji jednu vec a delaji ji dobre ...". Programů, které požadují autentizaci je mnoho. Bylo tedy nutné vytvořit jednotný systém autentizace - PAM.
Díky PAM je možné bez úpravy aplikace užívající PAM měnit autentizační mechanismy, které aplikace používá. Tedy je možné provést upgrade kompletně celého lokálního autentizačního systému bez jakéhokoli zásahu do samotných aplikací.
Programy, které potřebují autentizovat uživatele, mohou zavolat funkci z PAM, která projde s uživatelem autentizační proces a vrátí programu výsledek - uživatel prošel/neprošel. Jako příklady programů, kterým se PAM hodí, můžeme uvést login, su, passwd.
PAM je dostupný snad pro všechny UNIXové systémy - Linux, Solaris, IRIX. Některé BSD PAM nepodporují.

Kongfigurace

• auth - autentizace, ověří že uživatel je ten, kdo tvrdí, že je.
• account - tato hodnota provádí ne-autentizační management účtu. Je typicky používána pro zakázání/povolení přístupu ke službě v závislosti na denním čase, pro omezení odkud se může daný uživatel nalogovat, atd.
• session - určeno na provádění věcí, které je potřeba udělat před/po vykonáním dané služby. Takové věci zahrnují logování informací, mountování disků.
• password - tento poslední modul je nutný pro provedení aktualizace autentizačního symbolu (nejčastěji hesla) souvisejícího s uživatelem.

• required - toto indikuje, že úspěch modulu je nutný pro úspěch celé autentizace.
• requisite - jako required, ale v případě selhání modulu je okamžitě vrácena kontrola aplikaci.
• sufficient - úspěch modulu je brán jako dostatečný pro uspokojení knihovny a skončí se vykonávání autentizace s úspěchem.
• optional - toto označuje modul, který není kritický pro úspěch/selhání autentizace. Pokud všechny ostatní sufficient a optional moduly nejsou úspěšné, pak závisí návratová hodnota na tomto modulu.

Výpis konfiguračního souboru

auth       sufficient   /lib/security/pam_rootok.so
auth       required     /lib/security/pam_stack.so service=system-auth
account    required     /lib/security/pam_stack.so service=system-auth
password   required     /lib/security/pam_stack.so service=system-auth
session    required     /lib/security/pam_stack.so service=system-auth
session    optional     /lib/security/pam_xauth.so

odkazy