In questo articolo Indice dei contenuti 3 sezioni
Chi sceglie una distribuzione Linux convinto di aver trovato un sistema inattaccabile parte da un presupposto sbagliato, perché nessun sistema operativo può garantire l’immunità totale dalle compromissioni. Il punto non è tanto evitare che una vulnerabilità venga sfruttata, quanto capire cosa succede subito dopo. Un sistema può accumulare protezioni su protezioni e lasciare comunque spazio di manovra a chi riesce a ottenere privilegi elevati, ed è proprio lì che si gioca la partita vera della sicurezza informatica. Il ragionamento nasce da un’analisi che ripercorre il percorso di un utente attraverso diverse distribuzioni, fino ad approdare a Qubes OS. La domanda di partenza non era quale fosse la distribuzione più sicura in assoluto, ma come limitare i danni quando un’applicazione o un componente cede. Qubes risponde lavorando sulla separazione degli ambienti invece di puntare tutto sull’hardening.
Perché l’hardening non risolve tutto
Il kernel monolitico di Linux gestisce in modo diretto una quantità notevole di funzioni fondamentali, driver e moduli compresi. Un componente che lavora con privilegi kernel ha capacità enormemente superiori rispetto a un normale processo nello spazio utente. Tradotto: una vulnerabilità seria può produrre effetti che vanno ben oltre il programma inizialmente colpito. Non significa che il modello sia insicuro di per sé, significa che conta moltissimo a quale livello avviene la compromissione.
Le distribuzioni hanno a disposizione un arsenale di tecniche di mitigazione. ASLR, PIE, stack canary, seccomp, NX, SELinux. Strumenti che rendono più complicato sfruttare intere classi di vulnerabilità oppure restringono le operazioni che un processo può compiere. Utilissimi, senza dubbio. Però fanno un lavoro diverso da quello dell’isolamento vero e proprio. Anche i container, spesso citati come soluzione, hanno un limite strutturale rispetto alla virtualizzazione completa. I processi containerizzati condividono il kernel dell’host, quindi una falla in quello strato comune può far saltare il confine che si pensava di aver costruito.
Qubes OS e la logica dei compartimenti stagni
Qubes OS parte da un’idea diversa e usa Xen per eseguire le attività dentro domini separati, chiamati qubes. Applicazioni con livelli di fiducia differenti finiscono così in ambienti distinti. La documentazione ufficiale mette però in chiaro un aspetto: la separazione non protegge automaticamente i programmi che girano nello stesso dominio. Il vantaggio arriva dal confine tra un qube e l’altro, oltre che dalla riduzione delle risorse condivise. Nella pratica quotidiana il modello permette di tenere separate la navigazione, il lavoro di tutti i giorni e la gestione di informazioni delicate. Esistono meccanismi controllati per spostare file e dati da un dominio all’altro, più i qubes usa e getta pensati per le attività temporanee. La documentazione chiama questa impostazione security by compartmentalization. L’obiettivo dichiarato non è impedire ogni intrusione, ma fare in modo che la caduta di un ambiente non regali automaticamente le chiavi di tutti gli altri.
Non solo Qubes: altri approcci allo stesso problema
Lo stesso principio, con soluzioni tecniche diverse, si ritrova in progetti come Spectrum OS e Sculpt OS. Spectrum impiega macchine virtuali per separare le applicazioni. Sculpt si appoggia al framework Genode e a un’architettura costruita attorno a microkernel, capability e componenti isolati. Non sono distribuzioni Linux equivalenti a Qubes, ma condividono lo spostamento di prospettiva: meno attenzione alla protezione del singolo programma, più attenzione alla riduzione delle relazioni di fiducia tra i componenti. La differenza più concreta si vede nel momento dell’incidente. Una vulnerabilità non deve per forza trasformarsi in accesso libero a tutto il computer. Un’architettura compartimentata riduce le informazioni che finiscono nelle mani dell’aggressore e complica parecchio il tentativo di raggiungere risorse che stanno da un’altra parte. Il prezzo da pagare c’è ed è tangibile, perché la configurazione diventa più complessa e anche il semplice scambio di dati tra ambienti richiede passaggi in più. La sicurezza, vista così, diventa una questione di progettazione dei confini: meno fiducia implicita si concede, meno probabilità ci sono che un singolo errore si propaghi all’intero sistema.
Fonte: TecnoAndroid
