Autenticazione utente Linux corretta tramite applicazioni PAM aware

Mentre esci, a causa del limite di / etc / shadow access, a un certo livello, l'applicazione dovrà accedere a quel file o accedere ad altri moduli / servizi che hanno accesso a quel file. Non c'è modo di evitarlo se si desidera una soluzione che utilizzi le credenziali dell'utente gestite localmente (a meno che non ne possiate fare da soli, cosa che consiglio vivamente di evitare).

Penso che il tuo approccio migliore sia separare il componente di autenticazione. Oltre ad avere il vantaggio di limitare la superficie di esposizione, ha un altro grande vantaggio non ancora menzionato. Dal tuo post, sembra che questo software verrà eseguito su siti client, alcuni dei quali potrebbero avere LDAP, alcuni dei quali no. Se il tuo componente di autenticazione è modularizzato / separato dal nucleo della tua applicazione, hai la possibilità di ottenere il meglio da entrambi i mondi. Fondamentalmente, il tuo sito client può utilizzare il metodo che si adatta meglio alla loro architettura.

Mantenere l'ambiente il più diretto e coerente possibile è importante quasi quanto l'utilizzo della giusta tecnologia. Molti problemi di sicurezza sorgono perché l'ambiente o l'architettura sono troppo complicati. Le modifiche vengono apportate da qualcuno che non comprende appieno tutte le implicazioni e la prossima cosa che sai è che hai un grosso buco nella sicurezza.

Se si scrive l'applicazione in modo tale da poter trasmettere l'autenticazione a un modulo esterno, è possibile consentire ai siti di selezionare ciò che si adatta meglio per loro. Evitano di dover gestire un'altra fonte di identità, possono garantire la coerenza attraverso il loro ambiente e possibilmente ottenere ulteriori vantaggi, come il single sign-on o lo stesso accesso ecc. È possibile fornire un modulo di autenticazione "predefinito" che utilizza PAM per tali siti che non hanno LDAP o simili.

La sfida con questo approccio è nella selezione o definizione dell'interfaccia. Come dovrebbe avvenire la comunicazione? Lo terrei semplice Possibilmente socket di dominio, ma forse altri standard, come SAML 2.0, potrebbero valerne la pena.

Potresti anche essere interessato in questo articolo, che parla dell'utilizzo di PAM per controllare l'accesso al servizio

link

Inoltre, a seconda della piattaforma di distribuzione - redhat o debian based, dovresti controllare SELinux e AppArmor per modi di limitare potenziali problemi, come limitare ciò che resoruce un eseguibile è autorizzato ad accedere ecc.

Un'altra possibilità sarebbe quella di eseguire (parte) il tuo programma come root all'interno di un ambiente virtuale. I contenitori Linux (lxc) rendono questo leggero.

Considera che qualsiasi cosa possa fare la tua applicazione, un aggressore può fare se la tua applicazione è compromessa. Pertanto, non si dovrebbe consentire (la maggior parte) della propria applicazione di esporre nomi di utenti validi o effettuare verifiche di password a un tasso illimitato, e tanto meno cambiare le password. Quindi la separazione dei privilegi in qualche modo è la strada da percorrere.

La mia preferenza è per LDAP perché è un protocollo ben noto e ampiamente supportato e separa intrinsecamente il database utente dall'applicazione. Puoi lasciare che il server LDAP si preoccupi di mantenere le password sicure e di fare verifiche correttamente, ma anche di cose come la limitazione della velocità, sebbene la tua applicazione possa partecipare alla limitazione della velocità se dispone di conoscenze aggiuntive sulla provenienza dei tentativi di autenticazione. È anche più probabile che LDAP sia adattabile all'autenticazione federata, se desideri aggiungere questa funzione.

Il fatto che le distribuzioni non abbiano LDAP disponibile non è un ostacolo. Includi un server LDAP open source di tua scelta ed eseguilo su una porta personalizzata e ascoltando solo su localhost.

Sebbene una risposta sia stata accettata qui, non penso che sia una buona risposta.

Creating a group with read access to the /etc/shadow...

No. Molto tempo fa, qualcuno ha avuto la meravigliosa idea che il sistema operativo dovrebbe autenticare gli utenti, non i programmi - anche dove l'utente non ha già una sessione, e ha avuto l'idea di PAM. Con PAM il meccanismo con cui avviene l'autenticazione non è la preoccupazione dell'applicazione che cerca di autenticare l'utente.

slightly insane from a security point of view to run the daemon as root

L'esecuzione tuttavia semplifica enormemente il processo di autenticazione e di modifica all'uid autenticato. Se quest'ultimo non è un requisito, puoi prendere in considerazione l'idea di invocare il passo di autenticazione tramite sudo / uno script setuid (un esempio molto semplice incluso con squid) o anche come demone secondario.

Ci sono molti modi per testare un utente e una password - l'uso di su (o ssh) ha la complicazione necessaria per implementare la comunicazione bidirezionale con un nuovo processo, più o meno come fa "aspetta". Potrebbe essere molto più semplice testare il nome utente / password contro una casella di posta POP se si è contrari ad implementare l'autenticazione da soli.

Potrebbe esserci un modo per cambiare uid quando non sei root - ma probabilmente è una nuova domanda.