Sudo resta fondamentale su Linux ma è senza risorse: il maintainer spiega cosa rischia davvero

La gestione dei privilegi in ambiente Unix e Linux poggia su strumenti consolidati da decenni e profondamente radicati nelle procedure operative di amministrazione di sistema. Tra questi, il comando sudo rappresenta un elemento critico: permette di eseguire comandi con privilegi elevati senza autenticarsi come utente root, riducendo così l’esposizione ai rischi di un accesso diretto permanente.

Nato nei primi anni ’80 e mantenuto stabilmente da oltre trent’anni dal maintainer Todd C. Miller, sudo ha attraversato diverse fasi di sviluppo e integrazione nei principali sistemi operativi Unix-like, fino ad assumere un ruolo di riferimento nelle distribuzioni moderne.

Un manutentore solitario e la richiesta di supporto

Miller è stato al timone del progetto sudo sin dal 1993, con una storia di collaborazione e sponsor che si è protratta fino al 2024, quando il supporto da parte della sua ex azienda, Quest Software, è terminato.

Dopo la fine di questa sponsorizzazione, Miller chiede pubblicamente risorse e assistenza per continuare lo sviluppo e la manutenzione del progetto, evidenziando come la mancanza di supporto finanziario stia rallentando la capacità di rispondere rapidamente a bug critici e pull request. Senza un sostegno strutturato, il ritmo di sviluppo resta ancorato principalmente alla risoluzione di problemi segnalati piuttosto che all’aggiunta di nuove funzionalità.

Rischi tecnici e vulnerabilità nella storia recente

Nonostante sudo sia un componente consolidato, negli ultimi anni sono emerse vulnerabilità significative che ne hanno messo in evidenza le debolezze intrinseche. Ad esempio, nel 2025 sono emerse due falle critiche, catalogate come CVE-2025-32462 e CVE-2025-32463, che interessavano versioni dalla 1.9.14 fino alla 1.9.17 e consentivano a utenti locali non privilegiati di ottenere escalation di privilegi fino all’utente root sfruttando opzioni come -h e -R (chroot). Questi bug richiedevano patch dedicate e aggiornamenti tempestivi dei pacchetti sudo nei sistemi di produzione per mitigare i rischi.

La transizione verso sudo-rs e le implicazioni per le distribuzioni

In risposta a problemi di sicurezza e alla complessità strutturale dell’implementazione in C, è nato sudo-rs, una reimplementazione del comando in linguaggio Rust progettata per garantire migliori proprietà di sicurezza della memoria e ridurre la superficie d’attacco.

Il linguaggio Rust, grazie al suo sistema di proprietà e gestione del borrowing, elimina molte classiche classi di errori come buffer overflow e null pointer dereference, comunemente associate a codice legacy in C.

Canonical ha adottato sudo-rs come implementazione predefinita nella distribuzione Ubuntu 25.10 (nome in codice Questing Quokka), con l’obiettivo di rendere il comando di escalation dei privilegi più sicuro e sostenibile in futuro, pur mantenendo compatibilità con la sintassi e le configurazioni esistenti. L’implementazione originale rimane disponibile ma potrebbe essere progressivamente affiancata o sostituita in altri contesti.

Problemi di sostenibilità nella manutenzione open source

La situazione attuale di sudo mette in luce una problematica comune nei progetti open source: la dipendenza da singoli sviluppatori o piccoli gruppi per la manutenzione di componenti fondamentali dell’infrastruttura software globale.

Strumenti come sudo sono utilizzati quotidianamente in milioni di server e workstation; la loro affidabilità e aggiornamento continuo sono essenziali non solo per la sicurezza, ma anche per la stabilità operativa. Senza un modello di finanziamento sostenibile o una comunità di manutentori più ampia, tali progetti rischiano di soffrire colli di bottiglia nella risoluzione dei bug, nella gestione delle patch e nell’adozione di innovazioni che rispondano alle esigenze moderne.

La responsabilità di sudo tra fiducia, successione e sostenibilità

Miller non ha alcuna intenzione di abbandonare sudo nel breve periodo, né di cederne la gestione con leggerezza. Il punto critico non è tanto la volontà di continuare, quanto l’assenza di un percorso credibile di successione. Dopo decenni di lavoro sul codice, la manutenzione di sudo non è più un’attività neutra o puramente tecnica: è diventata una responsabilità diretta verso milioni di sistemi e utenti. In questo contesto, l’idea di “passare il testimone” non può essere ridotta a una semplice consegna delle “chiavi” del repository ufficiale.

L’episodio della backdoor in xz utils ha inciso profondamente su questa percezione. Non si è trattato solo di una vulnerabilità sofisticata, ma di un evento che ha scosso uno dei presupposti impliciti dell’open source: la fiducia nel processo di revisione e nella buona fede dei contributori. Per chi mantiene un componente così delicato come sudo, la consapevolezza che una compromissione possa passare inosservata per anni rende qualsiasi delega un atto carico di rischio.

L’approccio manifestato da Miller è comprensibile, ma espone una criticità più ampia: strumenti centrali per la sicurezza e l’amministrazione dei sistemi dipendono dal tempo libero e dall’energia residua di singoli individui. È una condizione che non può reggere nel lungo periodo, soprattutto in un contesto in cui le minacce diventano più sofisticate e le aspettative di affidabilità sempre più elevate.

Il rapporto con sudo-rs

In questo quadro si inserisce sudo-rs, la già citata riscrittura dello strumento in Rust, che Miller stesso indica come probabile evoluzione naturale nei prossimi anni. Il fatto che alcune distribuzioni, come Ubuntu, abbiano già iniziato a distribuirlo come implementazione predefinita non è un dettaglio marginale. Segnala un cambio di direzione tecnico e culturale: maggiore attenzione alla sicurezza della memoria, architetture più moderne e una base di codice potenzialmente più accessibile a nuovi contributori. La fiducia di Miller nel team che sviluppa sudo-rs non nasce dal nulla, ma da un confronto continuo e da una conoscenza diretta maturata nel tempo.

Tuttavia, anche questa transizione non risolve automaticamente il problema di fondo. Cambiare linguaggio o riscrivere uno strumento non elimina il rischio di burnout né garantisce, da sola, un modello di governance sostenibile. Se la comunità e le aziende che dipendono quotidianamente da questi strumenti non intervengono con forme concrete di supporto, il rischio è quello di replicare lo stesso schema su basi tecnologiche diverse.