Gentoo Logo

Domande frequenti su Gentoo Hardened

Indice:

1.  Domande

Introduzione

La 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

2.  Domande Generali

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?

Nota: Abilitare manualmente le flag di hardening è assolutamente non raccomandato.

Nota: Inviare una flag -fno... disabiliterà la flag, e anche fstack-protector-all e -fstack-protector potrebbero interferire se passate direttamente.

Nota: Gentoo si occuperà di applicare delle patch al relativo GCC per permettere che gli specfiles possano essere passati attraverso variabili di ambiente. Attualmente sono installati nel sistema Gentoo diversi tipi di specfile che permettono agli utenti che utilizzano le architetture supportate di abilitare o meno le funzionalità della toolchain in maniera semplice. Per accedere gli specs come l'utente finale si può far uso dell'utilità gcc-config.

Come posso disabilitare la compilazione hardened?

A tale scopo si può utilizzare gcc-config:

Codice 2.1: Esempio di output di gcc-config

# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.4 *
 [2] x86_64-pc-linux-gnu-4.4.4-hardenednopie
 [3] x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
 [4] x86_64-pc-linux-gnu-4.4.4-hardenednossp
 [5] x86_64-pc-linux-gnu-4.4.4-vanilla

Per disabilitare la compilazione PIE passare al profilo hardenednopie:
# gcc-config x86_64-pc-linux-gnu-4.4.4-hardenednopie
Per disabilitare la compilazione SSP passare al profilo hardenednossp:
# gcc-config x86_64-pc-linux-gnu-4.4.4-hardenednossp
Per disabilitare la compilazione SSP e PIE passare al profilo hardenednopiessp:
# gcc-config x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
Per disabilitare tutte le compilazioni hardened passare al profilo vanilla:
# gcc-config x86_64-pc-linux-gnu-4.4.4-vanilla
Per i cambiamenti nelle sessioni attive occorre eseguire anche
# source /etc/profile

Nota: L'output precedente potrà variare in base alla versione di gcc e all'architettura in uso, inoltre i comandi richiesti per disabilitare le varie opzioni possono dipendere dall'output del primo comando.

Alternativamente si può raggiungere lo stesso risultato modificando CFLAGS:

Importante: Disabilitare manualmente le flag non è raccomandato dal team e viene considerata un'opzione non supportata, pertanto usarla a proprio rischio e pericolo.

Per disabilitare la compilazione SSP, di default quando si usa l'hardened toolchain, aggiungere -fno-stack-protector alla fine delle proprie CFLAGS.

Nota: Nei rilasci di gcc 3.4 bisogna usare -fno-stack-protector-all -fno-stack-protector

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).

Importante: Il flag -fno-pic non dovrebbe essere usato perchè abilita il codice non-PIC. Invece, usando -nopie, si ritorna al comportamento del vanilla GCC che dovrebbe essere il risultato cercato.

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.

Nota: Relro è l'impostazione predefinita su binutils pertanto assicurarsi di volerla disabilitare prima di farlo.

Nota: Se si è interessati ad usare per-package CFLAGS con Portage allora è interessante leggere a proposito di script solar sviluppato per lavorare con questo: http://article.gmane.org/gmane.linux.gentoo.hardened/1204

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.

Nota: Per reperire informazioni migliori su come cambiare il proprio profilo è raccomandabile leggere la parte 1, capitolo 6 "Installare il sistema base Gentoo" del Manuale Gentoo

Codice 2.2: Impostare make.profile

# eselect profile list
[1]   default/linux/amd64/10.0
[2]   default/linux/amd64/10.0/desktop
[3]   default/linux/amd64/10.0/desktop/gnome *
[4]   default/linux/amd64/10.0/desktop/kde
[5]   default/linux/amd64/10.0/developer
[6]   default/linux/amd64/10.0/no-multilib
[7]   default/linux/amd64/10.0/server
[8]   hardened/linux/amd64
[9]   hardened/linux/amd64/no-multilib
[10]  selinux/2007.0/amd64
[11]  selinux/2007.0/amd64/hardened
[12]  selinux/v2refpolicy/amd64
[13]  selinux/v2refpolicy/amd64/desktop
[14]  selinux/v2refpolicy/amd64/developer
[15]  selinux/v2refpolicy/amd64/hardened
[16]  selinux/v2refpolicy/amd64/server
# eselect profile set 8 (sostituire 8 con il profilo hardened desiderato)

Nota: L'output precedente potrà variare in base alla versione di gcc e all'architettura in uso, inoltre i comandi richiesti per disabilitare le varie opzioni possono dipendere dall'output del primo comando.

Dopo aver impostato il profilo bisogna ricompilare il proprio sistema usando l'hardened toolchain in modo da avere una base consistente:

Codice 2.3: Passaggio all'hardened toolchain

# emerge --oneshot binutils gcc virtual/libc
Assicurarsi che sia in uso la toolchain hardened (la versione di gcc può cambiare):
# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.4 *
 [2] x86_64-pc-linux-gnu-4.4.4-hardenednopie
 [3] x86_64-pc-linux-gnu-4.4.4-hardenednopiessp
 [4] x86_64-pc-linux-gnu-4.4.4-hardenednossp
 [5] x86_64-pc-linux-gnu-4.4.4-vanilla
Selezionare la versione hardened, se non lo è già
# gcc-config x86_64-pc-linux-gnu-4.4.4
# source /etc/profile
Reinstallare il sistema
# emerge -e --keep-going system
# emerge -e --keep-going world

È stata aggiunta l'opzione --keep-going per assicurarsi che emerge non si interrompa in caso di fallimento nella compilazione di qualche pacchetto.

Come faccio il debug con gdb?

È 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

Codice 2.4: Esempio di abilitazione JIT per alcuni pacchetti in /etc/portage/package.use

x11-libs/qt-core jit
x11-libs/qt-script jit
x11-libs/qt-webkit jit

Tuttavia, è possibile abilitare la flag use globalmente usando /etc/make.conf

Codice 2.5: Esempio di /etc/make.conf con JIT abilitato

CFLAGS="-O2 -pipe -fomit-frame-pointer -march=native"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="x86_64-pc-linux-gnu"
# These are the USE flags that were used in addition to what is provided by the
# profile used for building.
#Se si hanno ulteriori use dovrebbe essere sufficiente aggiungere jit alla fine
USE="jit"

MAKEOPTS="-j2"

GENTOO_MIRRORS="ftp://ftp.udc.es/gentoo/"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

Importante: Ricordarsi che se si vuole abilitare codice JIT su PaX bisognera disabilitare mprotect sui binari che usano tale codice, sia attraverso i binari stessi o attraverso le librerie. Controllare la domanda di Pax su Java e JIT per vedere come farlo

3.  Domande su PaX

Dov'è l'homepage di PaX?

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.

Nota: Per poter ottenere la modalità "Soft", il proprio kernel dovrebbe avere la caratteristica abilitata e la si dovrebbe abilitare o passando pax_softmode=1 alla riga di comando del kernel o impostando ad 1 l'opzione in /proc/sys/kernel/pax/softmode.

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:

Codice 3.1: Opzione di Menuconfig

-> Security options
  -> PaX
    -> Enable various PaX features
      -> Non-executable pages
        [*] Restrict mprotect()
        [*]   Allow 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 scanelf reperibile in app-misc/pax-utils. Per informazioni su come usare il pacchetto pax-utils consultare la guida Gentoo a PaX Utilities.

Nota: Le versioni più recenti di sys-apps/portage(>=2.0.53) operano controlli riguardo alla text relocation e stampano un messaggio di attenzione oppure interrompono il processo di merge a seconda delle FEATURES impostate nel proprio /etc/make.conf.

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:

Codice 3.2: Abilitare i contrassegni nel proprio kernel

-> Security options
  -> PaX
    -> Enable various PaX features
      -> PaX Control
        [*] Use ELF program header marking

Codice 3.3: Installare paxctl

# emerge paxctl

Quando si già si ha chpax installato si può dare:

Codice 3.4: Disabilitare PaX per il binario

# paxctl -pemrxs /percorso/al/binario

Questa opzione modifica leggermente l' ELF header al fine di impostare correttamente le flag di PAX sui binari.

Nota: Se si sta utilizzando PaX in conbinazione con ulteriori strumenti per la sicurezza, come ad esempio RSBAC di grsecurity, o SELinux è necessario gestire PaX attraverso l'utilizzo dei kernel hooks previsti per ogni implementazione.

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.

4.  Domande su Grsecurity

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

Come funziona TPE

È 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.

5.  Domande su SELinux

Dove posso trovare le FAQ relative a SELinux?

Ci sono alcune FAQ specifiche per SELinux.



Stampa

Aggiornato il 2011-3-27

Oggetto: Domande poste frequentemente sul canale IRC #gentoo-hardened e sulla mailing list gentoo-hardened.

Adam Mondl
Autore

solar
Collaboratore

Guillaume Destuynder
Collaboratore

Il Team PaX
Collaborazione

klondike
Contributi

Magnus Granberg
Contributi

Anthony G. Basile
Contributi

Paolo Palana
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.