Domande frequenti su Gentoo HardenedLa seguente è un insieme di domande raccolte dal canale IRC #gentoo-hardened e dalla mailing list gentoo-hardened. Come tale, è orientata a rispondere in modo celoce e conciso piuttosto che fornire una panoramica globale sulle tecnologie dietro a Gentoo Hardened. È consigliabile leggere il resto della documentazione presente sulla pagina del Progetto Gentoo Hardened e quella nelle homepage dei progetti per ottenere informazioni più approfondite. Domande Generali
Domande su PaX
Domande su Grsecurity
Domande su SELinux Cos'è esattamente una "toolchain"? Il termine "toolchain" si riferisce ad una combinazione di pacchetti software comunemente usati per costruire e sviluppare una particolare architettura. La toolchain a cui ci si riferisce nel canale IRC gentoo-hardened consiste di GNU Compiler Collection (GCC), binutils e della libreria GNU C (glibc). Cosa dovrei usare: RSBAC di grsecurity o SELinux? La risposta a questa domanda è altamente soggettiva, e dipende molto dai propri requisiti,così il progetto Gentoo hardened tenta semplicemente di presentare ogni tecnologia e lasciare la scelta all'utente. Questa decisione ha richiesto molte ricerche che sono state fiduciosamente e chiaramente inserite nella documentazione inerente l'hardened. Tuttavia per qualsiasi domanda specifica riguardo i modelli di sicurezza che ciascuno fornisce ci si senta liberi di interpellare gli svilupptori sul relativo canale IRC o attraverso mailing list. È possibile usare grsecurity, SELinux e PaX tutti contemporaneamente? Si, questa combinazione è possibile poichè PaX ed alcune delle caratteristiche di grsecurity funzionano con RSBAC di grsecurity e SELinux. Il solo conflitto che si può verificare è che si può usare un solo sistema di controllo degli accessi (che può essere o RBAC o SeLinux). È necessario passare alcune flag a LDFLAGS/CFLAGS per abilitare la compilazione hardened? No, la toolchain attuale implementa automaticamente l'equivalente di CFLAGS="-fPIE -fstack-protector-all" -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,now -Wl,-z,relro" attraverso le specifiche integrate di GCC ed usando i file delle specifiche per disabilitarli che risulta essere una soluzione più appropriata. PEr i vecchi utenti di hardened-gcc l'approccio migliore è migrare al nuovo profilo hardened e successivamente seguire i passaggi elencati nella domanda Come posso passare al profilo hardened?
Come posso disabilitare la compilazione hardened? A tale scopo si può utilizzare gcc-config:
Alternativamente si può raggiungere lo stesso risultato modificando CFLAGS:
Per disabilitare la compilazione SSP, di default quando si usa l'hardened toolchain, aggiungere -fno-stack-protector alla fine delle proprie CFLAGS.
Se si vuole disabilitare la compilazione di default PIE aggiungere -nopie alla fine delle proprie CFLAGS e alle proprie LDFLAGS (in quanto le LDFLAGS vengono usate senza CFLAGS quando gcc viene usato per collegare i file oggetto).
Se si vuole disabilitare il binding "now" predefinito accodare -z,lazy alle proprie LDFLAGS. Se si vuole disabilitare il binding "relro" predefinito accodare -z,norelro alle proprie LDFLAGS.
Ho appena scoperto il progetto hardened, devo installare tutto quello che trovo sulla pagina del progetto prima di installare Hardened Gentoo? No, il progetto Gentoo Hardened è una collezione di sottoprogetti che hanno tutti come obbiettivo la sicurezza. Mentre molti di questi progetti posso convivere l'uno al fianco dell'altro, alcuni sono in conflitto tra loro, come molte delle implementazioni delle ACL messe a disposizione da Hardened Gentoo. Perchè i miei programmi non vanno quando uso CFLAGS="-O3" e hardened gcc? È noto che l'utilizzo del flag di ottimizzazione -O3 in molte situzioni crea problemi al stack-smashing protector (SSP) e in compilazioni vanilla. Questo flag di ottimizzazione non è ufficialmente supportato e quindi ne viene scoraggiato l'uso dall'hardened team. Compilazioni dove l'utente fa uso di CFLAGS="-O3" vengono chiuse come INVALID/CANTFIX e/o ignorate. Come posso passare al profilo hardened? Per cambiare il proprio profilo usare eselect per selezionarlo.
Dopo aver impostato il profilo bisogna ricompilare il proprio sistema usando l'hardened toolchain in modo da avere una base consistente:
È stata aggiunta l'opzione --keep-going per assicurarsi che emerge non si interrompa in caso di fallimento nella compilazione di qualche pacchetto. È stato redatto un documento su come effettuare il debug con Gentoo Hardened (in inglese, ndT), pertanto seguire le raccomandazioni lì presente per risolvere il proprio problema. Perchè la flag jit è disabilita nel profilo hardened? JIT significa Just in Time Compilazione e consiste nel prendere del codice che si considera interpretato (come i bytecode Java o il codice Javascript), compilarlo in codice binario nativo in memoria e successivamente eseguire il codice compilato. Ciò significa che il programma ha bisogno di una sezione di memoria con permessi di scrittura ed esecuzione per scrivere e poi eseguire il codice che viene negato da PaX, a meno che la flag mprotect sia non impostata per l'eseguibile. Ne consegue la disabilitazione della flag use JIT come impostazione predefinita per evitare reclami e problemi di sicurezza. Si dovrebbe tenere a mente che avere una sezione in cui si scrive e viene eseguito qualcosa può essere un grave problema di sicurezza in quanto l'attaccante necessita di poter sfruttare un bug tra le fasi di scrittura ed esecuzione per scrivere in quella sezione in modo da eseguire qualunque codice egli desideri. Come posso abilitare la flag jit? Se è necessario, si raccomanda di abilitare la flag su basi per pacchetto usando /etc/portage/package.use
Tuttavia, è possibile abilitare la flag use globalmente usando /etc/make.conf
Questa è l'homepage di PaX. Quale documentazione Gentoo esiste riguardo PaX? Attualmente l'unica documentazione Gentoo riguardante PaX è la Guida rapida per PaX su Gentoo Hardened. Come funzionano i contrassegni ("marking", ndT) di PaX? I contrassegni ("marking", ndT) sono un modo per dire a PaX quali caratteristiche dovrebbe abilitare (o disabilitare) per un determinato binario. Le caratteristiche possono essere o abilitate, o disabilitate o non impostate. Abilitarle o disabilitarle rimpiazzare l'azione del kernel, così un binario con una caratteristica abilitata userà sempre quest'ultima e uno con la caratteristica disabilitata non la userà mai. Quando lo stato della caratteristica non è impostato il kernel sceglierà se abilitarla o disabilitarla. Come impostazione predefinita, il kernel hardened abiliterà quelle caratteristiche con solo due eccezioni, ovvero se la caratteristica non è supportata dall'architettura/kernel o se PaX è in esecuzione in modalità "Soft"- In quei due casi, essa verrà disabilitata.
Continuo ad ottenere il messaggio: "error while loading shared libraries: cannot make segment writable for relocation: Permission denied." Che cosa significa? Le "Text relocations" sono un modo con il quale i riferimenti nel codice dell'eseguibile ad indirizzi non conosciuti al momento della fase di link vengono risolti. Semplicemente essi scrivono solo l'indirizzo appropriato in fase di esecuzione marcando il segmento di codice come scrivibile in modo da cambiare l'indirizzo quando esso viene deselezionato. Questo può essere un problema in quanto un attaccante potrebbe provare a sfruttare un bug quando la text relocation avviene in modo da poter scrivere codice arbitrario nel segmento di testo che dovrebbe essere eseguito. Ciò inoltre significa che il codice verrà caricato su indirizzi fissi (non in posizioni indipendenti) che può essere altrettanto sfruttabile scavalcando le caratteristiche di casualità fornite da PaX. In quanto questo può essere innescato per esempio aggiungendo una libreria con text relocation a quelle caricate dall'eseguibile, PaX offre l'opzione CONFIG_PAX_NOELFRELOCS in modo da evitarle. Questa opzione è abilitata nel seguente modo:
Se si sta utilizzando la toolchain hardened la compilazione dei propri programmi genererà librerie PIC ELF che non conterranno text relocations. Tuttavia alcune librerie potrebbero ancora contenere text relocations per diverse ragioni (spesso una è la presenza di codice assembly gestito in maniera non corretta). Questo può rappresentare un punto di vulnerabilità in quanto un attaccante potrebbe sfruttare librerie non-PIC per eseguire il proprio shellcode. Librerie non PIC hanno anche un impatto negativo dal punto di vista dell'uso della memoria visto che annullano la condivisione di codice, obiettivo delle librerie condivise. Per eliminare questo errore e consentire ad i propri programmi di funzionare è necessario sacrificare la sicurezza e consentire la generazione di codice a runtime per quel programma. La caratteristica di PaX che consente di ottenere ciò è chiamata MPROTECT. Si può disabilitare MPROTECT su qualsiasi eseguibile che utilizzi librerie non-PIC. Per testare il proprio sistema per textrels si può utilizzare il programma scanelf reperibile in app-misc/pax-utils. Per informazioni su come usare il pacchetto pax-utils consultare la guida Gentoo a PaX Utilities.
Da quando ho iniziato ad usare PaX il codice Java/JIT non funziona, perchè? Come parte di questo progetto la Java virtual machine genera una quantità considerevole di codice a runtime, cosa che non rende PaX felice. Sebbene, con le versioni attuali di portage e java, portage contrassegni automaticamente i binari, è ancora necessario abilitare i contrassegni di PaX in modo che esso possa fare un'eccezione con essi ed avere paxctl installato così i contrassegni possono essere applicati ai binari (e rieseguire l'emerge di questi ultimi in modo da applicarli). This of course can't be applied to all packages linking with libraries with JIT code, so if it doesn't, there are two ways to correct this problem:
Quando si già si ha chpax installato si può dare:
Questa opzione modifica leggermente l' ELF header al fine di impostare correttamente le flag di PAX sui binari.
L'altro modo è usare la propria implementazione di sicurezza per ottenere ciò usando gli hook del kernel. Posso disabilitare le caratteristiche di PaX all'avvio? Sebbene non sia consigliato farlo eccetto quando si deve recuperare il sistema o per scopi di debug, è possibile cambiare alcuni comportamenti di Pax all'avvio tramite la linea di comando del kernel. Passare pax_nouderef nella linea di comando del kernel disabiliterà uderef che può causare problemi su alcuni ambienti virtualizzati e causare alcuni bug (a volte) con lo svantaggio di lasciare il kernel sprotetto contro deferenze in spazio utente indesiderate. Passare pax_softmode=1 nella linea di comando del kernel abiliterà la modalità "soft" che può risultare utile quando si avvia un sistema non predisposto con un kernel PaX. Nella modalità "soft" PaX disabiliterà la maggior parte delle caratteristiche come impostazione predefinita dove non specificato altrimenti tramite i contrassegni. Similmente, pax_softmode=0 disabiliterà la modalità "soft" se essa è stata abilitata nella configurazione. Dov'è l'home page di Grsecurity? Questa è l'homepage per Grsecurity. Quale documentazione Gentoo esiste riguardo Grsecurity? La maggior parte della documentazione Gentoo per Grsecurity è una rapida Guida a Grsecurity v2. Inoltre documentazione non-Gentoo su RSBAC può essere trovata nel manuale per RSBAC all'indirizzo http://www.rsbac.org/documentation/rsbac_handbook È stata scritto un documento con alcune informazioni su come funziona TPE in diverse configurazioni (in inglese, NdT). Posso usare Greecurity con un kernel recente non nel Gentoo tree? Abitualmente viene rilasciato una nuova versioni degli hardened sources non molto dopo un nuovo rilascio di una patch PaX/Grsecurity, pertanto l'opzione migliore è aspettare un po' in modo che il team del kernel possa adattare le patch ed infine testarle. Ricordarsi che non vengono supportati sorgenti di kernel che non provengono dal portage tree. Dove posso trovare le FAQ relative a SELinux? Ci sono alcune FAQ specifiche per SELinux. |
|