Il file che si comporta da root - capire il bit SUID

Quando esegui un comando su Linux, il sistema controlla chi sei - il tuo user ID - e decide cosa puoi fare. È il modello di base: ogni processo eredita i permessi dell'utente che lo ha lanciato.

Il bit SUID rompe questa regola. Non per un bug, ma intenzionalmente.

Prima di tutto: come funzionano i permessi normali

#

Ogni file su Linux ha tre gruppi di permessi: owner, group, others. Ognuno ha tre bit: lettura (r), scrittura (w), esecuzione (x).

-rwxr-xr-x  1 root root  /usr/bin/ls
 ↑↑↑ ↑↑↑ ↑↑↑
 │   │   └── others: può leggere ed eseguire
 │   └────── group: può leggere ed eseguire
 └────────── owner (root): può fare tutto

Quando esegui ls, il kernel crea un processo con il tuo user ID. Il fatto che il file appartenga a root non cambia niente - importa solo che tu abbia il bit x per eseguirlo.

Il problema di passwd

#

Considera questo scenario: vuoi cambiare la tua password. Il comando è passwd. Ma le password sono in /etc/shadow, un file che appartiene a root e che solo root può modificare:

ls -la /etc/shadow
# ---------- 1 root shadow 1234 ...  /etc/shadow

Eppure passwd funziona per tutti gli utenti normali. Come?

ls -la /usr/bin/passwd
# -rwsr-xr-x 1 root root 68208 ...  /usr/bin/passwd
#     ↑
#     s al posto di x - questo è il bit SUID

Quella s cambia tutto. Quando un file ha il bit SUID e appartiene a root, il kernel eleva temporaneamente i privilegi del processo a quelli del proprietario del file (root), per tutta la durata dell'esecuzione.

Tu (uid=1001) esegui passwd
        │
        ▼
kernel vede SUID bit + proprietario root
        │
        ▼
processo gira con EUID=0 (root)
        │
        ▼
passwd può scrivere /etc/shadow
        │
        ▼
processo termina → EUID torna a 1001

È un meccanismo controllato: passwd è scritto per fare esattamente una cosa, in modo sicuro, poi restituire i privilegi. Il programma sa di avere privilegi elevati e li usa con attenzione.

RUID vs EUID - la distinzione che conta

#

Linux distingue due tipi di user ID per ogni processo:

Normalmente RUID e EUID coincidono. Con SUID, l'EUID viene impostato al proprietario del file - non al tuo RUID.

Puoi verificarlo su qualsiasi processo:

id
# uid=1001(barno) gid=1001(barno) groups=1001(barno)

# dopo aver eseguito qualcosa con SUID root, dentro quel processo:
# uid=1001(barno) gid=1001(barno) euid=0(root)

Come si riconosce un file SUID

#

Il bit SUID compare nella posizione x dell'owner, sostituita da s:

-rwsr-xr-x   → SUID attivo, il bit x è presente (eseguibile + SUID)
-rwSr-xr-x   → SUID attivo, ma il bit x manca (non eseguibile - situazione anomala)
-rwxr-xr-x   → nessun SUID, normale

In ottale, il bit SUID vale 4000. Un file con chmod 4755 ha SUID + rwxr-xr-x.

Per trovare tutti i file SUID su un sistema:

find / -perm -4000 -type f 2>/dev/null

-perm -4000 significa "almeno il bit 4000 è attivo" - elenca tutto, anche file con permessi aggiuntivi. Il 2>/dev/null silenzia gli errori su directory inaccessibili.

Output tipico su un sistema Linux sano:

/usr/bin/passwd
/usr/bin/sudo
/usr/bin/su
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/umount
/usr/bin/ping
/usr/lib/openssh/ssh-keysign

Questi file hanno SUID per una ragione precisa. Ognuno fa operazioni privilegiate in modo controllato.

Perché diventa un problema di sicurezza

#

Il bit SUID è sicuro se il programma è scritto per gestirlo. I binari di sistema come passwd, sudo, ping sono progettati sapendo di avere EUID=0 - validano l'input, limitano quello che fanno, gestiscono gli errori.

Il problema sorge in tre scenari:

1. Binario sbagliato con SUID Un interprete generico (python3, bash, perl, vim) non ha restrizioni su cosa può fare con i privilegi elevati. Se qualcuno imposta SUID su python3, chiunque può ottenere una shell root in una riga.

2. Binario che chiama altri programmi Se un programma SUID root esegue altri comandi usando il PATH dell'utente o senza path assoluti, un attaccante può sostituire quei comandi con versioni malevole.

3. Errore di configurazione Qualcuno imposta SUID per risolvere un problema di permessi in fretta, dimenticando di rimuoverlo. Oppure un typo: chmod 4755 invece di chmod 755.

I binari SUID più pericolosi

#

Questi sono i binari che non dovrebbero mai avere SUID - se li trovi nella lista di find, è un alert immediato:

Il SUID nel contesto della sicurezza

#

Il bit SUID è uno dei vettori di privilege escalation più documentati. Un utente con accesso limitato a un sistema cerca prima di tutto binari SUID fuori dal normale - è il primo controllo in qualsiasi audit di sicurezza e in qualsiasi CTF Linux.

La ragione per cui è efficace: non richiede exploit, non richiede vulnerabilità nel kernel, non lascia quasi traccia. Basta trovare il binario giusto e sapere come usarlo.

exit 0

#

SUID non è un bug di Linux - è una feature con quarant'anni di storia, necessaria per far funzionare cose basilari come il cambio password. Il problema non è l'esistenza del meccanismo: è quando viene applicato a file che non sanno come gestire i privilegi elevati.

La differenza tra passwd e python3 con SUID root non è tecnica - è di progettazione. Uno è scritto per fare una cosa sola in modo sicuro. L'altro non ha nessuna limitazione su cosa può fare con quei privilegi.

Vuoi vedere come un bit SUID impostato per errore diventa una root shell in produzione? → chmod +s - il bit che dimentichi e l'attaccante trova

Concetti correlati: iam · linux permissions