Gestire Utenti Linux: Guida Pratica a Permessi e Sicurezza

Quando ho dovuto ripulire gli accessi su un ente sanitario con 2.000 workstation, ho trovato 47 account con privilegi root. Quarantasette. Alcuni appartenevano a consulenti che non lavoravano lì da tre anni. Gestire utenti e permessi Linux non è un esercizio accademico. È la linea di difesa che separa un server sotto controllo da un server violato. Se chiunque può diventare root, il tuo SIEM non ti salverà. Se i file di configurazione hanno permessi 777, qualsiasi script malevolo li sovrascrive. In questa guida affrontiamo esattamente come creare, modificare e rimuovere utenti, assegnare i permessi corretti e auditare l’accesso. Senza teoria inutile, solo comandi pronti per la produzione.

Utenti, gruppi e UID/GID — come funziona Linux sotto il cofano

Per gestire utenti linux in modo efficace, devi capire come il sistema li identifica. Linux non conosce i nomi utente internamente. Conosce solo numeri. Il UID (User ID) identifica l’utente, il GID (Group ID) identifica il gruppo primario. Il UID 0 è root. Se un utente ha UID 0, è root, indipendentemente dal nome che gli dai. [Leggi anche: Hardening SSH su Linux: 10 Impostazioni Essenziali]

I dati risiedono in tre file critici:

• /etc/passwd: mappa nome utente a UID, GID, shell e home directory.
• /etc/shadow: contiene gli hash delle password. Solo root può leggerlo.
• /etc/group: definisce i gruppi e i membri supplementari.

Se apri /etc/passwd e vedi una shell /bin/bash su un account di servizio, hai un problema. Gli account di servizio non devono fare login interattivo. La shell deve essere /usr/sbin/nologin.

Creare e gestire utenti: adduser, usermod, userdel

Il primo errore che vedo spesso è usare useradd al posto di adduser. Su Debian e Ubuntu, useradd crea l’utente ma non configura la home directory, non imposta la password e non copia gli skeleton file. adduser è uno script Perl interattivo che fa tutto correttamente.

Per creare un nuovo utente:

sudo adduser nomeutente

Il comando ti chiederà la password, il nome completo e creerà automaticamente la /home/nomeutente copiando i file da /etc/skel.

Se questo utente deve avere privilegi amministrativi, non dargli la password di root. Aggiungilo al gruppo sudo:

sudo usermod -aG sudo nomeutente

Il flag -aG è fondamentale. Significa append to supplementary Group. Se ometti -a, rimuoverai l’utente da tutti gli altri gruppi supplementari a cui appartiene, isolandolo e rompendo probabili configurazioni di accesso.

Quando un consulente lascia l’azienda, l’account deve sparire. Non disabilitarlo e basta. Rimuovilo insieme alla sua home directory:

sudo userdel -r nomeutente

Il flag -r rimuove la home e la coda di posta. Se non lo usi, lascerai file orfani in giro per il filesystem, file di cui nessuno ha più la responsabilità.

Gestire i gruppi: groupadd, groupmod, gpasswd

I gruppi sono il modo corretto per gestire le autorizzazioni condivise. Se tre sviluppatori devono scrivere nella stessa directory, non impostare i permessi per singolo utente. Crea un gruppo.

sudo groupadd developers

Ora aggiungi gli utenti al gruppo:

sudo usermod -aG developers nomeutente

Per vedere a quali gruppi appartiene un utente, usa id nomeutente. L’output ti mostra il UID, il gruppo primario (GID) e tutti i gruppi supplementari.

Se devi rimuovere un utente da un gruppo specifico senza toccare gli altri, usa gpasswd:

sudo gpasswd -d nomeutente developers

Per maggiori dettagli sulla gestione dei gruppi e dei file di configurazione, consulta la documentazione ufficiale di Shadow utils: https://man7.org/linux/man-pages/man5/passwd.5.html

Permessi file: chmod in notazione simbolica e ottale

Ogni file in Linux ha tre categorie di accesso: User (proprietario), Group (gruppo proprietario), Other (tutti gli altri). Ogni categoria può avere permessi di Read (4), Write (2) ed Execute (1).

La notazione ottale somma questi valori. 7 significa 4+2+1 (Lettura, Scrittura, Esecuzione). 5 significa 4+1 (Lettura, Esecuzione).

Per rendere uno script eseguibile dal proprietario e leggibile da tutti:

chmod 755 script.sh

Il proprietario può leggere, scrivere ed eseguire (7). Il gruppo e gli altri possono solo leggere ed eseguire (5).

La notazione simbolica è più selettiva quando devi modificare un solo permesso senza alterare gli altri:

chmod u+x,g-w,o-r file.txt

In questo comando hai aggiunto l’esecuzione all’utente (u+x), rimosso la scrittura al gruppo (g-w) e rimosso la lettura agli altri (o-r). È l’approccio più sicuro quando non conosci a memoria i permessi attuali del file.

Un avvertimento sui permessi 777. Significa che chiunque può leggere, scrivere ed eseguire. Non usarlo mai in produzione. Se un attaccante ottiene accesso tramite un servizio compromesso, la prima cosa che farà sarà scrivere uno script in una directory con permessi 777 e farlo eseguire al proprietario del processo.

Proprietà: chown e chgrp — esempi pratici

I permessi si applicano sempre in base al proprietario e al gruppo. Se assegni i permessi al gruppo sbagliato, l’accesso non funzionerà.

Per cambiare proprietario e gruppo di un file specifico:

chown utente:gruppo file.txt

Nei web server, il problema più comune è avere i file di proprietà dell’utente root mentre il processo Apache o Nginx gira come www-data. Il risultato è un errore 403 Forbidden quando l’applicazione prova a scrivere un log o caricare un’immagine.

La correzione standard per la document root:

chown -R www-data:www-data /var/www/

Il flag -R applica la modifica ricorsivamente a tutti i file e le sottodirectory. Attenzione: usalo solo dove necessario. Se cambi ricorsivamente il proprietario di /etc, romperai il sistema in modo irreversibile.

Per cambiare solo il gruppo, usa chgrp:

chgrp developers /opt/progetto

Il bit SUID, SGID e sticky bit — quando e perché usarli

Questi sono permessi speciali che alterano il comportamento standard del sistema. Se usati male, creano escalation di privilegi.

Il bit SUID (Set-owner User ID) esegue un file con i privilegi del proprietario, non di chi lo lancia. Il classico esempio è /usr/bin/passwd. Deve girare come root per modificare /etc/shadow, ma un utente normale deve poter cambiare la propria password.

Il problema sorge quando trovi file SUID che non dovrebbero esserlo. Script bash, binari custom, vecchi eseguibili dimenticati. Un attaccante che sfrutta una vulnerabilità in un file SUID diventa istantaneamente root.

Trova tutti i file con bit SUID attivo sul sistema:

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

Confronta l’output con una lista nota di binari SUID legittimi del tuo sistema operativo. Se trovi qualcosa di anomalo in /tmp o /home, indaga immediatamente.

Il bit SGID (Set-Group ID) sui file funziona come SUID, ma per il gruppo. Sulle directory, fa in modo che ogni nuovo file creato erediti il gruppo della directory, non il gruppo primario dell’utente. È utile per le directory condivise del team.

Lo sticky bit si usa quasi esclusivamente sulla directory /tmp. Permette agli utenti di creare file dentro la directory, ma solo il proprietario del file (o root) può cancellarlo. Senza sticky bit, qualsiasi utente potrebbe cancellare i file temporanei degli altri.

sudo e /etc/sudoers — delegare i privilegi in modo sicuro

Distribuire la password di root è un errore di security 101. Usa sudo. Permette di delegare comandi specifici a utenti specifici, con logging completo di chi ha fatto cosa.

Mai modificare direttamente /etc/sudoers con un editor di testo. Se fai un errore di sintassi, sudo smette di funzionare e ti lockout dal sistema. Usa sempre:

sudo visudo

visudo apre il file in un editor, ma prima di salvare verifica la sintassi. Se c’è un errore, ti avvisa e non salva le modifiche.

Per delegare un comando specifico, crea un file in /etc/sudoers.d/. È più pulito e facile da gestire rispetto a modificare il file principale. Per esempio, per permettere all’utente backupadm di lanciare solo i comandi di backup senza password:

backupadm ALL=(ALL) NOPASSWD: /usr/local/bin/backup.sh

Limita sempre i comandi al minimo indispensabile. Un utente con NOPASSWD: ALL è di fatto root senza password.

Auditare chi ha fatto cosa: last, lastlog, who

Non puoi proteggere quello che non monitori. Quando gestire utenti linux diventa complesso, l’audit è la tua ancora di salvezza.

Per vedere chi è loggato in questo momento:

who

Per vedere gli ultimi login effettuati:

last

last legge /var/log/wtmp. Ti mostra utente, terminale, indirizzo IP e data di login. Se vedi un login da un IP insolito alle 3 di notte, hai un problema.

Per vedere l’ultimo login di ogni utente registrato nel sistema:

lastlog

È il comando più veloce per trovare account che non vengono usati da mesi. Se un account di servizio non ha mai fatto login, ma ha una shell valida in /etc/passwd, è un rischio inutile.

Checklist sicurezza utenti per server in produzione

Applica questi controlli su ogni nuovo server prima di metterlo in produzione.

1. Disabilita il login root diretto. In /etc/ssh/sshd_config, imposta PermitRootLogin no.
2. Rimuovi le shell di login dagli account di servizio. Usa /usr/sbin/nologin.
3. Verifica i file SUID. Confronta l’output di find / -perm -4000 -type f con la baseline del sistema operativo.
4. Controlla i permessi delle chiavi SSH. La directory ~/.ssh deve essere 700, il file authorized_keys deve essere 600. Se sono 644, sshd rifiuterà di usarle.
5. Configura sudo con visudo. Delega solo i comandi necessari. Niente NOPASSWD: ALL a meno che non sia strettamente giustificato e documentato.
6. Imposta lo sticky bit sulle directory world-writable come /tmp.
7. Usa lastlog per identificare e rimuovere gli account inattivi da più di 90 giorni.

La sicurezza non è un prodotto, è un processo. Gestire utenti e permessi Linux richiede costanza. Un server configurato oggi perfettamente diventa insicuro tra sei mesi se nessuno controlla chi accede e cosa lasciano in giro. Automatizza questi controlli con script bash o Ansible, ma prima assicurati di averli capiti a fondo manualmente.