Introduzione a Gentoo HardenedQuesta guida è indicata per chi non conosce a fondo il progetto Gentoo "Hardened" ("temprato,indurito", ndT) , quali sono le possibilità che offre, come queste interagiscono e quali sono i loro rispettivi compiti all'interno del progetto. La nozione principale sulla sicurezza su cui si pone l'accento è quello dei livelli di sicurezza. I livelli sono fondamentali nel garantire che il sistema di un utente non venga compromesso, e nel caso in cui ciò accada, nel minimizzare i possibili danni. Combinando una serie di tecnologie diverse, benchè tutte incentrate sulla sicurezza, si obbliga l'attaccante a superare ulteriori prove per compromettere un sistema. Per questo motivo si raccomanda sempre di decidere quali siano le proprie necessità e di combinare tali soluzioni per proteggere il proprio sistema. In questa guida si cercherà di esporre le varie opzioni disponibili e come queste si possano utilizzare contemporaneamente. Gentoo Hardened non è un prodotto nè la soluzione in sé, ma è semplicemente un progetto in cui un gruppo di sviluppatori lavora insieme per raggiungere l'obiettivo di una migliore sicurezza. I sotto-progetti contenuti in Gentoo Hardened non hanno nessun altro legame tra loro se non quello di appartenere allo stesso progetto. Si può pensare a questo allo stesso modo per cui KDE e GNOME fanno entrambi parte del progetto desktop e hanno un obiettivo comune, ma sono comunque indipendenti l'uno dall'altro.
Il cuore del progetto è PaX. PaX è una patch del kernel che permette di proteggersi da attacchi di tipo buffer o heap overflow e simili. PaX è la prima linea di difesa. A causa di software mal progettato si è sempre a rischio di compromissione da parte di attacchi chiamati buffer e heap overflow; questi tipi di overflow sono causati dalla mancanza di controlli sull'input inserito dall'utente in un'applicazione. Quando l'attaccante è in grado, in un'applicazione, di immettere input che viene inserito in memoria senza essere prima controllato, nasce la possibilità di un overflow. Linguaggi di programmazione a basso livello come C o C++ non proteggono automaticamente dai buffer overrun, e il risultato è che quando si inseriscono più dati di quanti il buffer ne possa contenere, il codice eseguibile ad esso adiacente può essere sovrascritto con l'input dell'utente. Questo normalmente dovrebbe causare il crash dell'applicazione se l'input dell'utente non è comprensibile alla macchina. Generalmente questo problema si manifesta in un page fault, in quanto i caratteri che hanno superato la dimensione del buffer e sono interpretati come codice eseguibile vengono trattati come un indirizzo che probabilmente non esiste. Questo è l'effetto meno nocivo di un overrun. Se l'attaccante conosce la presenza di un overrun, tuttavia, ha la possibilità di aggiungere all'input un shellcode ed invece di causare il crash dell'applicazione, può fare in modo che esso esegua istruzioni arbitrarie. Questo accade perchè i shellcode sono la modalità con cui le istruzioni vengono salvate in memoria per l'esecuzione da parte del processore. In pratica il shellcode consiste in 'opcodes', codici in linguaggio macchina che specificano l'operazione prossima ad essere eseguita; questi vengono tradotti in routine assembly. L'attaccante ha un'ottima conoscenza di questi opcode ed è in grado di creare un shellcode che gli permette di fare qualunque cosa desideri, come ad esempio aprire una shell root e associarla ad una porta. Quando questo accade, l'utente non ne è minimamente consapevole poichè l'applicazione non termina, ed invece comincia ad eseguire il codice arbitrario dell'attaccante permettendogli qualunque azione sul sistema. PaX attenua questo problema allocando in modo casuale ogni funzione e buffer dell'applicazione in memoria. Questa tecnica è chiamata ASLR (Address Space Layout Randomization) ed è la base fondamentale su cui si fonda PaX. Avendo offset, cioè posizioni nella memoria, casuali per le funzioni e i buffer, l'attaccante non è in grado di creare un input che gli assicuri l'esecuzione del shellcode (rendendo invece quest'operazione molto difficile in quanto probabilmente l'applicazione andrà in crash e verrà riavviata con nuovi offset). L'ASLR è ancora più utile se utilizzata con codice PIE (Position Indipendent Executable, cioè eseguibile indipendente dalla posizione) ma funziona anche con codice standard pena un overhead. PaX inoltre offre la possibilità di avere sia segmenti di codice che hanno permessi di esecuzione e non di scrittura che segmenti che hanno permessi di scrittura e non di esecuzione. Questa tecnica è chiamata pageexec. Nei processori basati su x86 non è possibile utilizzarla a livello hardware in quanto gli sviluppatori dell'x86, per risparmiare spazio, hanno deciso di utilizzare la stessa flag per segnalare i permessi di scrittura e di esecuzione. Dato che una zona di memoria può essere o scrivibile o leggibile ed eseguibile non è molto utile togliere i permessi di esecuzione ai buffer perchè questo li renderebbe non più leggibili. Per questa ragione, su x86 PaX emula questo comportamento a livello software, introducendo un overhead ma incrementando di molto la sicurezza. Per aumentare la chiarezza, anche se generalmente si parla di PIE e SSP come di un'unica entità perchè entrambi fanno parte della toolchain hardened, bisogna chiarire che sono senz'altro tecnologie diverse con diversi obiettivi. PIE, di per sé, non fornisce misure di sicurezza aggiuntive, ma quando è combinata nel kernel con PaX diventa un mezzo molto potente per difendersi contro gli overflow. SSP è invece interamente implementato a livello utente e protegge contro gli attacchi che hanno come obiettivo lo stack senza il supporto del kernel. Dato che PIE e SSP sono implementati separatamente e fanno cose diverse, sono indubbiamente due diversi livelli di protezione: per esempio, un attacco chiamato ret2libc che potrebbe superare PaX, sarebbe fermato da SSP. Si sono dovute superare molte difficoltà per fornire agli utenti un modo semplice per creare un ambiente interamente costituito da codice PIE in cui si possa usufruire dell'ASLR con overhead minimo. Oltre a PIE, la toolchain 'hardened' è dotata anche di SSP (Stack Smashing Protection). Per proteggere dallo stack smashing, SSP alloca un'area di memoria all'esterno dei buffer e vi inserisce un canary (o un marker) casuale crittografato. Questo permette all'SSP di controllare se il canary è stato sovrascritto dopo ogni fase di scrittura nel buffer e se ciò è accaduto, di terminare l'applicazione. La toolchain hardened fornisce nel modo più facile possibile un ambiente PIE/SSP a livello utente. Gli stage denominati 'hardened' sono stage standard compilati con PIE e SSP e non includono controlli degli accessi di tipo SELinux, RSBAC e grsecurity. Controllo obbligatorio degli accessi Se PaX è il primo livello di protezione, forse anche il secondo o il terzo se si dispone di un firewall e/o di un sistema di rilevazione delle intrusioni, si raccomanda fortemente di utilizzare il controllo degli accessi per rendere ancora più sicuro il proprio sistema. È molto importante rendersi conto che il controllo degli accessi rappresenta l'ultimo livello di protezione. Il controllo degli accessi è molto utile per porre dei limiti ad attaccanti che hanno già ottenuto accesso al vostro sistema, o ad utenti locali. Al momento attuale Gentoo Hardened supporta tre soluzioni di controllo: SELinux, grsecurity e RSBAC. Se si desidera utilizzare grsecurity non ci si deve preoccupare di quale stage sia stato utilizzato perchè esso non richiede modifiche nello spazio utente. Si deve semplicemente utilizzare lo stage hardened e compilare il kernel utilizzandone uno in cui grsecurity sia attivo, come ad esempio quello hardened-sources. Una volta che il sistema è in funzione, si può utilizzare la "learning mode" di grsecurity per costruire la lista di controllo degli accessi per il proprio sistema. Come per grsecurity, anche RSBAC non richiede nessuna modifica nello spazio utente ma può essere installato dopo aver configurato un sistema Gentoo standard. RSBAC è supportato dal kernel rsbac-sources. Quando il sistema funziona, è possibile scegliere tra i vari modelli di controllo degli accessi che offre RSBAC, dal momento che sono costituiti da moduli. La documentazione Gentoo su RSBAC riporta una lista dei vari modelli offerti insieme ad una descrizione più esauriente di ognuno di essi. Oltre ai due livelli di sicurezza che sono stati descritti, ne verrano sicuramente aggiunti altri in futuro. Esempi di livelli aggiuntivi sono la prevenzione / rilevamento delle intrusioni, che diventerebbe il primo livello addirittura prima di PaX. Dischi e swap criptati, che offrono una protezione dalle vulnerabilità 'fisiche' della sicurezza. Auditing, che permetterebbe di vedere e agire contro le minacce prima che queste possano compromettere il sistema. Il traffico criptato nelle reti e misure rigide di autenticazione sono ulteriori livelli di sicurezza supportati appieno dalla maggior parte delle installazioni Linux ma qui non verranno trattati a fondo.
|
|