Ogni file di configurazione PAM contiene un gruppo di direttive formattate come segue:
<module interface> <control flag> <module name> <module arguments> |
Ciascuno di questi elementi è spiegato nelle sezioni successive.
Esistono quattro tipi diversi di interfaccie di moduli PAM che permettono di controllare l'accesso a determinati servizi e si correlano ad aspetti diversi del processo di autorizzazione:
auth — Fornisce l'autenticazione per l'uso. Per esempio, esso richiede e verifica la validità di una password. I moduli con questa interfaccia possono anche impostare delle credenziali come l'appartenenza al gruppo o i ticket di Kerberos.
account — Questo modulo esegue un controllo per verificare che l'accesso sia abilitato. Per esempio, controlla se un account è scaduto o se l'utente ha il permesso di collegarsi ad una determinata ora del giorno.
password — Questa interfaccia imposta e verificale password.
session — Questa interfaccia configura e gestisce le sessioni dell'utente. I moduli con questa interfaccia, possono effettuare ulteriori compiti richiesti per autorizzare l'accesso, per esempio montando la home directory dell'utente o rendendo disponibile la sua mailbox.
![]() | Nota Bene |
---|---|
Un singolo modulo può fornire una o tutte le interfacce del modulo.Per esempio pam_unix.so fornisce tutti e quattro le interfacce del modulo. |
In un file di configurazione PAM il tipo di modulo è il primo aspetto definito. Per esempio una linea tipica di configurazione è:
auth required pam_unix.so |
Al PAM viene specificato di occuparsi del componente auth dell'interfaccia del modulo pam_unix.so. This instructs PAM to use the pam_unix.so module's auth interface.
Le direttive dell'interfaccia del modulo, possono essereammucchiate o messe l'una sull'altra, in modo tale che moduli multipli possanop essere utilizzati insieme per un unico scopo. L'ordine con cui vengono elencati i moduli è molto importante per il processo di autenticazione.
Tale operazione rende più facile per l'amministratore richiedere la verifica di determinate condizioni prima di autenticare l'utente. Per esempio, rlogin utilizza normalmente almeno cinque moduli auth, come lo dimostra il suo file di configurazione PAM:
auth required pam_nologin.so auth required pam_securetty.so auth required pam_env.so auth sufficient pam_rhosts_auth.so auth required pam_stack.so service=system-auth |
Prima che qualcuno possa usare rlogin, PAM controlla che non esista alcun file /etc/nologin, verifica se si stia provando ad effettuare un collegamento remoto come utente root attraverso una connessione di rete,e se vi sia la possibilità di caricare tutte le variabili d'ambiente. Quindi, se viene eseguita con successo un'autenticazione rhosts, il collegamento viene abilitato. Se l'autenticazione rhosts non va a buon fine, viene effettuata un'autenticazione standard della password.
Quando vengono controllati, tutti i moduli PAM generano un risultato positivo o negativo. I Control flag indicano a PAM cosa fare con il risultato. Poiché i moduli possono essere ordinati in determinati modi, i control flag permettono di stabilire l'importanza di un risultato positivo o negativo di un particolare modulo per l'autenticazione dell'utente al servizio.
Ci sono quattro control flag predefinite:
required — Il modulo deve superare il controllo perché l'autenticazione sia autorizzata. Se il controllo di un modulo required fallisce, l'utente non ne viene avvisato finché tutti gli altri moduli dello stesso tipo non sono stati controllati.
requisite — il modulo deve superare la verifica perché l'autenticazione vada a buon fine. Tuttavia, se la verifica di un modulo requisite fallisce, l'utente ne viene immediatamente avvisato tramite un messaggio che richiama il primo modulo required o requisite.
sufficient — Il risultato del modulo viene ignorato se fallisce. Tuttavia, se il risultato del modulo con opzione sufficient supera la verifica e nessun modulo con opzione required che lo precedono abbia fallito, non viene richiesto nessun altro risultato e l'utente viene autenticato.
optional — Il risultato del modulo viene ignorato.L'unico caso in cui un modulo con opzione optional è necessario ai fini dell'autenticazione è quando non ci sono altri moduli che si riferiscono all'interfaccia.
![]() | Importante |
---|---|
L'ordine con il quale i moduli required sono chiamati non é importante. I control flag sufficient e requisite invece, conferiscono una certa importanza all'ordine. |
Adesso è disponibile una nuova sintassi di controllo ancora più efficace per PAM. Per maggiori informazioni, consultate la documentazione su PAM contenuta nella directory /usr/share/doc/pam-numero_versione/ (dove numero_versione é il numero della versione per PAM).
Il nome del modulo fornisce a PAM il nome del modulo 'pluggable' contenente l'interfaccia del modulo specificato. Con le vecchie versioni di Red Hat Enterprise Linux, Il percorso intero per il modulo veniva fornito all'interno del file di configurazione di PAM, come ad esempio /lib/security/pam_stack.so. Tuttavia con l'avvento di sistemi con librerie multiple, i quali possono conservare moduli PAM a 64-bit all'interno della directory /lib64/security/, il nome della directory viene omesso perchè le applicazioni sono collegate alla versione appropriata di libpam, la quale può trovare la versione corretta del modulo.
PAM utilizza degli argomenti per fornire informazioni a un modulo pluggable durante il processo di autenticazione di un determinato tipo di modulo.
Per esempio il modulo pam_userdb.so utilizza file nascosti del Berkeley DB per autenticare l'utente. Il Berkeley DB è un database Open Source concepito per essere incorporato in varie applicazioni. Il modulo prende un argomento db specificando il file Berkeley DB da usare, che può variare in funzione del servizio.
Pertanto la riga pam_userdb.so di un file di configurazione PAM è:
auth required pam_userdb.so db=<path-to-file> |
Nell'esempio precedente, sostituire <percorso-per-file> con il percorso completo per il file del database Berkeley DB.
Gli argomenti non validi vengono ignorati e non influenzano il superamento né il fallimento del modulo PAM. Tuttavia, molti moduli riporteranno un errore al file /var/log/messages.