PAM

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (Konkrét modulok: typok)
a (Motiváció: UID sem kell mindig mindenkinek)
30. sor: 30. sor:
 
* webalkalmazások stb.
 
* 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,
+
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.
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
+
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.
LDAP-ból autentikálni.
 
   
 
== Történelem ==
 
== Történelem ==

A lap 2012. november 14., 10:15-kori változata

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.

Tartalomjegyzék

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.

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.
Személyes eszközök