OpenVPN stampa all’avvio un avviso che suggerisce auth-nocache, e la risposta tentante è aggiungere l’opzione e guardare la riga sparire. Quel consiglio presuppone un accesso interattivo. Quando nome utente e password vivono in un file, il confronto cambia: l’opzione smette di proteggere la copia duratura e, su un client che rinuncia ai privilegi, può rompere la rinegoziazione più tardi. Vale la pena tenere separati due modelli di archiviazione prima di modificare un profilo.

Due modi per rispondere alla richiesta di credenziali

Il primo modello è una persona che digita le credenziali in un terminale, o un’interfaccia di gestione che le tiene per la sessione. OpenVPN conserva quella copia per poter rispondere alla rinegoziazione successiva senza chiedere di nuovo, ed è esattamente di questo che parla l’avviso. Niente sul disco è coinvolto, quindi l’unica cosa da proteggere è il processo che detiene il valore. Chiudi il client e la copia sparisce con lui.

Il secondo modello è auth-user-pass che punta a un file, dove il file è il deposito e il client lo legge quando serve un valore. L’esposizione che conta qui non è la memoria del processo ma i permessi e la proprietà di quel file. L’avviso di avvio viene dalle direttive della configurazione, non da un’ispezione di come fornisci la password, quindi compare in entrambi i modelli e non punta a nessuno dei due.

Il resto di questo confronto discende da quella separazione: gestione della memoria per un modello, gestione del file e identità del processo per l’altro.

Che cosa scarta davvero auth-nocache

Con un accesso interattivo, --auth-nocache rimuove la copia memorizzata dalla memoria dopo che è stata usata. Il costo è una nuova richiesta a ogni intervallo di rinegoziazione, perché il giro successivo non può riusare ciò che è stato scartato.

Con un accesso basato su file il client può rileggere il file, quindi lo scarto è per lo più invisibile. Diventa visibile nell’unico punto in cui le persone non se lo aspettano: dopo che il demone rinuncia ai privilegi, se il file delle credenziali non è leggibile dall’account con cui ora gira.

Aggiungi l’opzione perché capisci questo scambio, non perché è comparso un avviso. Un’opzione aggiunta per rendere un log più silenzioso è un’opzione di cui nessuno ha misurato l’effetto.

Dove si rompe il percorso basato su file

Un client che parte come root per aprire il dispositivo tunnel e poi passa a user e group legge il file delle credenziali due volte: una prima del passaggio, una alla rinegoziazione che segue. Se il file è in modalità 600 ed è di root, la seconda lettura fallisce, e il guasto emerge un’ora dopo come errore di autenticazione che sembra un problema del server. Controlla il log del client intorno all’intervallo di rinegoziazione, poi controlla account e file insieme.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Entrambe le righe contano. La prima ti dice chi può leggere il file, la seconda ti dice chi è davvero il demone in esecuzione, e una discrepanza tra le due spiega un guasto che nessuna riscrittura della password riparerà.

Le correzioni pratiche non sono glamour: sposta il file in una directory e a un proprietario che l’account del demone può leggere, oppure mantieni la lettura privilegiata e conferma che il tuo client legga una sola volta. Non risolverlo rendendo il file leggibile a tutti.

Il caso che l’opzione la vuole davvero

Un accesso che porta un codice monouso vuole auth-nocache per un’altra ragione. Un codice monouso viene consumato dalla prima autenticazione, quindi una copia in cache è inutile alla rinegoziazione successiva e un valore scaduto potrebbe persino essere rigiocato.

È una questione sul tipo di credenziale, non su dove viene conservata. Una password statica in un file protetto ha il profilo opposto: deve essere leggibile a ogni rinegoziazione, e la protezione che serve sta sul file.

Tieni separate queste due ragioni nei commenti del profilo, altrimenti il prossimo amministratore assumerà che l’opzione sia lì per la ragione che avrebbe scelto lui.

Il confronto in una decisione

Scegli il modello interattivo quando c’è una persona e la freschezza conta, e accetta la richiesta ripetuta come suo costo. Scegli il modello file quando il client gira senza sorveglianza, e investi lo sforzo su proprietà, modalità e rinuncia ai privilegi.

Nessuno dei due modelli rende sicura una password memorizzata da solo, e nessuno rende significativo l’avviso di avvio.

Se l’avviso è l’unica ragione per cui hai aperto il profilo, annota la decisione invece di un’opzione inspiegata: le credenziali vengono da un file leggibile dall’account del demone, una rinegoziazione è stata vista riuscire, e la sezione sulla rinegoziazione del manuale OpenVPN 2.6 è stata letta prima di cambiarne l’intervallo. Quella nota sopravvive a qualunque singolo flag.

Articoli correlati