SASL (Simple Authentication Security Layer)

Usare SASL per autenticare le connessioni ad un server SMTP è solo uno dei possibili metodi utilizzabili. Personalmente, fino a quando gli utenti sono in numero ristretto, preferirei usare TLS sul lato client per certificare le connessioni al server.

Quanto segue non vuole essere niente altro che una piccola raccolta di osservazioni per me stesso, principalmente per evitare di commettere nuovamente gli stessi errori e riscoprire per l'ennesima volta l'acqua calda anche se probabilmente dovrei arrendermi e comperare un libro su SASL che spieghi tutto a piccoli passi. Conseguenza diretta di questo fatto è l'aspetto di brogliaccio di tutto quello che segue.

Qualche appunto

Alcuni appunti sparsi basati sulla versione 2.1.21 del pacchetto cyrus-sasl:

• la procedura di installazione a partire dai sorgenti non è completa: mancano alcune cose, come, per esempio, la pagina di manuale di saslauthd;
• l'esecuzione "semplice" di configure porta alla creazione di pochissime librerie:

  libsasl2.so.2.0.21
  sasl2/libanonymous.so.2.0.21
  sasl2/libcrammd5.so.2.0.21
  sasl2/libdigestmd5.so.2.0.21
  sasl2/libotp.so.2.0.21
  sasl2/libplain.so.2.0.21
  sasl2/libsasldb.so.2.0.21
  

  quindi è necessario specificare gli eventuali altri backend che si vogliono usare (esempi: --enable-sql, --enable-ldapdb oppure --enable-krb4) ed i meccanismi di autenticazione che si desiderano (--enable-ntlm, --disable-plain, etc); mi chiedo perché le versioni di queste librerie siano tutte sballate rispetto alla versione di release del pacchetto...
• è necessario scrivere un file di configurazione per ogni applicazione che userà la libreria; il file deve trovarsi in /usr/lib/sasl2/ e chiamarsi <applicazione>.conf dove <applicazione> non è necessariamente il vero nome dell'applicazione che userà il file (per esempio, per Postfix il file deve chiamarsi smtpd.conf (anche se è configurabile tramite il parametro smtpd_sasl_application_name in main.cf), mentre per Exim deve chiamarsi smtp.conf (anche se è configurabile tramite il parametro server_service));
• da notare che la versione di Exim fornita da Debian Woody sembra non avere la possibilità di usare SASL (ma, oramai, tutto questo non ha più molta importanza);
• per poter usare contemporaneamente più di un mezzo di controllo, è sufficiente indicare più di un metodo come valore della proprietà pwcheck_method;
• per poter controllare le password di /etc/shadow è necessario usare saslauthd con l'opzione -a shadow (oppure è meglio usare -a pam?);
• per poter controllare le password di un db è necessario usare il metodo auxprop ed aver compilato il plugin adatto; all'atto del controllo, auxprop interrogherà, nell'ordine, i plugin elencati come valori della proprietà auxprop_plugin oppure tutti i plugin presenti nel sistema se questa proprietà non è impostata;
• con mech_list è possibile specificare l'elenco di meccanismi di autenticazione che saranno "presentati" (PLAIN, CRAM-MD5, etc); di default, la lista è vuota e vengono offerti tutti i meccanismi presenti nel sistema;
• per configurare la verifica delle password di un db, sono disponibili molte proprietà: sql_engine (indica il nome del motore del db: mysql, pgsql oppure sqlite), sql_hostnames, sql_user, sql_password, sql_database, sql_select (la query che tenterà di recuperare le informazioni per autenticare la connessione), sql_insert (questa proprietà e la seguente sono utilizzate solo nei casi in cui si vuole permettere alla libreria od ai plugin di aggiornare le informazioni nel db), sql_update, sql_usessl.

Le query sql possono usare i seguenti parametri, che vengono sostituiti con i valori appropriati al momento dell'esecuzione della query:

• %u: il nome utente;
• %p: il nome della proprietà cercata/aggiornata (userPassword oppure cmusaslsecretMECHNAME (dove MECHNAME è il nome di uno dei meccanismi di SASL));
• %r: il reame a cui appartiene l'utente (un reame kerberos, il fqdn dell'applicazione oppure ciò che segue @);
• %v: il valore della proprietà inserita od aggiornata.

Un esempio

Stupido esempio, probabilmente non funzionante e sicuramente con problemi di permessi e chissà che altro, vagamente basato su quanto viene usato ora da chi so io:

pwcheck_method: saslauthd auxprop
auxprop_plugin: sql
sql_engine: pgsql
sql_hostnames: localhost
sql_user: mail
sql_password: XXXX
sql_database: mail
sql_select: select clear from password where login = '%u'

Nelle migliori intenzioni, quanto sopra dovrebbe funzionare in questo modo:

1. l'applicazione dovrebbe chiedere a saslauthd (eseguito con l'opzione -a shadow (oppure con -a pam?) di controllare la password dell'utente in /etc/shadow;
2. in seconda battuta si dovrebbe passare a richiedere l'autenticazione tramite auxprop che dovrebbe usare esclusivamente il plugin sql;
3. il motore da usare, l'hostname, il db, l'utente e la password per accedere al db dovrebbero essere indicate dalle proprietà omonime;
4. la select dovrebbe recuperare la password dal campo clear dalla tabella password dove login contiene il nome dell'utente seguito da @ e dal dominio; il fatto che l'utente sia costretto ad inviare come login l'indirizzo e-mail completo comporterà che %u verrà sostituito con l'indirizzo completo? Oppure sarà necessario sostituire %u con %u@%r?

Una considerazione estemporanea: se un utente "reale" del sistema ha la password disabilitata (come risultato di passwd -l <utente>), l'autenticazione fallirà sempre. Di conseguenza, saltando di palo in frasca alla configurazione di sshd, per obbligare tutti ad usare le chiavi dsa/rsa per autenticarsi si dovrebbe impostare PasswordAuthentication al valore no in /etc/ssh/sshd_config.

Ultima modifica: Mon Jul 18 10:19:13 CEST 2005