File di configurazione PAM
I file di configurazione PAM sono contenuti nella directory /etc/pam.d. Nelle versioni precedenti di PAM tali file erano invece contenuti in /etc/pam.conf. Il file pam.conf viene letto se la directory /etc/pam.d/ non è presente sul sistema, ma il suo utilizzo è sconsigliato.
Ogni applicazione (o servizio, nome solitamente attribuito alle applicazioni utilizzate da molti utenti) ha un suo proprio file. Ogni file contiene cinque elementi diversi: nome del servizio, tipo di modulo, indicatore di controllo, percorso di modulo e argomenti.
Nomi di servizio PAM
Il nome di servizio di ogni applicazione basata su PAM corrisponde al nome del suo file di configurazione contenuto in /etc/pam.d. Ogni programma che utilizza PAM definisce il proprio nome di servizio.
Per esempio il programma login definisce il nome di servizio login, ftpd determina il nome di servizio ftp e così via.
In generale, il nome di servizio corrisponde al nome del programma usato per accedere al servizio, non al programma usato per fornire il servizio.
Moduli PAM
PAM fornisce quattro tipi diversi di moduli che permettono di controllare l'accesso a particolari servizi:
Il modulo auth fornisce l'effettiva autenticazione (forse 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'autenticazione sia possibile (se l'account non è scaduto, se l'utente ha il permesso di accedere a quest'ora del giorno, ecc).
Il modulo password viene usato per configurare le password.
Il modulo session viene chiamato in causa una volta che l'autenticazione di un utente è stata eseguita per rendere possibile l'uso dell'account, magari montando la sua directory home o rendendo disponibile la mailbox.
Questi moduli possono essere inseriti nello stack o impilati in modo da poter essere utilizzati contemporaneamente. L'ordine del modulo stack è molto importante nel processo di autenticazione, poiché facilita all'amministratore il compito di richiedere la verifica di determinate condizioni prima di autorizzare l'autenticazione dell'utente.
Per esempio, rlogin utilizza normalmente almeno quattro metodi di autenticazione tramite stack, come 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 account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth |
Prima che qualcuno possa usare il comando rlogin, PAM verifica se esiste /etc/nologin, se si sta provando a effettuare un collegamento in modo remoto come root e se possono essere caricate tutte le variabili d'ambiente. Viene poi eseguita un'autenticazione rhosts. Se l'autenticazione rhosts non va a buon fine, viene effettuatata un'autenticazione standard della password.
Nuovi moduli possono essere aggiunti in ogni momento e le applicazioni compatibili con PAM possono utilizzarli. Per esempio, se create un nuovo sistema di calcolo della password e scrivete un modulo PAM per supportarlo, i programmi compatibili con PAM possono immeditamente usare il nuovo modulo e la nuova password senza dover essere ricompilati o modificati. Ciò permette di abbinare e verificare molto velocemente i metodi di autenticazione con diversi programmi senza doverli ricompilare.
Una documentazione sulla scrittura dei moduli è disponibile in /usr/share/doc/pam—<numero versione>.
Opzioni PAM
Quando vengono controllati, tutti i moduli PAM generano un risultato positivo o negativo. Le opzioni indicano a PAM cosa fare con il risultato del controllo. Poiché i moduli possono essere ordinati in determinati modi, le opzioni permettono di stabilire l'importanza di un modulo rispetto ai moduli successivi.
Considerate il file di configurazione PAM rlogin:
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 account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth |
Una volta specificato il tipo di modulo, gli indicatori di controllo decidono quanta importanza deve essergli attribuita rispetto all'accesso di tale utente al programma.
Lo standard PAM determina quattro tipi di opzioni di controllo:
I moduli con opzione required devono 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.
I moduli con opzione requisite devono anch'essi 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 requisite o required che non ha superato la verifica.
Le verifiche dei moduli sufficient vengono ignorate se falliscono. Tuttavia, se un modulo con opzione sufficient supera la verifica così come tutti i moduli required che lo precedono, nessun altro modulo di questo tipo viene controllato.
I moduli con opzione optional non rivestono un ruolo cruciale per il superamento o il fallimento dell'autenticazione di questo tipo di modulo. Rivestono un ruolo importante solo se nessun modulo dello stesso tipo ha superato o non ha superato la verifica. In tal caso, il superamento o il fallimento della verifica di un modulo con opzione optional determina l'autenticazione di tutti i moduli dello stesso tipo.
Adesso è disponibile una nuova sintassi di controllo ancora più efficace per PAM. Per maggiori informazioni, consultate la documentazione su PAM contenuta in /usr/share/doc/pam—<numero versione>.
Percorsi dei moduli PAM
I percorsi dei moduli indicano a PAM dove trovare il modulo inseribile da usare con il tipo di modulo specificato. Solitamente viene fornito l'intero percorso al modulo, quale /lib/security/pam_stack.so. Tuttavia, se non viene indicato tutto il percorso (in altre parole, se il percorso non inizia con /), allora si suppone che il modulo indicato si trovi in /lib/security, la posizione di default dei moduli PAM.
Argomenti PAM
PAM utilizza degli argomenti per passare informazioni a un modulo inseribile durante l'autenticazione di un tipo particolare di modulo. Tali argomenti permettono ai file di configurazione PAM di usare un modulo PAM comune ma in modi differenti per un programma particolare.
Per esempio il modulo pam_userdb.so utilizza dei file nascosti del Berkeley DB per autenticare l'utente. (Il Berkeley DB è un database open source concepito per essere incorporato in varie applicazioni al fine di seguire determinati tipi di informazioni). Il modulo prende un argomento db, specificando il file Berkeley DB da usare, che può variare in funzione del servizio.
La linea pam_userdb.so in un file di configurazione PAM è simile a:
auth required /lib/security/pam_userdb.so db=path/to/file |
Gli argomenti non validi vengono ignorati e non influenzano il superamento né il fallimento del modulo PAM. Quando viene passato un argomento non valido, viene solitamente inviato un errore a /var/log/messages. Tuttavia, poiché il metodo di reporting è controllato dal modulo PAM, è compito del modulo rilevare l'errore.
Esempi di file di configurazione PAM
Un file di configurazione PAM di esempio è simile a:
#%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_unix.so shadow nullok auth required /lib/security/pam_nologin.so account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow nullok use_authtok session required /lib/security/pam_unix.so |
La prima riga è un commento (tutte le righe che iniziano con # sono un commento). Le righe da due a quattro contengono tre moduli da usare per l'autenticazione della login.
auth required /lib/security/pam_securetty.so |
La seconda riga si assicura che se l'utente sta provando a collegarsi come root, la tty su cui sta provando a collegarsi è elencata nel file /etc/securetty, se tale file esiste.
auth required /lib/security/pam_unix.so shadow nullok |
La terza riga chiede all'utente una password e controlla tale password.
auth required /lib/security/pam_nologin.so |
La quarta riga controlla se il file /etc/nologin esiste. Se /etc/nologin esiste e l'utente non è root, l'autenticazione non va a buon fine.
Tutti e tre i moduli auth vengono controllati, anche se il primo modulo auth non supera la verifica. Questa strategia impedisce all'utente di sapere perché l'autenticazione non è permessa. Se fosse al corrente del motivo, l'utente riuscirebbe a infrangere l'autenticazione. Potete modificare questo comportamento sostituendo required con requisite. Se uno dei moduli requisite non supera la verifica, PAM non va a buon fine e non chiama altri moduli.
account required /lib/security/pam_unix.so |
La quinta riga effettua, se necessario, una verifica dell'account. Per esempio se le password shadow sono state attivate, il modulo pam_unix.so verifica se l'account è scaduto o se l'utente non ha modificato la password nel periodo stabilito.
password required /lib/security/pam_cracklib.so |
La sesta riga controlla se una password appena modificata può essere indovinata da un programma illegale per la ricostruzione delle password.
password required /lib/security/pam_unix.so shadow nullok use_authtok |
La settima riga specifica che se il programma login cambia la password dell'utente, dovrebbe utilizzare il modulo pam_unix.so per farlo. (Succede solo se un modulo auth ha stabilito che la password deve essere cambiata — per esempio se una password shadow è scaduta.)
session required /lib/security/pam_unix.so |
L'ottava e ultima riga specifica che il modulo pam_unix.so viene usato per gestire la sessione. Attualmente questo modulo non compie nessuna operazione, e può essere sostituito con qualsiasi modulo necessario.
L'ordine delle righe all'interno del file è importante. Sebbene non sia fondamentale in che ordine sono chiamati i moduli required, esistono altre opzioni di controllo. Mentre optional è usato raramente, sufficient e requisite rendono importante l'ordine con cui sono inserirti.
Diamo un'occhiata alla configurazione auth per rlogin:
#%PAM-1.0 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 |
Per prima cosa, pam_nologin.so verifica se /etc/nologin esiste. In caso positivo, può collegarsi solo root.
auth required /lib/security/pam_securetty.so |
In secondo luogo, pam_securetty.so evita gli accessi di root su terminali insicuri. Se volete che siano accettati (in tal caso vi raccomandiamo di non essere connessi a Internet o dietro un firewall), consultate la la sezione Utilizzo di rlogin, rsh e rexec con PAM.
auth required /lib/security/pam_env.so |
In terzo luogo, il modulo pam_env.so carica le variabili di ambiente specificate in /etc/security/pam_env.conf.
auth sufficient /lib/security/pam_rhosts_auth.so |
Poi, se pam_rhosts_auth.so autentica l'utente usando .rhosts nella sua directory home, PAM attiva subito rlogin senza attuare nessun controllo della password tramite pam_stack.so. Se pam_rhosts_auth.so non riesce ad autenticare l'utente, l'autenticazione fallita viene ignorata.
auth required /lib/security/pam_stack.so service=system-auth |
Infine, se pam_rhosts_auth.so non è riuscito ad autenticare l'utente, il modulo pam_stack.so esegue una normale autenticazione della password e riceve l'argomento service=system-auth.
 | Nota Bene |
|---|---|
Se non volete che venga visualizzato il prompt per inserire la password quando securetty fallisce e determina che l'utente sta provando a collegarsi come root in modo remoto, potete cambiare il modulo pam_securetty.so da required a requisite. Altrimenti, se volete autorizzare i collegamenti root remoti (ve lo sconsigliamo), potete commentare questa riga. |