Il principio del privilegio minimo (e perché sudo va usato con cura)

Il principio del privilegio minimo dice una cosa semplice: ogni persona, programma o servizio deve avere solo i permessi che servono per fare il proprio lavoro, e solo per il tempo necessario. Se un account con pochi poteri viene compromesso, i danni restano piccoli; se è un amministratore, il danno è totale. Molti attacchi riusciti non sono geniali: trovano un permesso più largo del necessario e lo sfruttano.

Perché è così importante

Pensa a un palazzo: il portinaio ha le chiavi del portone, non quelle di tutti gli appartamenti. Nei sistemi informatici, invece, è comune dare a un servizio i permessi dell'amministratore «per far prima». Se quel servizio ha una vulnerabilità, chi la sfrutta eredita tutti i suoi poteri. L'aumento dei privilegi da utente semplice ad amministratore (la *privilege escalation*) è una tappa fissa di quasi ogni intrusione seria.

Sudo: potere a piccole dosi

Su Linux il comando sudo permette a un utente di eseguire singoli comandi come amministratore (root) senza entrare come root. Le regole stanno nel file /etc/sudoers. Il problema nasce dal modo in cui sono scritte.

# Troppo largo: anna può fare qualunque cosa, senza password
anna ALL=(ALL) NOPASSWD: ALL

# Meglio: solo il comando che le serve davvero
anna ALL=(root) /usr/bin/systemctl restart nginx

Anche una regola che sembra innocua può essere troppo larga. Se concedi sudo su un programma che può leggere o scrivere qualsiasi file (un editor, un visualizzatore di testo, un archiviatore), concedi di fatto l'accesso a tutto il sistema, compreso il file delle password. Per questo il comando più utile da lanciare su un sistema che stai controllando è sudo -l: elenca cosa può fare l'utente corrente con privilegi elevati.

Un esempio concreto: i programmi SUID

Alcuni programmi hanno il bit SUID: quando li esegui, girano con i permessi del proprietario (spesso root). Servono, per esempio, per cambiare la propria password, ma ogni programma SUID in più è una superficie d'attacco. Un controllo di routine per elencarli:

$ find / -perm -4000 -type f 2>/dev/null
/usr/bin/passwd
/usr/bin/sudo
/usr/bin/mount
/opt/strumento-vecchio/backup-tool     <-- chi l'ha messo qui? serve davvero?

I primi sono previsti in un sistema normale; l'ultimo è fuori posto e va spiegato o rimosso (chmod u-s). È lo stesso ragionamento che si allena nei laboratori di audit di PurpleDuel, su sistemi simulati.

Come ci si difende: mettere in pratica il privilegio minimo

• Account separati: usa un utente normale per il lavoro di tutti i giorni e l'amministrazione solo quando serve.
• Regole sudo precise: un comando per riga, con il percorso completo e senza caratteri jolly; NOPASSWD: ALL non andrebbe mai usato.
• Servizi con utenti dedicati e senza accesso alla shell: un database non deve girare come root.
• Revisione periodica: elenca gli account, i gruppi amministrativi, le regole sudo e i programmi SUID, e rimuovi ciò che non serve più.
• Permessi temporanei: concedi i privilegi elevati per il tempo di un'attività e poi revocali.
• Registra e controlla: i log di sudo dicono chi ha eseguito cosa e quando, e sono una fonte preziosa dopo un incidente.
• Separa i dati: nelle applicazioni web l'utente del database deve poter fare solo ciò che l'app richiede, come spiegato nella guida alla SQL injection.

La stessa idea sta dietro l'architettura *zero trust*: nessuno ha fiducia automatica, ogni accesso viene verificato e ristretto al minimo indispensabile.