Moduli PAM personalizzati e considerazioni sulla sicurezza

Sto scrivendo il mio modulo PAM che farà parte di un'applicazione che sto sviluppando, ma non sono sicuro di dove metterlo. Il mio modulo fondamentalmente fa l'autenticazione a livello di rete (con altri mojo ovviamente) simile a LDAP.

Ci sono molti file di configurazione nella mia /etc/pam.d/directory e so cosa fanno la maggior parte dei servizi (tranne un paio, come atd, polkit, ppp). Presumo che l'autenticazione con stack PAM vada in questo modo:

1. Esegue lo stack in base al nome del servizio (se esiste un file di configurazione)
2. Se non autenticato, ripeti su common- *, dove * è il tipo di modulo (auth, account, ecc.)
3. Restituisce il successo o non riesce a chiamare l'applicazione (e ovviamente qualsiasi altro dato)

Sono corretto in questo presupposto? Tutte le piattaforme hanno common-auth, common-account, common-password e common-session?

In tal caso, stavo pensando di metterlo in cima a common- * come sufficientmodulo in modo che in caso di errore lo stack PAM normale rimanga inalterato. Ciò è particolarmente vantaggioso perché posso farlo a livello di codice sull'installazione del software.

Mi mancano potenziali vulnerabilità della sicurezza?

Non sono riuscito a trovare un'ottima documentazione su dove integrare i moduli PAM personalizzati o problemi di sicurezza che circondano i moduli.

Quando si chiama Linux-PAM per una procedura di autenticazione, viene sempre eseguito uno e un solo stack.

La definizione dello stack viene cercata in questi punti; il primo tentativo riuscito determina quale file viene letto:

1. il file che /etc/pam.dprende il nome dall'applicazione "nome servizio" (ad esempio, sshdoppure gdm), oppure

2. il file /etc/pam.d/otherse non esiste un file specifico del servizio o

3. il file /etc/pam.confse la directory /etc/pam.dnon esiste.

Per i dettagli, consultare la documentazione della funzione pam_start .

I file comuni * sono una convenzione seguita da molte distribuzioni Linux ma non sono obbligatori dal software PAM stesso. Di solito sono inclusi in altri file PAM mediante @include istruzioni; ad esempio il /etc/pam.d/otherfile su Debian ha il seguente contenuto:

# We fall back to the system default in /etc/pam.d/common-*
@include common-auth
@include common-account
@include common-password
@include common-session

Le stesse @includeistruzioni possono essere usate anche da file specifici del servizio e, per questo, si trovano nella configurazione predefinita su Debian. Nota che questa è una questione di configurazione: un amministratore di sistema è libero di modificare il file per /etc/pam.dnon includere alcun file comune *!

Pertanto: se il modulo PAM è specifico dell'applicazione, creare un file di servizio specifico dell'applicazione e chiamare il modulo da lì. Do Non aggiungere automaticamente un modulo in un file PAM altri servizi né al ripiego othersdi file, in quanto ciò potrebbe interrompere altre applicazioni installate sul sistema. La gestione dello stack del software PAM è un'attività per l'amministratore di sistema, non per gli sviluppatori di applicazioni.