Sicurezza Linux spiegata semplice: root, sudo, permessi e firewall

Quando si parla di sicurezza Linux, si incontrano spesso due affermazioni apparentemente opposte. Da una parte si sente dire che Linux è un sistema sicuro. Dall’altra viene ricordato che nessun sistema operativo è completamente invulnerabile.

Entrambe le affermazioni contengono una parte di verità.

Linux può avere vulnerabilità, configurazioni sbagliate, applicazioni compromesse e utenti che eseguono operazioni pericolose. La sua sicurezza non dipende quindi da una presunta invulnerabilità, ma da un’architettura progettata per separare utenti, processi, privilegi e risorse.

La sicurezza Linux nasce dall’unione di diversi meccanismi: il modello multiutente, la distinzione tra utente normale e root, i permessi di file e directory, l’isolamento dei processi, il principio del minimo privilegio, il firewall, gli aggiornamenti e sistemi aggiuntivi come SELinux e AppArmor.

Nessuno di questi elementi è sufficiente da solo. È la loro collaborazione a ridurre il rischio che un errore, un programma difettoso o un attacco compromettano l’intero sistema.

La sicurezza Linux non è una singola funzione

Un errore comune è immaginare la sicurezza come un interruttore che può essere semplicemente attivato o disattivato.

In realtà, un sistema sicuro è il risultato di molte decisioni.

Quando un processo tenta di aprire un file, Linux deve prima capire con quale identità sta operando. Deve poi verificare i permessi associati al file e stabilire se quell’utente può leggerlo, modificarlo o eseguirlo.

Quando un’applicazione usa la memoria, il kernel deve impedire che possa accedere liberamente alle aree appartenenti ad altri processi o al kernel stesso.

Quando arriva una connessione dalla rete, il firewall può verificare se quel traffico è consentito.

Quando viene scoperta una vulnerabilità, gli aggiornamenti permettono di distribuire la correzione.

La sicurezza Linux è quindi una difesa a più livelli. Se uno dei controlli non è sufficiente, un altro può ancora limitare il danno.

Perché Linux è un sistema multiutente

Linux deriva dal mondo Unix, dove una stessa macchina poteva essere utilizzata contemporaneamente da più persone.

Per questo motivo non è stato progettato intorno all’idea di un singolo utente con accesso completo a tutto il sistema. Ogni persona può avere un proprio account, una propria home directory, gruppi di appartenenza e permessi differenti.

Il concetto di utente, però, non riguarda soltanto le persone.

Anche molti servizi Linux utilizzano account dedicati. Un server web può essere eseguito con un utente specifico, mentre un database può funzionare con un altro account ancora. Lo stesso vale per servizi di stampa, sistemi di logging, applicazioni di rete e altri componenti dello user space.

Questa separazione ha un obiettivo preciso: limitare i danni.

Se un server web viene compromesso, l’attaccante dovrebbe ottenere soltanto i privilegi dell’utente con cui quel servizio viene eseguito. Se il servizio non ha accesso alle home directory, ai file di configurazione globali o ai dati del database, il problema rimane più contenuto.

Il modello multiutente è quindi una delle fondamenta della sicurezza Linux, anche su un computer utilizzato da una sola persona.

Utente normale e root

La distinzione più importante nel modello di sicurezza Linux è quella tra utente normale e utente root.

L’utente normale viene utilizzato per le attività quotidiane. Può lavorare nella propria home directory, avviare applicazioni, creare documenti, navigare sul web e utilizzare le risorse per le quali ha ricevuto i permessi.

Root è invece l’amministratore del sistema.

L’utente root può installare e rimuovere software, modificare le configurazioni globali, gestire servizi, creare utenti, cambiare proprietari e permessi e intervenire su quasi ogni parte del sistema.

Questi privilegi sono necessari per amministrare Linux, ma rappresentano anche un rischio.

Quando un utente normale tenta di modificare un file critico, il kernel può bloccare l’operazione mostrando un errore di permesso negato. Root, invece, può superare molti di questi limiti.

Questo significa che un comando sbagliato eseguito come root può causare conseguenze molto più gravi rispetto allo stesso comando eseguito da un utente normale.

Root non è quindi un account da usare per comodità. È uno strumento amministrativo da utilizzare soltanto quando serve davvero.

Root non rende il sistema più sicuro

Avere privilegi più elevati non significa essere più protetti.

Significa soltanto avere più potere.

Un’applicazione sconosciuta eseguita come utente normale può comunque leggere o cifrare tutti i file accessibili a quell’account. Se la stessa applicazione viene avviata come root, può potenzialmente modificare configurazioni di sistema, servizi, account utente e file appartenenti ad altre persone.

Il problema non riguarda soltanto il malware. Anche un errore involontario può diventare distruttivo.

Prima di eseguire un comando con privilegi amministrativi conviene quindi chiedersi se l’operazione abbia realmente bisogno di root. Se il comando riguarda un file presente nella propria home directory, molto spesso la risposta è negativa.

Il principio del minimo privilegio

Il principio del minimo privilegio è una delle idee più importanti nella sicurezza informatica.

Un utente, un processo o un servizio dovrebbe ricevere soltanto i permessi necessari per svolgere il proprio compito. Non dovrebbe avere privilegi aggiuntivi per comodità o per evitare di configurare correttamente il sistema.

Se un’applicazione deve leggere una directory, non dovrebbe poter modificare tutto il filesystem.

Se un server web deve pubblicare alcuni file, non dovrebbe avere accesso alle cartelle personali degli utenti.

Se un amministratore deve eseguire un singolo comando privilegiato, non è necessario che mantenga aperta una sessione root per l’intera giornata.

Il minimo privilegio non impedisce ogni attacco, ma riduce l’impatto di errori e compromissioni. Più limitato è il potere di un processo, minori sono i danni che può provocare.

Che cos’è sudo

Il comando sudo permette a un utente autorizzato di eseguire una specifica operazione con privilegi elevati.

L’idea principale è che l’utente continui a lavorare normalmente senza privilegi amministrativi e richieda un’elevazione soltanto quando necessario.

Per esempio, l’installazione di un pacchetto, la modifica di un file dentro /etc o la gestione di un servizio di sistema richiedono normalmente autorizzazioni superiori a quelle di un utente comune.

In questi casi sudo consente di elevare temporaneamente i privilegi per il singolo comando.

Questo approccio è più sicuro rispetto all’uso continuo di una shell root. Riduce il tempo durante il quale si opera con privilegi elevati e rende più evidente quali operazioni hanno richiesto l’accesso amministrativo.

È importante, però, non considerare sudo come un prefisso da aggiungere automaticamente quando qualcosa non funziona.

Scrivere sudo significa concedere al comando un potere maggiore. Prima di farlo bisogna capire cosa sta per essere eseguito e perché sono necessari privilegi amministrativi.

Perché sudo non risolve tutti gli errori di permessi

Quando Linux mostra un errore di permesso negato, molti utenti provano immediatamente a ripetere il comando aggiungendo sudo.

In alcuni casi è corretto. Se si sta modificando una configurazione globale, aggiornando il sistema o intervenendo su un servizio, i privilegi amministrativi possono essere necessari.

In altri casi, però, sudo nasconde il problema invece di risolverlo.

Un file nella home directory potrebbe appartenere per errore a root. Una cartella potrebbe avere permessi sbagliati. Un programma eseguito precedentemente con sudo potrebbe aver creato file che l’utente normale non può più modificare.

Continuare a utilizzare sudo può peggiorare la situazione, creando altri file con proprietario errato.

La soluzione corretta consiste nel verificare il percorso, il proprietario, il gruppo e i permessi della risorsa coinvolta. La sicurezza richiede comprensione della causa, non soltanto autorizzazioni più elevate.

I permessi di file e directory

I permessi Linux stabiliscono chi può leggere, modificare o eseguire una risorsa.

Ogni file e directory ha un proprietario, un gruppo associato e una serie di permessi applicati al proprietario, al gruppo e agli altri utenti.

I permessi principali sono lettura, scrittura ed esecuzione, rappresentati rispettivamente dalle lettere r, w e x.

Su un file, la lettura permette di visualizzarne il contenuto, la scrittura consente di modificarlo e l’esecuzione permette di avviarlo come programma o script.

Sulle directory, il significato cambia leggermente. La lettura permette di vedere l’elenco dei nomi contenuti, la scrittura consente di creare, eliminare o rinominare elementi e l’esecuzione permette di attraversare la directory e utilizzarla all’interno di un percorso.

Questi permessi rappresentano una delle prime linee di difesa del sistema.

Un file di configurazione può essere leggibile da molti utenti ma modificabile soltanto da root. Un documento personale può essere accessibile soltanto al proprietario. Uno script può essere leggibile ma non direttamente eseguibile.

Perché chmod 777 è pericoloso

Il comando chmod 777 viene spesso suggerito come soluzione rapida quando un’applicazione non riesce ad accedere a un file o a una directory.

Il numero 7 rappresenta la combinazione dei permessi di lettura, scrittura ed esecuzione. Ripetuto tre volte significa concedere tutti questi permessi al proprietario, al gruppo e a tutti gli altri utenti.

In pratica, la risorsa diventa accessibile e modificabile da chiunque abbia accesso al sistema.

Questo può eliminare temporaneamente un errore, ma introduce un problema di sicurezza.

È come rimuovere tutte le serrature da una stanza perché una persona non possiede la chiave corretta.

La soluzione dovrebbe invece consistere nell’identificare chi deve utilizzare la risorsa e assegnare soltanto i permessi necessari. A volte bisogna correggere il proprietario, altre volte è opportuno usare un gruppo condiviso, altre ancora basta modificare uno specifico permesso.

chmod 777 dovrebbe essere considerato un segnale d’allarme, non una soluzione universale.

I processi hanno un’identità

Quando un programma viene avviato, diventa un processo.

Ogni processo Linux è associato a un utente e a uno o più gruppi. Di conseguenza eredita i privilegi dell’identità con cui è stato avviato.

Se un editor di testo viene aperto da un utente normale, potrà accedere ai file consentiti a quell’utente. Se viene avviato con sudo, avrà privilegi molto più elevati.

Il kernel verifica l’identità del processo quando questo tenta di aprire file, creare connessioni di rete, accedere a dispositivi, inviare segnali o modificare risorse del sistema.

Non è quindi soltanto la persona ad avere dei permessi. Anche ogni programma in esecuzione opera all’interno di un perimetro definito.

Isolamento dei processi e della memoria

Linux cerca anche di separare i processi tra loro.

Ogni processo lavora normalmente dentro un proprio spazio di memoria virtuale. Non dovrebbe poter leggere o modificare liberamente la memoria appartenente ad altri programmi.

La CPU e il kernel applicano protezioni sulle aree di memoria e impediscono l’accesso a zone non autorizzate.

Se un’applicazione tenta di utilizzare un indirizzo non valido, può terminare con un errore invece di modificare casualmente i dati dell’intero sistema.

Questo isolamento aumenta sia la stabilità sia la sicurezza.

Un programma che si blocca non dovrebbe trascinare con sé tutti gli altri processi. Allo stesso modo, un’applicazione compromessa non dovrebbe poter leggere direttamente password o dati presenti nella memoria di un altro processo.

L’isolamento non è assoluto e possono esistere vulnerabilità, ma costituisce comunque una barriera fondamentale.

Perché i servizi devono avere privilegi limitati

I servizi Linux sono spesso componenti esposti alla rete oppure attivi continuamente in background.

Per questo motivo devono essere configurati con particolare attenzione.

Un server web dovrebbe poter leggere i file del sito e comunicare attraverso le porte necessarie, ma non dovrebbe avere accesso completo al sistema.

Un database dovrebbe poter gestire i propri file, ma non dovrebbe leggere liberamente le home directory degli utenti.

Molti servizi vengono quindi eseguiti con account dedicati. Se il servizio viene compromesso, l’attaccante ottiene inizialmente soltanto i privilegi di quell’account.

Systemd può inoltre aggiungere ulteriori restrizioni, limitando l’accesso al filesystem, alle risorse hardware, alla rete o ad alcune funzionalità del kernel.

Anche in questo caso viene applicato il principio del minimo privilegio: ogni servizio deve poter fare soltanto ciò per cui è stato progettato.

SELinux spiegato semplice

I normali permessi Unix sono fondamentali, ma non sempre permettono di descrivere politiche di sicurezza molto dettagliate.

SELinux, abbreviazione di Security-Enhanced Linux, aggiunge un ulteriore sistema di controllo degli accessi.

In modo semplificato, SELinux assegna contesti o etichette ai processi e alle risorse. Una politica stabilisce poi quali interazioni sono consentite.

Un processo potrebbe quindi avere i normali permessi per leggere un file, ma essere comunque bloccato dalla politica SELinux.

Questo modello è utile per confinare i servizi.

Un server web può essere autorizzato a leggere le pagine del sito, ma non altri file del sistema. Anche se una configurazione dei permessi tradizionali risultasse troppo permissiva, SELinux potrebbe ancora impedire l’accesso.

SELinux è molto potente e può sembrare complesso, ma il concetto fondamentale è semplice: non conta soltanto chi possiede il file. Conta anche il ruolo che il processo dovrebbe svolgere secondo la politica di sicurezza.

AppArmor spiegato semplice

AppArmor ha un obiettivo simile a quello di SELinux: limitare ciò che un’applicazione può fare oltre i normali permessi.

Utilizza profili associati ai programmi. Un profilo può indicare quali file possono essere letti o modificati, quali operazioni sono consentite e quali risorse possono essere utilizzate.

AppArmor viene spesso considerato più immediato da leggere perché molte regole fanno riferimento direttamente ai percorsi del filesystem.

SELinux e AppArmor adottano approcci differenti, ma condividono una stessa idea: un programma dovrebbe restare confinato all’interno del comportamento previsto.

Se un’applicazione compromessa tenta di accedere a una risorsa non autorizzata, il sistema può bloccare l’operazione e registrare l’evento.

Il ruolo del firewall Linux

Il firewall controlla il traffico di rete che attraversa il sistema.

Può limitare le connessioni in ingresso, bloccare porte che non devono essere raggiungibili e consentire l’accesso soltanto da determinati indirizzi o reti.

Nel kernel Linux, molte funzionalità di filtraggio sono fornite da netfilter. Strumenti come nftables, firewalld e UFW permettono di configurare queste regole con modalità differenti.

Il firewall riduce la superficie di attacco impedendo l’accesso ai servizi che non devono essere esposti.

Non può però correggere una vulnerabilità presente in un servizio che deve rimanere accessibile. Se un server web vulnerabile è pubblicato su Internet, il firewall deve consentire il traffico verso quella porta e non può sostituire l’aggiornamento o una configurazione corretta.

Il firewall è quindi una barriera importante, ma deve essere utilizzato insieme agli altri livelli di sicurezza.

Gli aggiornamenti sono parte della sicurezza

Un sistema non rimane sicuro soltanto perché è stato configurato correttamente durante l’installazione.

Nel tempo vengono scoperte vulnerabilità nel kernel, nelle librerie, nei servizi e nelle applicazioni.

Gli aggiornamenti distribuiscono le correzioni necessarie.

Uno dei vantaggi delle distribuzioni Linux è la presenza di repository centralizzati. Il gestore pacchetti può aggiornare in modo coordinato molti componenti del sistema, incluse librerie condivise utilizzate da numerose applicazioni.

Sui server gli aggiornamenti devono essere pianificati e testati, ma rimandarli indefinitamente significa mantenere aperti problemi già conosciuti.

Alcuni aggiornamenti richiedono il riavvio di un servizio. Altri, come quelli del kernel o di componenti particolarmente importanti, possono richiedere il riavvio dell’intero sistema.

Anche il riavvio, quando necessario, fa parte della corretta manutenzione della sicurezza.

Installare software da fonti affidabili

La provenienza del software è un altro elemento essenziale.

I repository ufficiali delle distribuzioni forniscono una catena di distribuzione più organizzata rispetto al download casuale di programmi da siti sconosciuti.

Il gestore pacchetti verifica le firme dei repository, controlla le dipendenze, gestisce le versioni e tiene traccia dei file installati.

Questo non garantisce l’assenza assoluta di vulnerabilità, ma riduce il rischio di installare software modificato, obsoleto o incompatibile.

Quando possibile, è preferibile utilizzare i repository indicati dalla distribuzione o le fonti ufficiali del progetto.

Aggiungere repository di provenienza incerta o copiare comandi trovati casualmente su Internet può compromettere la sicurezza dell’intero sistema.

Attenzione agli script scaricati da Internet

Uno script non è semplice testo innocuo.

È codice che può essere eseguito dal sistema.

Può leggere file, modificarli, cancellarli, scaricare altri programmi, creare utenti, cambiare permessi e modificare configurazioni.

Se viene eseguito con sudo, tutte queste operazioni possono essere effettuate con privilegi amministrativi.

Prima di eseguire uno script scaricato da Internet è quindi importante verificarne la provenienza, leggerne il contenuto quando possibile e capire almeno a grandi linee quali comandi verranno eseguiti.

Particolare attenzione meritano i comandi che scaricano uno script e lo inviano direttamente a una shell. In quel caso il codice viene eseguito senza essere prima salvato e controllato localmente.

Non significa che ogni procedura di questo tipo sia necessariamente malevola. Significa che si sta scegliendo di fidarsi completamente della fonte e del contenuto ricevuto in quel momento.

Aggiungere sudo alla cieca rende il rischio ancora maggiore.

La sicurezza Linux come difesa a più livelli

Possiamo ora ricostruire il quadro completo.

L’identità stabilisce quale utente o servizio sta operando. I permessi controllano l’accesso a file e directory. Il minimo privilegio limita il potere di utenti e processi. L’isolamento della memoria separa le applicazioni. SELinux o AppArmor aggiungono politiche più dettagliate. Il firewall riduce il traffico consentito. Gli aggiornamenti correggono vulnerabilità conosciute.

Nessun controllo è perfetto.

Un file può avere permessi sbagliati. Un servizio può contenere una vulnerabilità. Una regola firewall può essere configurata male. Un aggiornamento può essere rimandato.

La difesa in profondità serve proprio a evitare che il fallimento di una singola barriera comprometta immediatamente tutto il sistema.

Esempio completo: proteggere un server web

Un server web rappresenta un buon esempio di sicurezza a più livelli.

Il servizio dovrebbe essere eseguito con un utente dedicato, non con root per tutte le sue attività.

I file del sito devono avere proprietari e permessi coerenti. Il server dovrebbe poter leggere i contenuti da pubblicare e scrivere soltanto nelle directory in cui è realmente necessario.

Il processo può essere ulteriormente confinato tramite systemd, SELinux o AppArmor.

Il firewall dovrebbe consentire soltanto le porte necessarie, come quelle utilizzate dal servizio web e dall’amministrazione autorizzata.

Il sistema operativo, il server web e le relative librerie devono essere mantenuti aggiornati.

I log devono essere controllati per individuare errori, tentativi di accesso anomali o comportamenti inattesi.

Nessuno di questi elementi rende il server sicuro da solo. È la loro combinazione a ridurre la probabilità e l’impatto di una compromissione.

Cinque regole pratiche per usare Linux in sicurezza

Per utilizzare Linux in modo più consapevole non è necessario diventare immediatamente esperti di cybersecurity.

Le regole fondamentali sono semplici: lavorare normalmente con un utente non privilegiato, utilizzare sudo soltanto quando serve davvero, assegnare permessi precisi, installare software da fonti affidabili e mantenere aggiornato il sistema.

È inoltre importante evitare scorciatoie come chmod 777, non disattivare SELinux o AppArmor soltanto perché un’applicazione non funziona e non eseguire script sconosciuti con privilegi amministrativi.

La domanda da porsi dovrebbe essere sempre la stessa: questo utente, processo o servizio ha davvero bisogno di tutto questo accesso?

Conclusione

Linux offre un modello di sicurezza solido perché separa utenti, processi, memoria, file, servizi e traffico di rete.

Root dispone di privilegi molto elevati, ma proprio per questo deve essere utilizzato con attenzione.

sudo permette di ottenere privilegi temporanei senza lavorare continuamente come amministratore.

I permessi proteggono file e directory, mentre l’isolamento dei processi limita le interferenze tra programmi.

SELinux e AppArmor possono aggiungere regole più dettagliate. Il firewall riduce i servizi esposti. Gli aggiornamenti correggono vulnerabilità note.

La sicurezza Linux non deriva quindi da un singolo strumento e non è una condizione raggiunta una volta per tutte.

È un processo continuo fatto di configurazione, manutenzione e uso consapevole dei privilegi.

Nel prossimo episodio della serie Capire Linux vedremo che cosa cambia tra distribuzioni come Ubuntu, Debian, Fedora, Arch e Linux Mint, e perché sistemi basati sullo stesso kernel possono adottare strumenti, repository, cicli di aggiornamento e politiche di sicurezza differenti.