PAM

A PAM (Pluggable Authentication Modules) egy moduláris autentikációs keretrendszer. Arra való, hogy:

• az autentikációt igénylő programok (pl. sshd) elől elrejtse az autentikáció részleteit; illetve hogy
• ne kelljen minden programban megvalósítani az autentikációt; és hogy
• áttérhessünk más autentikációs mechanizmusra anélkül, hogy az alkalmazásainkat bántanunk kellene.

1 Motiváció

Az idők hajnalán minden program önállóan valósította meg az autentikációt; pl. elolvasta a /etc/passwd file-t, és a felhasználó által beírt jelszót (pontosabban a belőle készült hasht) összehasonlította a jelszófájlban levővel.

Manapság sokféle autentikációs backendet szeretnénk használni. /etc/passwd helyett pl:

• egyéb jelszófájlt;
• relációs adatbázist;
• címtárat stb.;

jelszó helyett:

• ujjlenyomat-leolvasót;
• chipkártyát;
• OTP-t (one-time-password) stb.

Számos szolgáltatásunk van, ami autentikációt igényel:

• konzolos bejelentkezés;
• ssh;
• levelezés (smtp, imap, pop3);
• ftp;
• webalkalmazások stb.

Egy fizikai gépen többféle felhasználói adatbázisból is kellhet autentikálni: pl. ha van 50000 userünk, akiknek nálunk van a mailboxa, akkor az általában nem szükséges, hogy ők a konzolon is be tudjanak lépni, sőt. Igazából az sem fontos, hogy egyedi unixos UID-val (pláne GID-val) rendelkezzenek: elég, ha a levelezőszerver meg tudja őket különböztetni valahogy. Ehhez nincs feltétlenül szükség a kernel segítségére.

Jó lenne, ha az autentikációs alrendszer független lenne a programoktól; tehát pl. nem az alapján kellene IMAP-szervert választanunk, hogy melyik tud LDAP-ból autentikálni.

2 Történelem

• A SUN javasolta 1995. októberében.
• Hamarosan a PAM lett a CDE (Common Desktop Environment) autentikációs alrendszere.
  • A CDE koncepcionálisan pl. a KDE előfutárának tekinthető.
• A PAM 1996-ban jelent meg a Red Hat Linuxban.
• Jelenleg a következő oprendszerekben található meg:
  • AIX,
  • FreeBSD,
  • HP-UX,
  • a legtöbb Linux-disztribúció (van egyáltalán kivétel?),
  • Mac OS X,
  • NetBSD,
  • Solaris.
• Az X/Open szabványosította.
  • De természetesen - ahogyan ez a Unix-világban lenni szokott - túl későn:
    • már voltak működő implementációk, és
    • természetesen a szabványban egy olyan APIt sikerült specifikálni, amelyik egyetlen létezővel sem egyezett meg.

3 Filozófia

Minden PAM-ot használó alkalmazásnak van egy saját "profilja" a PAM konfigurációján belül, ami leírja, hogyan kell az adott alkalmazás számára a felhasználókat hitelesíteni. Az alkalmazás betölti a PAM libraryt, megmondja neki, melyik (milyen nevű) profilt szeretné használni, és innentől - kicsit leegyszerűsítve - a library teszi a dolgát.

Mint a PAM neve is mondja, viszonylag szabadon cserélgethető és kombinálható moduljaink vannak, amik a hitelesítés különböző részeit más-más módokon oldják meg.

A PAM koncepciója szerint egy szolgáltatás nyújtása a következő fázisokra bontható:

1. megállapítjuk, hogy a user az, akinek mondja magát, és átváltunk az ő UID-jára, belépünk a csoportjaiba:
   • pl. úgy, hogy kiírunk egy login: és egy password: promptot és
   • a /etc/passwd segítségével ellenőrizzük, megfelelő-e, amit a user beírt;
2. megállapítjuk, hogy minden egyéb feltétele adott-e annak, hogy ő a szolgáltatást az adott pillanatban az adott helyről igénybe vegye:
   • pl. nem járt le a jelszava?
   • Vagy esetleg a root csak a konzolon léphet be, vagy
   • a pénzügyes alkalmazásszerverre csak munkaidőben szabad belépni, vagy
   • korlátozva van az egyszerre bejelentkezhető felhasználók száma (mondjuk ftp-nél), vagy
   • a felhasználónkénti bejelentkezések száma (ftp-nél, pop3-nál, vpn-nél);
3. teljesítjük a kérését,
   • pl. futtatunk egy interaktív shellt az ő UID-jával.
4. Külön fázisnak tekintjük a szolgáltatáshoz kapcsolódó hitelesítési adatok (pl. jelszó) módosítását.

Egy-egy PAM egy vagy több fázist is megvalósíthat, és egy-egy alkalmazásnál egy-egy fázisban egynél több modul használatát is előírhatjuk. Az egyes fázisokat a PAM a következőképpen hívja:

1. auth;
2. account;
3. session;
4. password.

4 Konfiguráció

A /etc/pam.d/ könyvtárban minden PAMos szolgáltatásunkhoz tartozik egy fájl, ami az ő profilját tartalmazza.

Pl. egy konkrét gépen a /etc/pam.d/sshd tartalma a következő (az include-olásokat elvégeztem):

# PAM configuration for the Secure Shell service

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
auth       required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
auth       required     pam_env.so envfile=/etc/default/locale

# Standard Un*x authentication.
auth    required        pam_unix.so nullok_secure

# Disallow non-root logins when /etc/nologin exists.
account    required     pam_nologin.so

# Uncomment and edit /etc/security/access.conf if you need to set complex
# access limits that are hard to express in sshd_config.
# account  required     pam_access.so

# Standard Un*x authorization.
account required        pam_unix.so

# Standard Un*x session setup and teardown.
session required        pam_unix.so
session optional        pam_tmpdir.so

# Print the message of the day upon successful login.
session    optional     pam_motd.so # [1]

# Print the status of the user's mailbox upon successful login.
session    optional     pam_mail.so standard noenv # [1]

# Set up user limits from /etc/security/limits.conf.
session    required     pam_limits.so

# Set up SELinux capabilities (need modified pam)
# session  required     pam_selinux.so multiple

# Standard Un*x password updating.
password   required   pam_unix.so nullok obscure min=4 max=8 md5

Vegyük észre, hogy több auth, account és session modul is van! Ezek a PAM terminológiájában egy-egy stacket képeznek.

Az alkalmazásokhoz tartozó konfigurációs fájlok sorainak felépítése a következő:

type control module-path module-arguments

A type mezőben az auth, az account, a session és a password valamelyike szerepelhet; az adott sor csak az adott fázisban fog szerepet játszani.

A module-path valamely konkrét PAM fájlneve; a module-arguments a modulnak átadandó paraméterek listája.

A control határozza meg, mi a teendő abban az esetben, ha az adott modul működése sikertelen (pl. a user elrontja a jelszót). Kétféle szintaxisa van: egy egyszerű és egy összetett.

Az egyszerűben a következő kulcsszavakat lehet használni (ezek szerepelnek az sshds példában is):

• required:
  • Ha a modul futása sikertelen, a végeredmény is az lesz, de a stack többi modulját is lefuttatjuk.
• requisite
  • Ha a modul futása sikertelen, azonnal sikertelen bejelentkezést jelzünk az alkalmazásnak; a többi modul nem fut le.
  • Használata pl: meg sem kérdezzük a jelszót, ha az átviteli közeg nem biztonságos.
• sufficient
  • Ha a stackben korábban nem volt sikertelen required modul, és
  • a sufficient modul futása sikeres, akkor a bejelentkezés sikeres, és a további modulok nem futnak le.
  • Ha a stackben korábban volt sikertelen required modul, a sufficient modul esetleges sikerességét a PAM figyelmen kívül hagyja.
  • Ha a sufficient modul futása sikertelen, a PAM veszi a következő modult (ebből a fázisból).
• optional
  • Csak akkor számít a sikeressége, ha ez az adott szolgáltatás egyetlen, ehhez a fázishoz tartozó modulja.
• include
  • Ritkán használják, de azért példa: session include foobar
  • azt eredményezi, hogy a foobar szolgáltatás profiljából a session típusú modulokat a jelenlegi szolgáltatás session stackjébe is beemeljük.
  • Szerintem jobb helyette a @include filenév jellegű include-mechanizmus, ami az egész file-t include-olja.
• substack
  • Olyan, mint az include, csak szubrutinhívás-szerű szemantikával.
  • Szintén ritkán használják; akit érdekelnek a konkrétumok, olvassa el a manban.

Az összetett szintaxis a következőképpen néz ki:

[visszatérési_érték1=action1 vissz_érték2=action2 ...]

• Jelentése: ha a modul a megadott visszatérési értékek valamelyikével tér vissza, akkor a hozzá tartozó akciót kell végrehajtani.
• Visszatérési értékből sok van; pl.: success, cred_expired, perm_denied, abort stb.
• Ezeknek a jelentése nincs jól dokumentálva; a forrásban kell elolvasni.
• A default visszatérési érték speciális. Jelentése: "minden egyéb, külön nem specifikált visszatérési érték esetén".
• Akció lehet:
  • egy n természetes szám; jelentése: ugord át ebben a stackben a következő n modult.
  • ignore: az adott modul visszatérési értéke ne befolyásolja a teljes stack visszatérési értékét.
  • bad: sikertelen hitelesítést jelez az alkalmazásnak.
  • die: sikertelen hitelesítést jelez az alkalmazásnak és a stackben szereplő további modulokat átugorja.
  • ok: ha az eddigi modulok futása alapján sikeres lenne a hitelesítés, a jelenlegi modul visszatérési értéke legyen a teljes stack visszatérési értéke.
  • done: mint az ok, de a stack többi modulját nem futtatja.
  • reset: törli a stack állapotterét; a következő modul "tiszta lappal" indul.

Az egyszerű szintaxis elemei a következő módon fejezhetők ki a bonyolult szintaxissal:

required
	[success=ok new_authtok_reqd=ok ignore=ignore default=bad] 

requisite
	[success=ok new_authtok_reqd=ok ignore=ignore default=die] 

sufficient
	[success=done new_authtok_reqd=done default=ignore] 

optional
	[success=ok new_authtok_reqd=ok default=ignore] 

(Nem túl jó) példa:

session	[success=1 default=ignore]	pam_unix.so
session	required			pam_ldap.so use_first_pass
session	required			pam_permit.so
session	optional			pam_tmpdir.so
session	required			pam_mkhomedir.so

4.1 Konkrét modulok

A teljesség igénye nélkül...

• pam_access.so: korlátozhatjuk, ki, honnan, melyik szolgáltatást használva léphet be egyáltalán. Konfigurációja a /etc/security/access.conf-ban.
• pam_cracklib.so: jelszóváltoztatáskor ellenőrzi, nem szótári szó-e az új jelszó.
• pam_deny.so: feltétel nélkül tilt.
• pam_echo.so: szöveges üzeneteket ír ki a hitelesítés során.
  • Használata pl.: password optional pam_echo.so file=/usr/share/doc/how-to-choose-good-password.txt
• pam_env.so: környezeti változókat állít be, fájlból (/etc/environment).
  • Használata pl.: rendszerszintű PATH- és locale-beállítás.
• pam_exec.so: külső programot hív meg.
• pam_group.so: további csoportokba lépteti be a usert, ha megadott helyről jelentkezik be.
• pam_lastlog.so: kiírja, mikor és honnan lépett be a user utoljára.
• pam_limits.so: erőforráskorlátokat állít be.
• pam_listfile.so: egy sima szövegfile alapján enged vagy tilt; pl.:
  • a megadott felhasználók nem használhatják az ftp-t;
  • a soros porton keresztül bárki jelszó nélkül léphet be;
  • a konzolon csak a megadott csoport(ok) tagjai léphetnek be stb.
• pam_localuser.so: csak azokat a usereket engedi belépni, akik benne vannak a /etc/passwd-ben (pl. címtárban levőket nem).
• pam_mail.so: belépéskor tájékoztatja a felhasználót, ha új levele van.
• pam_mkhomedir.so: belépéskor létrehozza a user home-könyvtárát. LDAP esetén hasznos.
• pam_namespace.so: saját mount namespace-t csinál a bejelentkezett usernek.
  • Pl. csinálhatunk vele mindenkinek külön /tmp könyvtárat.
• pam_permit.so: feltétel nélkül mindent enged.
• pam_rootok.so: a rendszergazdát engedi belépni; pl. su esetén:

auth	sufficient	pam_rootok.so
auth	required	pam_unix.so

• pam_securetty.so: a rendszergazdát csak biztonságos vonalakról engedi belépni (pl. fizikai vagy soros konzol, valamint ssh).
• pam_succeed_if.so: az account tulajdonságaival kapcsolatban megfogalmazott feltételektől függően enged vagy tilt (pl. uid-tartományba tartozást lehet vizsgálni vele).
• pam_tally.so: túl sok sikertelen próbálkozás esetén kitiltja a usert.
• pam_umask.so: az umaskot állítja be.
• pam_unix.so: a hagyományos unixos passwd-/shadow-alapú hitelesítést valósítja meg. Számos opciója van.
• pam_userdb.so: BerkeleyDB-ben tárolt felhasználókat hitelesít.
• pam_xauth.so: sun át is megőrzi az X display-hez tartozó cookie-t, így suból is lehet X-es programokat futtatni.

És ezek még csak azok a modulok, amik a PAM-csomagban vannak (abból sem az összes).

Még néhány, mások által fejlesztett modul (Debian csomagnevekkel):

• libpam-blue: bluetooth-alapú hitelesítés
• libpam-ccreds - cache; akkor is enged belépni, ha pl. nem elérhető az LDAPszerver.
• libpam-chroot - chrootolja a usert.
• libpam-dbus - a helyi konzolon belépett felhasználótól kérdezi meg, hogy akarja-e engedni a távoli felhasználót belépni.
• libpam-dotfile - lehetővé teszi, hogy a felhasználók az egyes szolgáltatásokhoz különböző jelszavakat rendeljenek.
• libpam-encfs - automatikusan mountolja a felhasználóhoz tartozó titkosított fájlrendszereket bejelentkezéskor.
• libpam-foreground - nyomon követi, melyik konzolon ki van, így bizonyos műveleteket pl. csak az aktuálisan előtérben levő konzolon bejelentkezett usernek enged.
• libpam-http - úgy hitelesít, hogy a megadott user/pass párossal megpróbál lekérni egy URL-t.
• libpam-ldap - LDAPból hitelesít.
• libpam-mount - bejelentkezéskor fájlrendszereket mountol.
• libpam-mysql - MySQL-ből hitelesít.
• libpam-ncp - NetWare-ből hitelesít.
• libpam-nufw - megfelelő tűzfallal kiegészítve a tűzfal a rajta átmenő forgalomról is tudni fogja, kié, és az alapján is szűrhet.
• libpam-pgsql - PostgreSQL-ből hitelesít.
• libpam-pwgen - jelszavakat generál.
• libpam-shield - elvileg kitiltja a jelszópróbálgatókat.
• libpam-ssh - a titkosított ssh-kulcsok és az ssh-agent használatát könnyíti meg.
• libpam-tmpdir - minden usernek külön tmp-könyvtárat csinál.
• libpam-usb - USB-kulcs alapján hitelesít.

4.2 Mire kell vigyázni?

• Ha egy szolgáltatáshoz nincs külön profil, a PAM az other profilt használja. Ez lehetőleg ne engedjen be mindenkit válogatás nélkül.