Bloccare il comando su per gli utenti sudo in Linux

Obiettivo reale: impedire l’uso di su senza rompere l’accesso amministrativo

Se vuoi bloccare su per gli utenti che hanno sudo, la prima cosa da chiarire è il modello operativo: sudo e su non sono equivalenti.

sudo concede privilegi in modo granulare, tracciabile e spesso con policy centralizzate. su cambia utente dopo l’autenticazione della password dell’account di destinazione, di solito root, e non passa da una policy per comando altrettanto fine.

Quindi, se l’obiettivo è ridurre il rischio operativo o l’uso improprio di root, la strada corretta non è “vietare a tutti su e basta”, ma definire una combinazione di:

• controllo dei gruppi autorizzati a usare su
• policy PAM per limitare chi può autenticarsi via su
• preferenza organizzativa per sudo al posto di su
• audit degli accessi e dei passaggi a root

Se fai solo uno di questi passi, il blocco sarà parziale. Se vuoi un controllo serio, devi agire sul livello giusto.

Come funziona davvero su

Su molte distribuzioni, il comando su è gestito da PAM e da regole locali. In pratica, l’utente può usare su se:

• riesce ad autenticarsi con la password dell’account di destinazione
• non è escluso da una regola PAM o da una restrizione di gruppo
• il binario non è stato sostituito o ristretto da policy aggiuntive

Questo significa che, se root ha una password nota e gli utenti possono tentare su, il blocco non è automatico solo perché usano sudo. Un utente con privilegi sudo può anche diventare root con sudo -i o sudo su -, quindi vietare su non elimina il problema di fondo: devi decidere quale percorso amministrativo vuoi consentire.

Decisione architetturale consigliata

Per ambienti server, la prassi migliore è:

1. disabilitare o rendere non usabile la password di root
2. concedere privilegi amministrativi solo via sudo
3. limitare chi può usare su a un gruppo ristretto, se proprio serve
4. registrare i tentativi falliti e i passaggi a root

Così ottieni tracciabilità e riduci il rischio di escalation non controllata.

Opzione 1: consentire su solo a un gruppo dedicato

È la soluzione più pulita quando vuoi che su resti disponibile solo a pochi amministratori di fiducia.

Molte distribuzioni usano il gruppo wheel o admin, ma non darlo per scontato: dipende dalla distro e dalla configurazione PAM.

Verifica prima la policy attuale:

grep -R "pam_wheel\|su" /etc/pam.d /etc/security 2>/dev/null

Se trovi una riga simile a auth required pam_wheel.so use_uid, il sistema sta già usando il gruppo wheel per limitare su.

Per controllare i membri del gruppo:

getent group wheel

Se il gruppo non esiste o è vuoto, puoi crearlo e aggiungere solo gli account autorizzati:

groupadd wheel

usermod -aG wheel nomeutente

Per rendere effettivo il controllo, la policy PAM deve negare su a chi non è nel gruppo consentito. Su molte distro questo si fa nel file /etc/pam.d/su.

Esempio tipico:

auth required pam_wheel.so use_uid group=wheel

In alcune implementazioni puoi anche invertire la logica e limitare l’accesso a un gruppo diverso da wheel, ma la verifica va fatta sul pacchetto PAM della tua distribuzione.

Verifica attesa: un utente non membro del gruppo prova su - e riceve un rifiuto; un utente autorizzato può ancora usare sudo per compiti amministrativi.

Opzione 2: bloccare su via PAM

Se vuoi un blocco più netto, puoi intervenire direttamente su PAM. È la via più comune quando devi impedire l’uso di su a una platea ampia ma non vuoi disinstallare il comando.

Prima di cambiare, fai un backup del file:

cp -a /etc/pam.d/su /etc/pam.d/su.bak.$(date +%F_%H%M)

Le strategie possibili sono due:

1. limitare su a un gruppo specifico con pam_wheel.so
2. negare esplicitamente su a tutti o a utenti selezionati con regole PAM personalizzate

La prima è quasi sempre preferibile perché è più semplice da auditare e meno fragile.

Un esempio pratico di restrizione forte, da adattare alla tua distro, è:

auth required pam_wheel.so use_uid group=wheel

Se il tuo obiettivo è impedire su agli utenti con sudo ma lasciare accesso ai soli operatori di console o break-glass, allora il gruppo autorizzato deve essere separato dal gruppo sudo. Non mischiare i due ruoli.

Blast radius: un errore nella configurazione PAM può bloccare anche gli amministratori legittimi. Tieni una sessione root già aperta o accesso console fuori banda prima di applicare il cambio.

Rollback: ripristina il backup di /etc/pam.d/su e verifica con un nuovo login.

Opzione 3: rendere root non utilizzabile con password

Questo è il punto che spesso risolve davvero il problema. Se root non ha una password utilizzabile, su perde gran parte del suo senso operativo.

Su molte distribuzioni puoi bloccare la password di root con:

passwd -l root

Oppure, in ambienti dove la policy lo consente, impostare root senza password attiva e usare solo sudo per l’amministrazione.

Attenzione: non fare questo se non hai già verificato un percorso amministrativo alternativo funzionante, perché potresti tagliarti fuori. Serve almeno un utente con sudo testato e una sessione di emergenza.

Verifica attesa: su - verso root fallisce per tutti, mentre sudo -i continua a funzionare per gli account autorizzati.

Se in azienda hai bisogno di accessi break-glass, meglio usare account nominativi con privilegi temporanei e audit, non password root condivise.

Opzione 4: preferire sudo e togliere il percorso culturale verso su

Il blocco tecnico è utile, ma spesso il problema è organizzativo. Se gli utenti amministrativi sono abituati a usare su, continueranno a cercarlo anche quando esistono alternative migliori.

La linea corretta è:

• documentare che l’accesso amministrativo standard passa da sudo
• limitare su ai soli casi eccezionali
• usare sudoers con privilegi minimi necessari
• registrare i comandi amministrativi eseguiti

Per esempio, in /etc/sudoers o in un file sotto /etc/sudoers.d/, assegna solo i comandi necessari invece di dare accesso totale a root.

Verifica la sintassi sempre con:

visudo -c

Verifica attesa: l’utente amministrativo esegue i task con sudo e non ha bisogno di aprire una shell root persistente.

Audit: sapere chi ha tentato su

Bloccare senza tracciare non basta. Devi vedere chi prova a usare su, chi fallisce e chi riesce.

Controlla i log di autenticazione della tua distribuzione:

• /var/log/auth.log su Debian e derivate
• /var/log/secure su RHEL, CentOS, Rocky, AlmaLinux
• journalctl se i log passano da systemd-journald

Esempi utili:

grep su /var/log/auth.log

grep su /var/log/secure

journalctl -t su

Se vuoi una verifica rapida dei tentativi falliti, cerca anche gli eventi PAM e le autenticazioni negate.

Per una postura più solida, integra il monitoraggio con alert sui tentativi ripetuti di su falliti e con retention adeguata dei log.

Limiti reali della restrizione

Bloccare su non elimina automaticamente il privilegio amministrativo se l’utente ha già sudo troppo ampio.

In particolare:

• sudo -i può aprire una shell root
• sudo su - aggira il divieto di usare direttamente su
• un utente nel gruppo sudo con policy troppo permissiva resta comunque troppo potente

Quindi il controllo vero è sul perimetro dei privilegi, non solo sul nome del comando.

Se vuoi ridurre davvero il rischio, applica anche questi principi:

1. niente password root condivisa
2. sudoers per singolo comando o per ruoli ben definiti
3. accesso amministrativo nominativo
4. log centralizzati e conservazione delle evidenze

Procedura consigliata passo per passo

Se vuoi un approccio pratico e reversibile, usa questa sequenza:

1. verifica quali utenti hanno già sudo e quali gruppi sono autorizzati a usare su
2. controlla il file /etc/pam.d/su e la presenza di pam_wheel.so
3. crea un gruppo dedicato agli operatori autorizzati a usare su, separato dal gruppo sudo
4. aggiungi solo gli account necessari a quel gruppo
5. imposta o rafforza la policy PAM per limitare su al gruppo dedicato
6. se possibile, blocca la password di root e usa sudo come percorso standard
7. testa con un utente autorizzato e con uno non autorizzato
8. verifica i log di autenticazione per confermare il comportamento atteso

Verifica finale: un utente con sudo ma non nel gruppo autorizzato fallisce con su -; un amministratore autorizzato può ancora operare secondo la policy decisa.

Controlli finali / rollback

Dopo la modifica, controlla almeno questi punti:

• getent group wheel o il gruppo scelto mostra solo gli utenti autorizzati
• grep -R "pam_wheel\|su" /etc/pam.d /etc/security riflette la policy attesa
• un tentativo di su da un utente non autorizzato viene negato nei log
• sudo continua a funzionare per gli account previsti

Se qualcosa non torna, ripristina il backup del file PAM:

cp -a /etc/pam.d/su.bak.YYYY-MM-DD_HHMM /etc/pam.d/su

e riesegui un test di autenticazione da una sessione separata.

Assunzione: la distribuzione usa PAM standard e il controllo di su passa da /etc/pam.d/su; se il sistema ha una variante diversa, verifica il file di servizio equivalente prima di applicare le regole.