14.3. Formato del file di configurazione PAM
Ogni file di configurazione PAM contiene un gruppo di direttive formattate come segue:
<module interface> <control flag> <module path> <module arguments> |
Ogni elemento viene spiegato nelle seguenti sezioni.
14.3.1. Interfaccia del modulo
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:
Il modulo auth fornisce l'effettiva autenticazione, per esempio, richiedendo e controllando una password e fornisce "credenziali", quali l'appartenenza al gruppo o i "ticket" di Kerberos.
Il modulo account esegue un controllo per assicurarsi che l'accesso sia possibile. Per esempio, controlla se un account è scaduto o se l'utente ha il permesso di collegarsi a un determinato orario.
Il modulo password viene usato per impostare e verificare le password.
session — Questo modulo configura e gestisce le sessioni dell'utente. I moduloi 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ò rivolgersi a uno o più moduli specificati sopra. Per esempio pam_unix.so si rivolge a tutti e quattro i tipi di moduli. |
In un file di configurazione PAM il tipo di modulo è il primo aspetto definito. Per esempio una linea tipica di configurazione è:
auth required /lib/security/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.
14.3.1.1. Impilare i moduli
Le direttive dell'interfaccia del modulo, possono essere messe l'una sull'altra, in modo da poter essere utilizzati contemporaneamente per un unico scopo. L'ordine con cui vengono elencati i moduli è molto importante nel 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 /lib/security/pam_nologin.so auth required /lib/security/pam_securetty.so auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_stack.so service=system-auth |
Prima che qualcuno possa usare il comando rlogin, PAM controlla che non esista alcun file /etc/nologin, verifica se si sta provando a effettuare un collegamento remoto come root su una connessione di rete non cifrata e se possono essere caricate tutte le variabili d'ambiente. Viene quindi eseguita un'autenticazione rhosts prima della connessione. Se l'autenticazione rhosts non va a buon fine, viene effettuata un'autenticazione standard della password.
14.3.2. Control Flag
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 controllo del modulo viene ignorato se fallisce. Tuttavia, se un modulo con opzione sufficient supera la verifica e tutti i moduli required che lo precedono, nessun altro modulo di questo tipo viene controllato e l'utente viene autenticato.
optional — il controllo del modulo viene ignorato se non va a buon fine. Se riesce, non riveste un ruolo cruciale per il superamento o il fallimento dell'autenticazione di questo tipo di modulo. L'unico caso in cui un modulo con opzione optional è necessario ai fini dell'autenticazione è quando l'autenticazione di altri moduli dello stesso tipo non ha dato alcun risultato. In tal caso, il modulo optional determina l'autenticazione di tutti i moduli dello stesso tipo.
 | 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).
14.3.3. Percorso del modulo
I percorsi dei moduli indicano a PAM dove trovare il modulo da usare con il tipo di modulo specificato. Solitamente viene fornito l'intero percorso del modulo, quale /lib/security/pam_stack.so. Tuttavia, se non viene indicato tutto il percorso, allora si suppone che il modulo indicato si trovi in /lib/security/ — la directory di default dei moduli PAM.
14.3.4. Argomenti 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 /lib/security/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.