In un articolo precedente, ho descritto il flusso di un'applicazione che chiama le librerie PAM per l'autenticazione a un livello molto alto. In questo articolo, analizzeremo i file di configurazione per un sudo locale comando.
Quando si utilizza sudo , cambiamo utente e facciamo qualcosa. Questo cambio di privilegio richiede la verifica che siamo chi diciamo di essere e siamo autorizzati a eseguire l'azione data. Il /etc/sudoers il file controlla chi può fare cosa, ma il processo chiama comunque PAM per eventuali controlli di autenticazione. Come parte di queste chiamate, il processo si identifica e quindi libpam cerca un file di configurazione corrispondente in /etc/pam.d directory.
$ cat /etc/pam.d/sudo
#%PAM-1.0
#Type ReturnCode Modules Options
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Come molte altre directory *.d, la gestione dei pacchetti può aggiungere o rimuovere un file da questa directory. Il sudo RPM aggiunge il /etc/pam.d/sudo file.
$ rpm -qf /etc/pam.d/sudo
sudo-1.9.0-0.1.b4.fc31.x86_64
Una versione upstream potrebbe avere una varietà di voci, ma questo pacchetto fornito dalla distribuzione include un file di configurazione che ha diversi include istruzioni al comune /etc/pam.d/system-auth file fornito da pam pacchetto.
Campi del file di configurazione
Il primo campo di questo file identifica un Tipo di chiamata effettuata verso PAM. Le righe dello stesso tipo sono raggruppate. Esistono quattro tipi:autenticazione, account, password e sessione. Guarda man pam per una descrizione di ogni tipo.
Il secondo campo è noto come ReturnCode . Questo campo consente a PAM di sapere come gestire i risultati del test del modulo. I codici di ritorno indicano se un test è obbligatorio o facoltativo. I codici possono anche essere usati per indicare che la riga non è un test del modulo con opzioni ma piuttosto il nome di un altro file di configurazione con controlli aggiuntivi. Una descrizione completa dei codici di ritorno si trova in man pam.conf e quelli più comuni sono discussi più avanti in questo articolo.
Il resto della riga contiene il nome del modulo e le opzioni per quel modulo. Il nome del modulo deve corrispondere a un modulo disponibile in /etc/lib64/security directory. Le opzioni possono variare a seconda del tipo di chiamata effettuata. Alcuni moduli eseguono test solo per alcuni tipi di chiamate. Usa la pagina man di ogni modulo per vedere esempi e conoscere gli usi e le opzioni disponibili.
L'ordine delle voci all'interno di un tipo di chiamata è importante. Ciò è dovuto principalmente al modo in cui vengono elaborati i codici di ritorno, ma in alcuni casi a un'azione del modulo. Quando libpam riceve un messaggio "fatto" o "morire", riporta il risultato complessivo al processo di chiamata.
La configurazione per sudo ha diversi include Linee. Queste righe dicono a libpam per includere tutte le righe di un determinato tipo dal file di configurazione specificato. C'è anche un sottostack opzione, che è simile nel modo in cui include le righe da un determinato file di configurazione, ma su un "fatto" o "morire", riporta al sottostack istruzione invece del processo originale che chiama libpam . Le versioni precedenti di PAM avevano altre variazioni su come venivano inclusi altri file di configurazione. Ad esempio, quando ho iniziato a esplorare PAM quasi 20 anni fa, c'era un modulo specifico chiamato con i file di configurazione come argomento. La parola chiave "include" non era valida per il Codice di ritorno campo.
Codici di ritorno nei file di configurazione centrale
Il /etc/pam.d/sudo il file mostrato in precedenza è piuttosto breve. Tre dei quattro tipi di chiamata hanno solo un include di un altro file. Il /etc/pam.d/system-auth è più tipico di un file di configurazione, con molti controlli per ogni tipo di chiamata.
$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
...omitted... Il richiesto la parola chiave è forse la più comune. Indica che il modulo deve superare il controllo per restituire un pass complessivo all'applicazione. Tuttavia, anche in caso di errore, le seguenti righe di quel tipo verranno comunque controllate. Questa è una pratica di lunga data di non condividere alcun motivo per un errore di autenticazione. Sui sistemi di 20 anni fa, sarebbe stato possibile indovinare come l'autenticazione non è riuscita in base al tempo impiegato per fallire.
Il requisito la parola chiave è simile a richiesto in quanto il controllo deve passare, ma in caso di fallimento restituisce un messaggio di "morire". Requisito consente libpam sapere che le seguenti righe non verranno controllate e informare il processo di chiamata dei risultati complessivi, in questo caso un errore.
Il sufficiente parola chiave è quasi l'opposto di requisito . In caso di successo, viene restituito un messaggio "done" e libpam va avanti e invia i risultati complessivi all'applicazione chiamante. Gli altri risultati di questo modulo vengono ignorati e il controllo continua.
Il sufficiente parola chiave è comune quando potrebbero esserci più modi per verificare un criterio. Ad esempio, durante la verifica di una password, l'utente potrebbe essere definito nel /etc/passwd locale e /etc/shadow file, oppure potrebbero essere definiti solo in un sistema centrale a cui si accede con sssd . Il pam_unix modulo controlla i file locali. Se c'è successo, non c'è bisogno di continuare e controllare i servizi centralizzati. Tuttavia, se l'utente non è definito localmente, non vogliamo registrare un errore, vogliamo ignorare il risultato e provare il pam_sss modulo. Dal momento che il sufficiente la parola chiave non fallisce mai veramente, è comune aggiungere un pam_deny richiesto riga dopo una serie di sufficienti Linee. Il pam_deny il modulo fallisce sempre in modo molto simile a /bin/false eseguibile.
Il opzionale la parola chiave è simile a sufficiente in quanto ignora eventuali fallimenti. Tuttavia, in caso di successo, si comporta più come il richiesto parola chiave impostando un valore "ok" e continuando a eseguire eventuali controlli aggiuntivi.
Poiché entrambi i requisiti e sufficiente possono essere punti di uscita dalla pila di moduli, l'ordine nel file di configurazione è importante. Le righe dopo quelle parole chiave possono essere eseguite o meno.
Codici di reso complessi
Oltre alla semplice sintassi delle parole chiave, i codici di ritorno complessi sono definiti con coppie chiave-valore all'interno di parentesi quadre. Il /etc/pam.d/system-auth il file ha un esempio nella sezione della sessione della sintassi più complessa.
$ cat /etc/pam.d/system-auth
...omitted...
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
Puoi trovare la sintassi complessa che corrisponde a ciascuna parola chiave nel pam.conf pagina man. Il - mostrato sopra è anche definito nella pagina man. Indica che la registrazione può essere saltata se il modulo non è installato sul sistema.
Cosa c'è dopo?
Ora che possiamo esaminare quando si verifica una chiamata e un'uscita con libpam , il passaggio successivo consiste nel comprendere meglio il caso d'uso per ciascun modulo. La maggior parte dei moduli ha una pagina man che spiega l'uso e mostra esempi di righe che dovrebbero apparire nel pam.d file di configurazione. Alcuni dei moduli fanno anche riferimento a file supplementari in /etc/security directory. Quei file sono ben commentati e spesso hanno anche la loro pagina man. Il pam_pwquality e pam_limits i moduli sono buoni esempi con cui iniziare.
Concludi
Nel prossimo articolo, illustrerò alcune delle modifiche apportate utilizzando authconfig utilità. Se vuoi passare direttamente alla modifica dei file e disponi di un abbonamento Red Hat Learning, dai un'occhiata al capitolo su PAM nel corso Red Hat Security:Linux in Physical, Virtual, and Cloud (RH415).
[ Corso online gratuito:panoramica tecnica di Red Hat Enterprise Linux. ]