sudo-rs su Ubuntu 26.04: cosa cambia in sudoers

Cosa cambia sudo-rs su Ubuntu

Ubuntu 26.04 LTS include sudo-rs come implementazione predefinita di sudo. Di conseguenza, su un server appena installato, il comando sudo sudo esegue la reimplementazione in Rust invece del programma originale in C. La maggior parte dei file sudoers continua a funzionare esattamente come prima. Il problema riguarda le regole che contengono un carattere jolly negli argomenti di un comando, perché sudo-rs non confronta i modelli glob con il testo degli argomenti.

Ubuntu 25.10 ha introdotto per primo questo cambiamento e Ubuntu 26.04 LTS lo ha mantenuto. Ubuntu 24.04 LTS non è interessato, perché continua a usare sudo originale, a meno che non si installi sudo-rs manualmente. Questo diventa importante quando si esegue l'upgrade da Ubuntu 24.04 a 26.04 oppure quando si configura un nuovo server con la release più recente. Se si usano anche le release intermedie, come differiscono le release LTS e intermedie di Ubuntu su un server spiega quale macchina riceve per prima un cambiamento di questo tipo.

Verifica quale implementazione di sudo è effettivamente in esecuzione sul server

Non dedurlo dal numero di versione. Chiedilo alla macchina.

sudo --version
update-alternatives --config sudo
dpkg -l 'sudo*'

Fai riferimento a sudo --version sul tuo server, non a una tabella delle versioni su Internet, inclusa questa pagina. update-alternatives --config sudo è l'altra metà della risposta: elenca tutti i provider installati di /usr/bin/sudo e indica quello selezionato. Un pacchetto installato non è necessariamente selezionato, quindi consulta la selezione, non l'elenco dei pacchetti.

Durante la transizione vengono pacchettizzate entrambe le implementazioni. Quella in Rust è sudo-rs, alla versione 0.2.13 in 26.04 ad agosto 2026. L'implementazione originale, mantenuta da Todd C. Miller, è ancora il pacchetto sudo; ciò che è cambiato è che i relativi programmi usano il suffisso .ws, così entrambe possono essere installate contemporaneamente: /usr/bin/sudo.ws e /usr/bin/visudo.ws, insieme a cvtsudoers.ws e sudoreplay.ws. Verificato sull'archivio 26.04 a settembre 2026: dpkg -L sudo elenca i binari con suffisso e sudo-rs include /usr/bin/sudo-rs accanto a questi.

Perché Ubuntu è passato a sudo-rs

sudo usa setuid root. Qualsiasi utente del sistema può avviarlo e il programma parte con privilegi completi. Di conseguenza, un bug di memoria al suo interno può diventare un exploit locale per ottenere root. CVE-2021-3156 era esattamente questo: un heap buffer overflow raggiungibile da qualsiasi utente locale, presente nel codice distribuito per circa dieci anni. Rust rileva questa categoria di bug in fase di compilazione. Questo è il motivo principale della riscrittura.

Il secondo motivo riguarda l'ambito delle funzionalità, ed è quello che interessa la configurazione. Il sudo originale ha accumulato un ampio insieme di funzionalità in tre decenni. Ogni funzionalità aggiunge altro codice eseguito come root. sudo-rs implementa volutamente solo un sottoinsieme. Gli autori hanno escluso tutto ciò che hanno ritenuto di nicchia o potenzialmente dannoso. Di conseguenza, una direttiva sudoers che ha funzionato per anni può semplicemente non essere disponibile. La regola con caratteri jolly è una di queste.

La sicurezza della memoria elimina una categoria di bug. Non rende il programma privo di bug. sudo-rs ha ricevuto anche correzioni di sicurezza proprie da quando è diventato l'implementazione predefinita. Applicare le patch a sudo-rs come a qualsiasi altro software.

Quali regole sudoers continuano a funzionare

Il file è lo stesso. sudo-rs legge /etc/sudoers e i file drop-in in /etc/sudoers.d/. Sono supportate le configurazioni normalmente usate dagli amministratori di sistema:

• deploy ALL=(ALL:ALL) ALL e le forme per i gruppi, come %sudo ALL=(ALL:ALL) ALL
• i tag NOPASSWD: e PASSWD:
• User_Alias, Runas_Alias, Host_Alias e Cmnd_Alias
• un comando con un elenco esatto di argomenti, ad esempio /usr/bin/systemctl restart app-api
• un comando seguito da "", che consente di eseguire il comando soltanto senza argomenti
• un comando seguito da * come argomento finale, che consente qualsiasi argomento aggiuntivo
• un percorso di directory che termina con /, che consente qualsiasi comando in quella directory
• ! per escludere un comando da un elenco
• un sottoinsieme utile di Defaults, inclusi secure_path, env_keep, env_check, timestamp_timeout, passwd_tries, editor, umask, targetpw, rootpw e use_pty

Due impostazioni predefinite si comportano in modo diverso e possono creare problemi. env_reset non può essere disattivato in sudo-rs: è sempre attivo. use_pty è attivo per impostazione predefinita, quindi il comando viene eseguito nel proprio pseudo-terminale.

Perché la regola wildcard di sudoers ha smesso di corrispondere

I wildcard sono ancora consentiti in un solo punto: il nome file del comando. Una regola con %ops ALL = /sbin/fsck* consente ancora sudo fsck e sudo fsck_exfat, perché * fa parte del percorso confrontato con il filesystem.

All'interno dell'elenco degli argomenti, sudo-rs accetta solo due forme speciali, e nessuna delle due è un pattern. "" indica che non devono essere presenti argomenti. Un * finale indica invece qualsiasi argomento aggiuntivo. Ogni altro argomento viene confrontato come testo letterale. Perciò %ops ALL = /sbin/service ntp * è valido, perché ntp è letterale e * è l'ultimo elemento. Una regola come questa, invece, non concede nulla di ciò che si intendeva autorizzare:

deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart app-*

app-* è un pattern all'interno di un argomento. sudo-rs non lo espande, quindi la regola non copre systemctl restart app-api e sudo rifiuta il comando. Due comandi mostrano il comportamento effettivo di qualsiasi regola sul proprio server: sudo -l -U deploy, eseguito come root, stampa ciò che quell'account può realmente eseguire, mentre sudo visudo -c indica se il file viene analizzato correttamente. Eseguirli prima di iniziare a modificare il file senza una verifica.

La regola con wildcard lasciava sempre una falla

Nel sudo originale, gli argomenti digitati vengono concatenati in un'unica stringa e confrontati con la stringa degli argomenti della regola tramite un glob. Un glob corrisponde anche agli spazi. È questo l'aspetto che quasi tutti trascurano.

La documentazione di sudo-rs fornisce la dimostrazione più chiara. Una regola del tipo /bin/rm *.txt consente anche sudo rm -rf /home .txt, perché l'unico * assorbe -rf /home e la stringa concatenata termina comunque con .txt. La regola si legge come «solo file di testo». In realtà significa «qualsiasi argomento, purché la riga termini con .txt».

Lo stesso vale per l'esempio con systemctl. Poiché gli argomenti vengono confrontati come un'unica stringa concatenata, un pattern finale corrisponde anche a tutto ciò che viene aggiunto dopo. Di conseguenza, restart app-* autorizza restart app-api e qualsiasi ulteriore argomento aggiunto dal chiamante. Un pattern all'interno di un argomento espone gli argomenti che lo precedono e lo seguono, ma è negli argomenti che risiede il potere di un comando. sudo-rs rifiuta questo costrutto invece di tentare di renderlo sicuro, perché non esiste una forma generale sicura per questo caso.

Sostituisci il carattere jolly con un elenco esplicito di comandi

La maggior parte delle regole con caratteri jolly esiste perché qualcuno non voleva digitare quattro righe. Digita le quattro righe.

Cmnd_Alias APP_RESTART = /usr/bin/systemctl restart app-api, /usr/bin/systemctl restart app-worker
Cmnd_Alias APP_STATUS = /usr/bin/systemctl status app-api, /usr/bin/systemctl status app-worker
deploy ALL=(root) NOPASSWD: APP_RESTART, APP_STATUS

Indica il percorso corretto. Una regola che specifica /bin/systemctl su un sistema in cui il binario si trova in /usr/bin/systemctl non corrisponde mai, e il problema appare identico a un errore di autorizzazioni. Verifica con command -v systemctl e incolla l’output.

Inserisci la regola in un file drop-in dedicato anziché in /etc/sudoers, così un aggiornamento del pacchetto non sovrascriverà le tue modifiche:

sudo visudo -f /etc/sudoers.d/90-deploy
sudo visudo -c
sudo -l -U deploy

Assegna al file un nome senza punto e senza tilde finale. La versione originale di sudo ignora i file in sudoers.d i cui nomi contengono un punto, quindi 90-deploy.conf non produce alcun effetto senza mostrare errori. Rispettare questa convenzione non costa nulla.

Usa un wrapper di proprietà di root quando l'elenco diventa lungo

Quando l'insieme degli elementi consentiti è troppo grande da elencare, sposta la decisione fuori da sudoers e inseriscila in un piccolo programma di proprietà di root.

sudo tee /usr/local/sbin/app-restart >/dev/null <<'EOF'
#!/bin/sh
set -eu
case "${1:-}" in
  app-api|app-worker) ;;
  *) echo "app-restart: not allowed: ${1:-}" >&2; exit 1 ;;
esac
exec /usr/bin/systemctl restart "$1"
EOF
sudo chown root:root /usr/local/sbin/app-restart
sudo chmod 0755 /usr/local/sbin/app-restart
ls -l /usr/local/sbin/app-restart

In sudoers viene quindi indicato un solo comando:

deploy ALL=(root) NOPASSWD: /usr/local/sbin/app-restart *

Il * finale è accettabile in questo caso perché è lo script, non sudo, a decidere cosa è consentito. Questo vale solo se lo script è di proprietà di root e nessun altro può scriverci. Se deploy può scrivere nel file, deploy può sostituirne il contenuto ed eseguire qualsiasi comando come root, con un rischio maggiore rispetto alla regola con carattere jolly rimossa. Controlla i permessi con ls -l e, se l'output non ti è chiaro, imparare a leggere la stringa di permessi drwxr-xr-x richiede cinque minuti. La stessa regola vale per la directory: anche /usr/local/sbin non deve essere scrivibile dall'account, perché una directory scrivibile consente di sostituire completamente il file.

Assegna al job un account dedicato invece di una regola sudo

La domanda migliore è spesso perché il comando debba usare root. Un servizio eseguito con il proprio utente può essere gestito da quell'utente, senza coinvolgere alcuna riga di sudoers. Per le unità di sistema, systemd delega già questa decisione a polkit. È quindi possibile creare una regola che specifichi una sola unità e un solo operatore:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "app-api.service" &&
        subject.user == "deploy") {
        return polkit.Result.YES;
    }
});

Salva la regola come /etc/polkit-1/rules.d/50-app-api.rules. In questo modo deploy può eseguire systemctl restart app-api senza usare sudo. Verificala dal contesto esatto in cui verrà utilizzata. Una regola che funziona nella sessione SSH deve essere verificata anche da cron prima di farvi affidamento. In ogni caso, l'account che esegue l'operazione deve essere dedicato esclusivamente a quella funzione. È lo stesso principio alla base degli account utente con privilegi minimi su un VPS.

Cos’altro manca in sudo-rs

sudo -E non è implementato. Indicare le variabili necessarie con Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY" e ricordare che env_reset è sempre attivo: tutto ciò che non viene conservato viene eliminato.

L’archiviazione centralizzata di sudoers in LDAP non è disponibile. sudoers.ldap e cvtsudoers non sono implementati e il pacchetto sudo-ldap è stato rimosso nella versione 26.04. L’autenticazione LDAP tramite PAM o SSSD continua a funzionare. Non rientra nell’ambito, invece, la gestione delle policy in una directory.

INTERCEPT, che tentava di impedire le escape dalla shell a partire da un comando autorizzato, non è implementato. In ogni caso, non avrebbe fermato un utente determinato. Se una regola consente di eseguire un editor o un interprete come root, l’utente dispone di fatto dei privilegi root e nessuna opzione di sudo può cambiare questa situazione.

La registrazione delle sessioni non è implementata. Non sono quindi disponibili log I/O né sudoreplay. La registrazione viene inviata solo a syslog e non esiste alcuna opzione logfile per reindirizzarla altrove. I messaggi di sudo vengono quindi scritti nella destinazione a cui il sistema invia già syslog.

Tornare a sudo.ws?

È possibile farlo e, durante il ciclo 26.04, il pacchetto originale rimane disponibile esattamente per questo motivo.

sudo apt install sudo
update-alternatives --config sudo
sudo update-alternatives --set sudo /usr/bin/sudo.ws

Copia i percorsi esatti dall'output di --config, non da questa pagina, perché quella è la lista accettata dal tuo sistema. Per tornare in seguito a sudo-rs, imposta l'alternativa sul percorso del binario sudo-rs riportato nella stessa lista.

Prima di modificare qualsiasi elemento che influisca su sudo, mantieni aperta una seconda sessione SSH, con l'accesso effettuato e la sessione inattiva. Un file sudoers che non può essere analizzato oppure un'alternativa che punta a un binario non installato può impedirti di diventare root su un sistema remoto. Questa precauzione rientra nelle operazioni da eseguire nei primi dieci minuti su un nuovo VPS.

Considera il ritorno al valore precedente una scadenza, non una correzione. Ti concede una settimana per riscrivere correttamente le regole. La riscrittura è utile anche a prescindere, perché ogni regola con caratteri jolly che elimini concedeva più autorizzazioni di quanto il suo autore avesse previsto.

FAQ

Perché la regola wildcard di sudoers ha smesso di funzionare su Ubuntu 26.04?

Ubuntu 26.04 LTS seleziona sudo-rs come implementazione predefinita di sudo, ma sudo-rs non riconosce i pattern wildcard negli argomenti di un comando. Consente una wildcard nel nome del file del comando, "" per indicare l'assenza di argomenti e un singolo * come argomento finale. Una regola come /usr/bin/systemctl restart app-* inserisce un pattern all'interno di un argomento, quindi non concede alcuna autorizzazione e il comando viene rifiutato. Esegui sudo -l -U deploy come root per verificare le autorizzazioni effettive dell'account, quindi sostituisci la regola con i comandi esatti oppure con uno script wrapper di proprietà di root.

Come posso tornare al sudo originale su Ubuntu 26.04?

L'implementazione originale è inclusa nel pacchetto sudo, i cui binari hanno il suffisso .ws. Installala con sudo apt install sudo, quindi imposta l'alternativa con sudo update-alternatives --set sudo /usr/bin/sudo.ws. Esegui prima update-alternatives --config sudo per leggere i percorsi esatti disponibili sul sistema e mantieni aperta una seconda sessione SSH mentre modifichi l'impostazione. Questo non ripristina sudo-ldap, che è stato rimosso da 26.04 indipendentemente dall'implementazione selezionata.

sudo-rs legge lo stesso file /etc/sudoers?

Sì. sudo-rs legge /etc/sudoers e i file drop-in presenti in /etc/sudoers.d/, usando la stessa sintassi per utenti, gruppi, alias, specifiche run-as e il tag NOPASSWD. Implementa un sottoinsieme del linguaggio sudoers, quindi le differenze si manifestano come costrutti mancanti, non come costrutti con comportamento diverso. Modifica il file con sudo visudo, quindi verifica la configurazione con sudo visudo -c prima di chiudere la sessione.

Cosa sostituisce sudo -E in sudo-rs?

sudo -E non è implementato ed era già sconsigliato nel sudo originale, perché fornire a un processo root un ambiente controllato dall'utente è un modo noto per modificarne il comportamento. Indica invece in sudoers le variabili effettivamente necessarie, con una riga come Defaults env_keep += "HTTP_PROXY HTTPS_PROXY NO_PROXY". env_reset è sempre attivo in sudo-rs e non può essere disabilitato, quindi tutte le variabili non conservate vengono cancellate.