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).
La risposta a questa domanda è altamente soggettiva, 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.
Si, questa combinazione è possibile poichè PaX può lavorare con grsecurity, RSBAC e SELinux. Il solo conflitto che si può verificare è che si può usare un solo sistema di controllo degli accessi.
No, la toolchain attuale implementa automaticamente l'equivalente di
# emerge --oneshot binutils gcc virtual/libc # emerge -e world
A tale scopo si può utilizzare
# gcc-config -l [1] i686-pc-linux-gnu-3.4.4 * [2] i686-pc-linux-gnu-3.4.4-hardenednopie [3] i686-pc-linux-gnu-3.4.4-hardenednopiessp [4] i686-pc-linux-gnu-3.4.4-hardenednossp [5] i686-pc-linux-gnu-3.4.4-vanillaPer disabilitare la compilazione SSP passare al profilo hardenednossp: # gcc-config i686-pc-linux-gnu-3.4.4-hardenednossp
Alternativamente si può raggiungere lo stesso risultato modificando CFLAGS:
Per disabilitare la compilazione SSP, di default quando si usa l'hardened
toolchain, aggiungere
Se si vuole disabilitare la compilazione di default PIE aggiungere
Per utilizzare PaX su sorgenti hardened, è necessario abilitare grsecurity nella configurazione del proprio kernel. Questo potrebbe essere corretto in future versioni del kernel.
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.
E' noto che l'utilizzo del flag di ottimizzazione
Recentemente i vecchi bootstrap.sh e bootstrap-2.6.sh sono stati deprecati. Al loro posto bootstrap-cascade.sh è stato rinominato bootstrap.sh.
# cd /etc # rm make.profile # ln -s ../usr/portage/profiles/hardened/x86 make.profile(Per i kernel 2.4) # ln -s ../usr/portage/profiles/hardened/x86/2.6 make.profile(Per i kernel 2.6)
Dopo aver impostato il profilo bisogna ricompilare il proprio sistema usando l'hardened toolchain in modo da avere una base consistente:
# emerge --oneshot binutils gcc virtual/libc # emerge -e world
La prima cosa da sottolineare è che GDB non può risolvere i simboli in PIEs; non riesce a capire che gli indirizzi sono relativi in PIEs, non assoluti. Questo si manifesta quando, per esempio, si tenta di fare un backtrace e viene visualizzato un flusso di linee di '??' dove dovrebbero essere i simboli.
Per aggirare questo, eseguire la fase finale di linkaggio con
Un'altra maniera per fare ciò consiste nel fare l'emerge di =sys-devel/gdb-6.3-r5, che contiene una patch particolare che rende possibile il debug di eseguibili lincati con -pie
Il secondo punto è che PaX potrebbe impedire a GDB di creare breakpoints, a
seconda della configurazione del kernel. Questo include anche il breakpoint nel
main di cui si necessita come punto di partenza. Per impedire a PaX di
comportarsi in questo modo gli eseguibili da debuggare necessitano dei flag
# /sbin/paxctl -m foo
A questo punto si dovrebbe essere pronti per partire! Avviate gdb come sempre e buona fortuna.
L'home page è reperibile all'indirizzo
Attualmente l'unica documentazione Gentoo riguardante PaX è la PaX
quickstart guide reperibile presso l'indirizzo
Questo errore si manifesta quando viene abilitato CONFIG_PAX_NOELFRELOCS nel seguente modo:
Non-executable page -> [*] Disallow ELF text relocations
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
Come parte di questo progetto la Java virtual machine genera una quantità considerevole di codice a runtime, cosa che non rende PaX felice. Ci sono due maniere per correggere questo problema:
# emerge chpax # /etc/init.d/chpax start
O se già si ha
# chpax -pemrxs /opt/*-jdk-*/{jre,}/bin/*
Entrambe queste opzioni modificano leggermente l' ELF header al fine di impostare correttamente i falgs di PAX sui binari.
Con RSBAC si possono etichettare tutti i file Java utilizzando il seguente comando.
# for i in $(ls /opt/*(jdk|sdk)*/{jre,}/bin/*);do attr_set_file_dir FILE $i pax_flags pmerxs;done
L'homepage di grsecurity è reperibile all'indirizzo
La documentazione più aggiornata su grsecurity è la Grsecurity2 quickstart
guide, reperibile all'indirizzo
Sono stati apportati dei cambiamenti significativi nel kernel 2.6.8 che hanno
compromesso Pax, per i kernel 2.6.8.1 e 2.6.9 non sono diponibili patch ne per
per PaX ne per grsecurity. Anche se per il kernel 2.6.10 è disponibile una
patch sperimentale è bene prendere in considerazione la posizione ufficiale del
team PaX nei confronti del kernel 2.6 prima di utilizzarlo:
L'homepage di RSBAC è reperibile all'indirizzo
Tutta la documentazione Gentoo inerente RSBAC è reperebile presso la pagina
del sottoprogetto RSBAC all'indirizzo
Inoltre documentazione non-Gentoo su RSBAC può essere trovata nell'handbook
per RSBAC all'indirizzo
Per usare un ramdisk iniziale con un kernel abilitato per RSBAC è necessario abilitare una particolare opzione, altrimenti RSBAC tratterà l'initrd come il root device:
[*] Delayed init for initial ramdisk
FAQ specifiche per SELinux possono essere reperite all'indirizzo