04 Novembre 2026

GNU/Linux

Indice navigabile

Pinguino Linux incappucciato davanti a un forziere aperto, circondato da simboli di permessi, file sensibili, systemd e Docker in pixel art rossa e nera

Il firewall lavora. SSH è blindato. Poi arriva un permesso lasciato largo “solo per fare una prova”.

Immaginate la scena: aggiornamenti installati, accessi filtrati, configurazioni controllate. Il server sembra pronto a difendere il regno.

Poi qualcuno trova uno script di backup modificabile da tutti, eseguito ogni notte da root.

A quel punto non serve necessariamente uno zero-day. Può bastare modificare il file giusto e aspettare che l’automazione faccia il resto.

È il problema del grande classico: “Metti 777, poi sistemiamo”.

Il problema si risolve. Il ticket si chiude. Il “poi” prende la residenza sul server.

Vediamo otto controlli sui permessi e sulle deleghe di privilegio che meritano attenzione. Senza trasformare il server in un fermacarte per eccesso di zelo.

Prima di iniziare: controllare non significa correggere alla cieca

Gli esempi usano strumenti GNU/Linux e, dove necessario, sudo. Sostituite i percorsi dimostrativi con quelli reali. I comandi di modifica vanno eseguiti soltanto dopo aver verificato proprietario, utilizzo e conseguenze.

Nei comandi find, -xdev limita la ricerca al filesystem di partenza. Se /home, /var o /usr sono filesystem separati, vanno controllati anche quelli: partire da / non significa automaticamente aver esaminato tutto.

Non nascondete gli errori durante l’audit: un percorso non leggibile è un pezzo di verifica mancante, non una prova di sicurezza.

1. SUID e SGID: privilegi che nessuno ricorda di aver assegnato

Sui programmi eseguibili, SUID e SGID possono attribuire rispettivamente l’identità effettiva del proprietario e del gruppo. Sono meccanismi legittimi; diventano interessanti quando compaiono su un programma inatteso, vulnerabile o non affidabile.

Per individuare i file con almeno uno dei due bit:

sudo find / -xdev -type f -perm /6000 -ls

Il risultato non è una lista di malware. È una lista di privilegi da giustificare.

Per ogni elemento inatteso chiedetevi da quale pacchetto provenga, perché abbia bisogno di quei privilegi e quando sia comparso. Confrontate l’inventario con una baseline verificata e conservata in un posto non modificabile dagli account sotto controllo.

Togliere tutti i bit speciali senza capire cosa state toccando non è hardening. È un modo creativo per aprire nuovi ticket.

2. File modificabili da tutti: il 777 non è un modello di sicurezza

Un file world-writable concede la scrittura anche agli altri utenti. Su uno script eseguito con privilegi elevati, questo può diventare un passaggio diretto dalla modifica del contenuto all’esecuzione privilegiata.

Per cercare i file interessati:

sudo find / -xdev -type f -perm -002 -ls

Per le directory scrivibili da tutti e prive di sticky bit:

sudo find / -xdev -type d -perm -002 ! -perm -1000 -ls

Non trattate automaticamente ogni risultato come un errore. /tmp e /var/tmp hanno uno scopo preciso e normalmente usano il modo 1777:

stat -c '%a %n' /tmp /var/tmp

Lo sticky bit limita la cancellazione e la rinomina delle voci altrui: non impedisce di modificare un file che concede già la scrittura sul proprio contenuto.

Quando la scrittura per gli altri non è necessaria, una correzione mirata può essere:

sudo chmod o-w /percorso/file

Poi verificate nuovamente permessi e funzionamento. Mirata, appunto. Non ricorsiva su mezzo sistema perché “così siamo sicuri”.

3. File sensibili: /etc/passwd non è /etc/shadow

Il nome può trarre in inganno: /etc/passwd contiene informazioni sugli account ed è normalmente leggibile da tutti. Anche /etc/group è normalmente pubblico nel sistema.

/etc/shadow contiene invece gli hash delle password e informazioni correlate. /etc/gshadow contiene informazioni protette sui gruppi. Questi file non devono diventare materiale da consultazione per utenti non privilegiati.

Controllate proprietari e permessi:

sudo stat -c '%A %a %U:%G %n' /etc/passwd /etc/shadow /etc/group /etc/gshadow

Per correggerli, rispettate i valori previsti dalla distribuzione: non esiste un unico comando chmod e chown da distribuire indistintamente su tutte le macchine.

Lo stesso ragionamento vale per configurazioni applicative contenenti password, token e chiavi API: deve leggerle il servizio che ne ha bisogno, non chiunque abbia ottenuto un accesso locale.

4. SSH: la chiave è privata, non condominiale

Una chiave privata leggibile da altri può essere copiata e potenzialmente usata per autenticarsi. Un authorized_keys modificabile da persone non autorizzate permette invece di alterare quali chiavi sono ammesse.

Come impostazione prudente, per i file SSH personali: directory .ssh a 700, chiave privata a 600 e authorized_keys a 600, con proprietario corretto.

Per esempio, sull’account interessato e sui file effettivamente presenti:

chmod 700 ~/.ssh

chmod 600 ~/.ssh/id_ed25519

chmod 600 ~/.ssh/authorized_keys

Questi percorsi riguardano l’utente della sessione corrente. Non la home di un altro account che avevate in mente di sistemare.

Le chiavi pubbliche non richiedono la stessa riservatezza delle private. E i permessi non sostituiscono la revisione degli accessi: controllate authorized_keys e rimuovete le chiavi non più autorizzate.

Una chiave dell’ex collaboratore resta una chiave valida finché non smettete di autorizzarla.

5. Sudoers: “può fare manutenzione” non significa “può fare tutto”

Una regola come questa non rappresenta una piccola delega:

utente ALL=(ALL) NOPASSWD: ALL

Consente di eseguire qualsiasi comando come root, senza richiesta della password da parte di sudo.

Il problema non è soltanto NOPASSWD. Anche wildcard troppo ampie, interpreti, shell ed editor possono concedere molto più di quanto suggerisca il nome del comando autorizzato.

Partite dalla verifica della configurazione:

sudo visudo -c

Poi esaminate /etc/sudoers e i file inclusi da /etc/sudoers.d. Per modificarli usate visudo, eventualmente indicando il file:

sudo visudo -f /etc/sudoers.d/nomefile

Al termine ripetete il controllo sintattico.

Attenzione: sintassi valida non significa delega sicura. Una regola può essere perfettamente scritta e concedere privilegi completamente sproporzionati.

6. Cron e systemd: root esegue, qualcun altro decide cosa

Il caso dello script di backup torna qui. Se root esegue periodicamente un file modificabile da un utente ordinario, quell’utente può influenzare il codice che verrà eseguito con privilegi elevati.

Controllate i job di root:

sudo crontab -l -u root

Esaminate anche /etc/crontab e /etc/cron.d. Per i timer systemd:

systemctl list-timers --all

Poi verificate i servizi coinvolti, i comandi ExecStart e i file richiamati. Per individuare file .service scrivibili dal gruppo oppure dagli altri:

sudo find /etc/systemd/system /usr/lib/systemd/system -type f -name '*.service' -perm /022 -ls

Qui /022 cerca almeno uno dei due bit di scrittura. -022 richiederebbe entrambi e perderebbe risultati rilevanti.

È un primo controllo, non un inventario completo: proprietari, gruppi autorizzati e configurazioni aggiuntive vanno comunque esaminati. Anche le directory che contengono gli script devono impedire sostituzioni da parte di utenti non autorizzati.

Spostare un’automazione da cron a systemd non corregge, per magia, i permessi dei file che esegue.

7. Capabilities: pochi privilegi, ma scelti male

Le capabilities suddividono i privilegi tradizionalmente associati a root. Il principio è utile: concedere soltanto ciò che serve. Ma “non è SUID” non significa “non ha privilegi pericolosi”.

Per vedere le capabilities assegnate ai file:

sudo getcap -r /

La scansione può essere ampia: valutate percorsi e filesystem coinvolti prima di lanciarla in produzione.

CAP_SETUID e CAP_SYS_ADMIN meritano particolare attenzione: la prima riguarda la modifica degli identificativi utente del processo; la seconda comprende un insieme molto esteso di operazioni privilegiate.

Verificate ogni assegnazione inattesa. Solo quando avete accertato che al binario non serva alcuna file capability, potete rimuovere l’intero insieme:

sudo setcap -r /percorso/binario

Quindi controllate:

getcap /percorso/binario

Conservate un inventario verificato e confrontatelo dopo installazioni e aggiornamenti. Non aggiornate la baseline soltanto per far sparire una differenza che non avete ancora spiegato.

8. Socket Docker: non è una semplice cartella condivisa

Con un Docker Engine tradizionale, eseguito come root, l’accesso al socket del daemon può equivalere al controllo amministrativo dell’host. Il gruppo docker va quindi trattato come un gruppo altamente privilegiato.

Controllate il socket e la definizione del gruppo:

ls -l /var/run/docker.sock

getent group docker

Verificate anche quali container ricevono il socket dell’host e se ne abbiano realmente bisogno. Un’applicazione compromessa con accesso al daemon può incidere su molto più del proprio container.

Se quell’accesso non serve, rimuovete il mount dalla configurazione e ricreate il container interessato. Rivedete anche le appartenenze al gruppo.

La configurazione rootless è un caso distinto: non va confusa con un utente ordinario che controlla un daemon eseguito come root.

Essere dentro un container non rende innocuo un collegamento al pannello di controllo dell’host.

La sicurezza comincia anche dalle cose noiose

L’obiettivo non è trasformare ogni file in qualcosa di inaccessibile. È fare in modo che ciascun account e servizio possa leggere, modificare ed eseguire soltanto ciò che gli serve.

Ripetete i controlli, conservate inventari attendibili e investigate le differenze. Dopo una correzione, verificate sia la restrizione sia il funzionamento dell’applicazione.

Soprattutto, smettiamo di considerare i permessi un dettaglio da sistemare quando ci sarà tempo.

Perché un sistema può avere tutte le difese del mondo e poi fidarsi dello script sbagliato.

Il 777 non è una soluzione. È una domanda rimandata: chi deve davvero poter fare cosa?

E poi, come sempre: mani in pasta.

Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.

Risorse: