Il pulsante VPN richiede sudo: limita la regola, convalida la policy

Il pulsante VPN funziona per l’amministratore e fallisce per tutti gli altri, così qualcuno aggiunge una riga a sudoers. Quella riga di solito sopravvive al problema che doveva risolvere, e spesso concede più di quanto il pulsante richieda. Prima di modificare la policy, verifica se il proprietario supportato della connessione può già svolgere il lavoro. Le tre condizioni seguenti decidono se sudo è coinvolto.

Condizione 1: il proprietario supportato può farlo senza sudo

Sulla maggior parte dei desktop Linux il gestore di rete possiede già le connessioni VPN, e la sua autorizzazione passa per polkit invece che per sudo. Un utente autorizzato ad attivare una connessione può farlo da riga di comando senza alcuna regola root. Verifica cosa consente il gestore prima di supporre che il pulsante richieda un privilegio. Se la risposta è sì, la modifica a sudoers risolve un problema che non esiste.

nmcli connection show
nmcli connection up "Work VPN"

Se il gestore rifiuta, leggi perché: una regola polkit mancante, una connessione di proprietà di un altro utente o un profilo memorizzato dove l’utente non può leggerlo. Ognuna di queste ha una correzione supportata più ristretta di una regola sudo. L’escalation di privilegi è l’ultima risorsa, non la prima.

Condizione 2: la regola nomina un solo eseguibile e i suoi argomenti

Se sudo è davvero necessario, la regola dovrebbe nominare il comando esatto e, dove possibile, gli argomenti che può usare. Una regola che lascia a un utente eseguire uno script wrapper è sicura solo quanto i permessi di quello script, perché l’utente può modificare ciò che root eseguirà. Una regola con un carattere jolly dopo il comando è lo stesso problema in forma più breve.

sudo -l -U alice
ls -l /usr/local/sbin/vpn-up

Controlla ogni percorso della catena di comando: il binario, lo script che chiama, il file di configurazione che legge e ogni directory intermedia. Se l’utente può scrivere in uno di essi, la regola limitata è in pratica root senza restrizioni. Anche gli argomenti contano, perché un comando che accetta un percorso di configurazione può essere puntato a un file controllato dall’utente. Scrivi la regola per l’operazione, non per il pulsante.

Fermati se il comando richiede un file controllato dall’utente per funzionare. Allora il progetto è sbagliato, e nessuna sintassi di sudoers lo renderà sicuro.

Condizione 3: l’intera policy viene analizzata, non solo la tua riga

Convalida con l’editor che blocca il file e controlla la sintassi, e convalida la policy assemblata invece di un frammento. Un file che si analizza da solo può comunque rompere l’ordine di inclusione o duplicare una regola in modo da cambiare il comportamento.manuale di visudo documenta sia l’editor con blocco sia la modalità di sola verifica usata qui.

sudo visudo -c
sudo visudo -cf /etc/sudoers.d/vpn-launcher

Il controllo segnala il file e la riga quando fallisce, e quel rapporto è la parte utile. Correggi la modifica prevista tramite l’editor invece di forzare il salvataggio di un errore noto, perché una policy rotta può bloccare fuori tutti gli amministratori contemporaneamente. I file nella directory di inclusione hanno bisogno anche della proprietà e del modo richiesti dal manuale, altrimenti vengono ignorati o rifiutati. La sintassi è solo il primo cancello: dopo averlo superato, rileggi la regola e chiediti cosa permette davvero.

Fermati se l’unico modo per far funzionare la modifica è disattivare il controllo della sintassi. Non è una policy, è un’interruzione che aspetta un riavvio.

Recupero: mantieni una sessione che funziona ancora

Prima di salvare, assicurati che una sessione amministrativa autorizzata sia già aperta e che esista un secondo percorso verso la macchina. Un errore in sudoers può toglierti la capacità di correggerlo, e un pulsante sul desktop non vale quel rischio. Se sudo è già rotto, usa il percorso di recupero documentato del sistema invece di improvvisarne uno.

sudo -n true
id

Alternative come pkexec dipendono dalla propria installazione e policy, quindi non sono un secondo prompt root garantito. Tieni anche l’autorizzazione locale separata dalla fornitura del segreto VPN: una regola sudo non può sbloccare un agente di segreti assente e non soddisfa l’MFA del gateway. Dopo la correzione, prova l’account normale eseguendo solo l’operazione prevista, poi usa i controlli abituali del gestore.

La decisione finisce quando sai dire quale condizione ha giustificato sudo, cosa nomina la regola, che l’intera policy viene analizzata e come ti riprenderesti se non fosse così. Un launcher privilegiato che ti costa l’accesso amministrativo è un cattivo affare, ed è di solito evitabile.