Impedire a NetworkManager di mostrare una password VPN salvata
Chiederla ogni volta, affidarla a un portachiavi o tenere un file accessibile solo a root. Ogni scelta comporta un’esposizione diversa, e il flag della password deve corrispondervi.
NetworkManager può conservare una password VPN così che la connessione si alzi senza che nessuno la digiti, e può mostrare di nuovo quel valore tramite l’editor o tramite nmcli --show-secrets. Sono disponibili tre modelli di proprietà, e il comportamento di visualizzazione è solo un sintomo di quello che avete scelto. Scegliete prima il modello, poi impostate il flag che gli corrisponde, invece di nascondere un campo con un segnaposto che confonderà la persona successiva.
Tre modelli di proprietà
Il primo modello chiede ogni volta. Niente viene memorizzato, il segreto esiste solo per la durata dell’attivazione, e chiunque avvii la connessione deve conoscere la password. È l’opzione meno comoda e la più facile da difendere.
Il secondo consegna il segreto a un portachiavi di proprietà dell’utente. L’agente si sblocca all’inizio della sessione e fornisce il valore su richiesta, il che lo tiene fuori dal file di connessione ma lega la connessione alla sessione di quell’utente. Ne derivano due condizioni: l’agente deve essere in esecuzione e deve essere sbloccato.
Il terzo memorizza una credenziale protetta per una connessione di sistema. Sopravvive ai riavvii e funziona prima che qualcuno acceda, e in cambio il valore risiede sul disco protetto dai permessi del file e non dalla crittografia.
Ogni modello è ragionevole nel contesto giusto. L’errore è mescolarli, ed è così che un portatile finisce con un segreto in due posti e senza una risposta chiara su quale sia quello autorevole. Annotate quale modello usa un profilo. Una riga nel manuale del team risparmia alla persona successiva di inventare un quarto posto dove guardare.
Leggete lo stato attuale prima di cambiarlo
Guardate il profilo e lo stato del segreto come utente che gestisce la connessione. Il secondo comando è quello che vi dice se il valore è davvero leggibile.
nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnection
Un file di chiave in quella directory di solito appartiene a root con modo 600. Questo tiene fuori gli utenti ordinari e non tiene fuori root, cosa che conta quando la stessa macchina è condivisa o quando un backup viene eseguito come root.
I permessi del file sono un confine, non una crittografia. Chi può leggere il file come root ha la password in chiaro. È uno scambio accettabile per un server senza sorveglianza e pessimo per una postazione condivisa. Scriverlo una volta evita una lunga discussione sul fatto che il valore sia protetto.
Che cosa fa ogni valore del flag
Il segreto VPN porta una proprietà flags, e i valori non sono intuibili solo dai numeri.
| Value | Meaning | Practical effect |
|---|---|---|
| 0 | No special flag | Secret is typically saved with the connection |
| 1 | Agent-owned | A keyring or secret agent supplies it |
| 2 | Not saved | Prompted at each activation |
| 4 | Not required | Connection proceeds without asking |
Il comportamento effettivo dipende anche dal plugin e dal fatto che un agente sia in esecuzione, quindi trattate la tabella come il contratto e il comportamento osservato come ciò che verificate. Un valore che funziona su un desktop può comportarsi diversamente su un server senza sessione. In questo divario vivono la maggior parte dei ticket confusi.
Impostate la proprietà esplicitamente invece di cancellare una riga e sperare. Un flag assente non è una politica, e il prossimo aggiornamento del pacchetto può riempirlo con qualcosa che non intendevate.
Fate corrispondere il modello a quando la connessione parte
Se la connessione parte solo mentre un utente è connesso, la proprietà dell’agente si adatta bene e tiene il segreto fuori dal file. Se parte all’avvio, prima che esista una sessione, un agente non può aiutarvi.
Questa è tutta la decisione per la maggior parte delle macchine. Spiega anche una classe di rapporti confusi in cui la connessione funziona in modo interattivo e fallisce dopo un riavvio. Il flag non è mai cambiato; è cambiato il contesto.
Per il caso senza sorveglianza, la risposta pratica è un file limitato di proprietà di root o una fonte di credenziali approvata. Tenetelo fuori dal profilo di connessione se quel profilo viene mai esportato o copiato su un’altra macchina.
Se il valore era già visibile, cambiatelo
Modificare un flag lascia intatta la password stessa. Un valore emerso in uno screenshot, nella cronologia della shell, in un pacchetto inviato all’assistenza o in un file che altri utenti potevano aprire va considerato divulgato.
Cambiatelo sul server, poi correggete il client e terminate ogni sessione che si è autenticata con quello vecchio. Eliminare la connessione locale non revoca nulla dall’altra parte, ed è la parte che le persone trascurano.
Poi smettete di mettere la password sulla riga di comando. Finisce nella cronologia della shell e può comparire in un elenco dei processi; usate invece il prompt interattivo o l’agente.
Verificate riconnettendovi
Ripetete il comando che ha mostrato il segreto e confermate che il campo non viene più stampato. Poi disconnettete e riconnettete, e riavviate se la connessione parte automaticamente, perché il guasto interessante compare solo quando cambia il contesto della sessione.
Se il segreto compare ancora, lo fornisce un altro profilo o un altro agente. Ispezionate la connessione attiva e il portachiavi invece di eliminare file finché il sintomo non si sposta.