PAM a Kerberos

Michal Trávníček xtravni2@informatics.muni.cz


Obsah


Úvod


Princip jednoduché autentizace

Pro zajištění bezpečnosti systému je třeba autentizace osob, které mají oprávněný přístup do systému. Základním a historickým způsobem ověřování totožnosti uživatele bylo a stále je přihlašování se pomocí hesla - uživatel při přihlášení do UNIXového systému zadá svoje uživatelské jméno a heslo, které se zakóduje typicky DES nebo MD5 šifrovacím algoritmem s přidánim hashe a výsledek se porovná s hodnotou uloženou v souboru /etc/passwd - tím ověří svoji identitu vůči danému systému. Standadně mohou při přihlašování nastat tyto tři stavy: uživatel zadá špatné uživatelské jméno (na což obvykle nebude z bezpečnostních důvodů ihned upozorněn) a potom může zadat libovolné heslo a bude mu oznámeno, že přihlášení nebylo úspěšné. Další možnou situací může být, když uživatel zadá uživatelské jméno správně, ale zadá špatně heslo. Výsledek bude stejný jako v prvním případně. V příznímém případě zadá uživatel (pokud možno svoje) uživatelské jméno a heslo správně a bude mu umožněn vstup do systému. V průběhu práce v prostředí UNIXU je pak uživatel při různých příležitostech nucen heslo zadávat znovu (např. připojování ke vzdálenému počítači, spouštění programu vyžadujícího dodatečné ověřování a mnoho dalších).

Tento jednoduchý princip ověřování totožnosti má tedy mnohá úskalí. Zaprvé je proces pro uživatele nepříjemný, protože musí stále znovu zadávat heslo a zároveň nepraktický - proč by se měl uživatel neustále ověřovat, když už jednou ověřen byl. Dalším problémem je bezpečnost - ručně vkládáné heslo může být prozrazeno, odpozorováno, ukradeno, kdokoliv má volně přístup k souboru /etc/passwd a může tak s pomocí zde uloženého zahašované hesla odhalit heslo původí apod. Bezpečnostní problémem také je, že nikdo nezaručí, zda uživatel je skutečně tím, za koho se vydává. Problematikou autentizace po stránce úrovně zabezpečení se zabývá aplikace Kerberos, ke které se dostaneme později.
Obsah


PAM (pluggable authentication modules)


V roce 1987 byl na systému SCO Xenix zaveden systém stínových hesel. Protože bylo potřeba zachovat možnost volného přístupu do souboru /etc/passwd (pro účely zjišťování údajů o uživatelích), začal se používat soubor /etc/shadow s omezeným přístupem, do kterého se od té doby začaly ukládat zahašovaná hesla, která se následně odstranila z původního souboru. Tato změna měla dopad na programy, které byly zvyklé využívat původní /etc/passwd a musely se upravit. Protože se v některých systémech začala kvůli velkému počtu uživatelů namísto /etc/passwd používat databáze a začaly se objevovat nové způsoby autentizace (RADIUS, Kerberos) bylo nutné často měnit nastavení programů. Vznikla tak potřeba pro systémy správy autentizace a hesel.

Rok 1995 systém sdílených autentizačních modulů PAM - Sun pro platformu Solaris a je specifikován dokumentem
DCE-RFC 86.0 . Jeho alternativou je například GSS-API jenž je definováno v RFCs 1508 a 1509.

Tento svrchovaným správce autententizace v rámci systému se stal standartem a je implementován i na LINUXu - jsou zde však menší odchylky od verze pro Solaris.

O co tedy v tomto systému jde: zjednodušeně řečeno o zrušení potřeby opětovné autentizace uživatele, nebo také o systém sdílené autentizace pro jakékoliv potřeby. Systém je založen na souboru knihoven (modulů), které umožňují programům sdílet autentizační infromace a provádět automatické ověřování. Déle je zde abstrakce od vlastního způsobu autentizace - systém je flexibilní - není spojený s určitým způsobem ověřování totožnosti a umožňuje využít jakéhokoliv způsobu a systému autentizace - je zde podpora pro RSA, DCE, Kerberos, smart cards "inteligentní moduly" - snímání oční sítnice, čtečky karet, hardwarová autentizace a další. PAM je součástí mnoha Linuxových distribucí jako jsou Caldera 1.3, 2.2 a novější, Debian 2.2 a novější, Turbo Linux 3.6 a novější, Red Hat 5.0 a novější a SuSE 6.2 (částečná podpor). Podpora PAMu je ve FreeBSD od verze 3.1.

Obsah

Konfigurace PAM

Struktura a místo uložení konfiguračních souborů se může na jednotlivých systémech lišit. Původě se nastavení ukládalo v jedniném souboru /etc/pam.conf. V poslední době se však prosazuje používání adresáře s jenotlivými konfiguračními soubory (RedHat, Debian), které se nachází ve složce /etc/pam.d/

Položky v konfiguračních souborech PAM jsou strukturovány takto:

module-type	control-flag   		module-path   				arguments


Příklad souboru /etc/pam.d/rlogin na RedHatu6.0:
#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth sufficient /lib/security/pam_rhosts_auth.so
auth required /lib/security/pam_pwdb.so shadow nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so nullok use_authtok md5 shadow
session required /lib/security/pam_pwdb.so
(při použití jediného konfiguračního souboru /etc/pam.conf se před module-type uvádí ještě service-name)
Podrobnější popis jednotlivých položek přebírám s mírnějšími úpravami z práce
Tomáše Jirky.
service-name

Tato položka se používá pouze při uložení konfigurace v /etc/pam.conf. Představuje jméno služby, která se vztahuje k tomuto řádku. Při použití více konfiguračních souborů v adresáři /etc/pam.d se služby rozlišují podle jména souboru. Nejčastěji se používá jméno aplikace, které se daná služba týká. Například: login, passwd, su, ftpd a ssh . Existuje speciální služba OTHER rezervovaná pro definování defaultního ověřovacího mechanizmu. Tato služba se použije, pokud program nespecifikuje konkrétní službu, nebo pokud služba není nakonfigurovaná.

module-type

Jeden ze čtyř typů využití modulu:

control-flag

Kontrolní příznak se používá k tomu, aby se PAMu určilo, jak má reagovat na úspěšné ukončení/selhání daného modulu. Protože moduly se mohou dávat do série (moduly stejného typu se spouštějí v sérii, jeden po druhém), kontrolní příznaky určují relativní důležitost každého modulu. Takové sérii modulů budeme říkat skupina. Aplikace se nedozví, jak dopadl individuální modul. Místo toho dostane od knihovny Linux-PAM odpověď ve formě: úspěšné ukončení nebo selhání skupiny. Pořadí spouštění modulů je dáno jejich seřazením v konfiguračním souboru. Od Linux-PAM v0.60 je možné kontrolní příznak specifikovat jednou ze dvou syntaxí.

Jednodušší (a historicky starší) syntaxe pro ontrolní příznak je jedno klíčové slovo definované k nastavení přísnosti asociované s úspěšné ukončením nebo selháním specifikovaného modulu. Existují čtyři taková klíčová slova: required, requisite, sufficient a optional.

Linux-PAM knihovna je interpretuje následujícím způsobem:

Více propracovaná (novější) syntaxe dává administrátorovi velký potenciál ke konfigurování toho, jakým způsobem se ověřuje totožnost uživatele. Tato forma kontrolního příznaku je vymezena hranatými závorkami a sestává ze série value=action prvků:

   [value1=action1 value2=action2 ...]

Kde, valueI je jedna z následujících návratových hodnot: successopen_err; open_err; symbol_err; service_err; system_err;buf_err; perm_denied; auth_err; cred_insufficient; authinfo_unavail; user_unknown; maxtries; new_authtok_reqd; acct_expired; session_err; cred_unavail; cred_expired; cred_err; no_module_data; conv_err; authtok_err; authtok_recover_err; authtok_lock_busy; authtok_disable_aging; try_again; ignore; abort; authtok_expired; module_unknown; bad_item; a default. Poslední z nich (default) může být použit na nastavení akce pro návratové hodnoty, které nejsou určeny explicitně.

actionI může být kladné přirozené číslo nebo jedna z následujících hodnot: ignore; ok; done; bad; die; a reset. Kladné číslo, J, pokud je specifikováno jako akce, může být použito k indikování, že příštích J modulů tohoto typu bude přeskočeno. Takto může administrátor vytvořit poměrně komplexně propojenou skupinu modulů s mnoha různými možnostmi provedení. Která možnost bude provedena je dáno reakcí jednotlivých modulů.

module-path

Cesta k dynamicky zaveditelným objektovým souborům; samotný pluggable modul. Pokud je první znak cesty k modulu `/', je brána jako absolutní cesta. Pokud není, modul se hledá implicitně v /usr/lib/security. Ovšem RedHat Linux (který používá PAM již od RedHat Linux 3.0.4) má moduly v /lib/security a v konfiguraci je specifikovaná celá cesta.

arguments

Argumenty tvoří seznam, který je předán modulům při spuštění. Podobně jako argumenty pro typický linuxový příkaz shellu. Obecně jsou argumenty volitelné a jsou specifické pro daný modul. Chybné argumenty jsou ignorovány a od modulu je požadováno, aby nahlásil chybu pomocí funkce syslog(3).

Příklady některých dalších základních konfiguračních souborů:

# /etc/pam.d/login
# Náhrada standardního Unixovského loginu.
#
account  required       /usr/lib/security/pam_unix.so
auth     requisite      /usr/lib/security/pam_nologin.so
auth     required       /usr/lib/security/pam_unix.so
session  required       /usr/lib/security/pam_unix.so

# 
# /etc/pam.d/passwd
# Menší změny v klasickém Unixovském programu pro změnu hesla.
# modul 'pam_cracklib.so' je užitečný pro nastavování bezpečnosti hesla. 
#
password required  /usr/lib/security/pam_unix.so nullok md5 remember=5

#
# /etc/pam.d/other
# Zamezení používání programů, které nejsou nakonfigurované.
#
account  required       /usr/lib/security/pam_deny.so
auth     required       /usr/lib/security/pam_deny.so
auth     required       /usr/lib/security/pam_warn.so
password required       /usr/lib/security/pam_deny.so
password required       /usr/lib/security/pam_warn.so
session  required       /usr/lib/security/pam_deny.so

Obsah

Základní moduly PAM

pam_unix.so

Tento modul poskytuje klasickou Unixovou autentizaci, správu hesel a nastavení uživatelských účtů. Využívá standardní systémová volání pro zjišťování a nastavování hesla a informací týkajících se účtu. Modul je napojen na /etc/shadow a /etc/passwd.

account
Nastavuje pravidla pro platnost uživatelského účtu a hesla, má schopnost nabádat ke změně hesla nebo dokonce může změnu hesla vyžadovat. Přímá spojitost se soubory /etc/passwd a /etc/shadow .

Argumenty: audit, debug.

auth
Tato část modulu porovnává uživatelské heslo s databázemi hesel. Konfigurace této komponenty se provádí v /etc/nsswitch.conf. Pomocný program unix_chkpwd umožňuje komponentě přístup pro čtení do chráněných databází aniž by musel mít celý modul práva superuživatele.

Argumenty: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.

password
Tato komponenta umožňuje měnit uživatelské heslo. Ve spojitosti s modulem pam_cracklib.so můžeme tuto komponentu využívat pro kontrolu bezpečnosti hesla.

Argumenty: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok, and use_first_pass.

session
Tato součást modulu zaznamenává na začátku a na konci relace (přihlášení a odhlášení) jméno uživatele a typ relace do systémového logu (syslog). Tato komponenta nevyužívá žádné další argumenty.

argumenty

pam_warn.so

Tento modul ukládá informace o pokusu o přihlášení nebo o pokusu o změnu hesla do systémového logu (syslog).

Tento modul nepodporuje žádné argumenty a umožnuje použití pouze komponent auth a password.

pam_deny.so

Tento modul blokuje přístup k aplikaci. Jako komponenta auth nebo account, brání uživatelům v přihlášení nebo vytvoření účtu. Jako komponenta password zakazuje uživatelům měnit si heslo. Jako komponenta session, může být ve skupině s moduly typu pam_motd.so, které zobrazují zprávy a brání uživateli ve spuštění shellu.

Tento modul nepodporuje žádné argumenty, a zároveň podporuje všechny komponenty. Opačnou funkci zastává modul pam_permit.so.

pam_nologin.so

Poskytuje standardní Unixovou autentizaci s využítím nologin. Pokdu existuje soubor /etc/nologin, má do systému přístup pouze superuživatel a ostatním uživatelům se ukáže obsah /etc/nologin. Tento modul uspěje, pokud soubor /etc/nologin není v odpovídajícím adresáři přítomen.

Tento modul nepodporuje žádné argumenty, a podporuje pouze komponentu auth. Měl by být ve všech konfiguracích a metodách přihlášení zahrnut jako required, a to před jakýmkoliv modulem sufficient.

Obsah

Kerberos

Kerberós měl tři hlavy, hady ovinuté kolem šíje a ocas končící dračí hlavou. Bdělý strážce podsvětní Hádovy říše; pouze jediný Héraklés vyvedl Kerbera na světlo dne, když ho z příkazu krále Eurysthea přivedl do Mykén.

Kerberos je systém pro autentizaci uživatelů a služeb v rámci sítě. Základním předpokladem, z něhož jeho koncepce vychází je, že síť není bezpečnou zónou pro volný pohyb informací. Data zasílaná po síti mohu být kupříkladu odposlouchávána a pozměňována a síťové adresy mohou být falšovány. Proto nemůžeme považovat autentizaci pomocí těchto prostředků za důvěryhodnou.

Kerberos je důvěryhodná autorita zprostředkovávající komunikaci dvou stran. To znamená, že zde existuje důvěryhodná třetí strana (server Kerberos), která je považována všemi účastníky (principals) síťové komunikace (uživatelé a služby) za důvěryhodnou a která dohlíží nad jejich vzájemnou komunikací. Všichni komunikující účastníci sdílejí tajné heslo neboli klíč s Kerberos serverem a pomocí tohoto klíče si mohou ověřit, zda jsou zprávy přicházející z kerberos serveru autentické. Pokud tímto způsobem důvěřují účastníci Kerberos serveru, mohou se ověřovat i navzájem mezi sebou.


Kerberos v datech

1987: návrh Kerberos v4, instalován na MIT v rámci projektu Athena
1990: návrh Kerberos v5 je více méně hotový
1991: Kerberos v5 adaptován OSF/DCE
1992: Rozsáhlé instalace Kerberosu v4 na univerzitách
1993: publikováno RFC 1510, oficiální specifikace v5;
současně bylo představeno RFC 1509 GSS-API v1 specifikace
1996: MIT představilo implementaci Kerberos v5 1.0
1997: Microsoft ohlásil podporu Kerberosu pro Windows NT5;
současně bylo představeno RFC 2222 SASL specifikace

V roce 1997 se též rozjíždí projekt Heimdal (resp. vychází jeho nultá verze), který má za cíl stát se volně šířitelnou implementací MIT Kerberosu, jenž měl v tu dobu zákaz distribuce mimo území USA, což je však nyní už minulostí. Heimdal se nyní nachází ve verzi 0.6, kdy zachovává zpětnou kompatibilitu s vlastními vývojovými verzemi, je vysoce kompatibilní s MIT Kerberosem verze 4 a snaží se udržovat kompatibilitu s verzí 5.


Princip ověřování v systému Kerberos

(Následuje popis autentizačního mechanizmu Kerberos verze 4, která se od aktuální verze 5 liší jen minimálně)

V systému Kerberos využívají účastníci lístky (tickets), pomocí kterých prokazují, že jsou těmi, za něž se vydávají. V následujícím příkladě je A iniciátor spojení a vysílá požadavek na B, což  je služba , kterou chce A využít.

Pokud chce A získat lístek pro službu B, musí zaslat žádost o lístek na kerberos server. Žádost obsahuje jména účastníků A a B (plus další doplňkové údaje). Kerberos server si ověří, zda jsou A a B platnými účastníky.

Potom, co server ověří pravost účastníků, vytvoří paket, který bude obsahovat jména A a B, síťovou adresu A (A <adresa>), aktuální čas (t <čas podání>), dobu platnosti lístku (platnost) a tajný klíč relace (session key K<AB>). Tento paket bude zakódován tajným heslem B (K<B>). Samotný lístek (T <AB>)bude vypadat  takto: ({A, B, A<adresa>, t <čas vydání >, platnost, K<AB>}K<B>).

Odpověď účastníkovi A se bude skládat z lístku (T<AB>), jména B, aktuálního času, platnosti lístku a klíče relace, vše zakódované pomocí  tajného klíče A ({B, t<čas vydání >, platnost , K<AB>, T<AB>}K<A>). A si zprávu rozluští a uchová pro pozdější využití.

Předtím, než zašle A zprávu  B, vytvoří ověřovací zprávu (authenticator), která se skládá ze jména A, adresy A, aktuálního času, a  kontrolního součtu, který A zvolí  – to vše se zakóduje tajným klíčem relace ({A, A<adresa>, t<aktuální čas>, kontrolní součet}K<AB>). Tyto údaje se spolu s lístkem, který účastník obdržel od kerberos serveru, zašlou entitě B. Po přijetí těchto dat B dekóduje lístek pomocí svého tajného klíče. Protože lístek obsahuje klíč relace, může nyní B dekódovat ověřovací zprávu, která byla pomocí něj zakódována. Aby si B nyní ověřil, že A je opravdu A, musí porovnat obsah lístku s obsahem ověřovací zprávy. Pokud údaje souhlasí, bude B považovat A za řádně ověřené.

Příklady možných útoků

Vydávání se za A

Neseriózní strana C může zachytit ověřovací zprávu a lístek během jejich cesty po síti a začít se s jejich pomocí vydávat za A. Síťová adresa v lístku a ověřovací zprávě slouží k tomu, aby se takovým situacím předcházelo a útok tohoto typu byl mnohem obtížnější. Z toho důvodu by uživatel C musel být buďto na stejném počítači jako A, nebo by musel zfalšovat zdrojové adresy paketů ze svého počítače. Protože je v ověřovací zprávě zahrnuta časová známka, nemá C mnoho času, aby svůj útok provedl.

Vydávání se za B

C se může zmocnit síťové adresy B a když A zašle požadavek k ověření, C bude předstírat, že ho autorizoval. C si však nemůže být nikdy jist, že opravdu komunikuje s A.

Způsoby jak čelit útokům

Na straně serveru by bylo možné zavést tzv. replay cache. Princip tohoto řešení je v tom, že by se ukládaly ověřovací zprávy zaslané během poslední doby, takže by B mohlo zjistit, že se někdo snaží znovu zaslat jíž použitou ověřovací zprávu. Toto řešení je poměrně nepraktické (hlavně co se týče efektivity), a není součástí Kerberosu 4, MIT Kerberos 5 však tuto funkci obsahuje.

Pro ověření B, by mohlo A požadovat od B zpětné zaslání nějakého důkazu o tom, že má B přístup ke klíči relace. Například by mohlo jít o kontrolní součet který vytvořilo A jako součást ověřovací zprávy. Typicky se to řeší tak, že B připočte ke kontrolnímu součtu jedničku, zakóduje výsledek pomocí klíče relace a pošle vše zpět A. Tomuto procesu se říká vzájemné ověření.

Klíč relace lze také použít pro přidání kryptografických kontrolních součtů ke zprávám posílaným mezi A a B (což se nazývá celistvost, integrita zprávy). Může se též přidat šifrovaní (utajení zprávy). To je asi nejlepší postup jak se chránit ve všech případech útoků.


Zdroje


PAM
http://www.kernel.org/pub/linux/libs/pam
http://news.tucows.com/ext2/99/08/security/081999-security1.shtml
http://www.linuxdevcenter.com/pub/a/linux/2001/09/27/pamintro.html
http://www.kolej.mff.cuni.cz/~tjir5186/Linux-PAM/
http://www.root.cz/clanek/478


Kerberos
http://web.mit.edu/kerberos/
http://www.pdc.kth.se/heimdal/heimdal.html
http://www.mcc.ac.uk/Documentation/coda/heimdal_4.html
http://www.rospa.ca/projects/kerberos/Heimdal_Kerberos.pdf
http://www.sans.org/rr/papers/67/1288.pdf
http://www.natur.cuni.cz/prfdec/kerberos.htm

Obsah