Gentoo Logo

Guida Gentoo a Grsecurity v2

Indice:

1.  A proposito di Grsecurity

Il progetto Grsecurity

Il progetto grsecurity, ospitato su http://www.grsecurity.org, fornisce diverse patch al kernel di Linux che consentono di aumentare la sicurezza generale del proprio sistema. Le varie caratteristiche offerte da grsecurity sono discusse nel prossimo capitolo. Una lista esauriente è mantenuta nella stessa pagina delle caratteristiche di grsecurity.

Visto che le caratteristiche di grsecurity sono essenzialmente basate sul kernel, la maggior parte di questo documento spiega le varie caratteristiche del kernel e le relative chiamate di sistema (se ciò è possibile).

Integrazione Gentoo Hardened

Il Progetto Gentoo Hardened sostiene le caratteristiche di aumento della sicurezza per Gentoo, includendo, ma non limitandosi a, grsecurity.

Configurazione del Kernel

In questo documento vogliamo parlare della configurazione del kernel parlando in termini di variabili del kernel quali CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS. Queste sono le variabili che il processo di compilazione del kernel usa per determinare se certe caratteristiche devono o meno essere compilate.

Quando si procede alla configurazione del kernel attraverso make menuconfig o simili si riceve un'interfaccia utente attraverso la quale è possibile selezionare le varie opzioni del kernel. Se si seleziona il bottone di Help su qualsiasi caratteristica del kernel è possibile vedere nella parte superiore della schermata la corrispettiva variabile.

È possibile configurare il kernel in qualsiasi maniera si voglia, con un minimo di raziocinio, e se risulta difficile trovare alcune opzioni si può sempre modificare /usr/src/linux/.config a mano :)

Ovviamente per essere in grado di selezionare le varie opzioni grsecurity del kernel è necessario abilitare grsecurity nel proprio kernel:

Codice 1.1: Attivare grsecurity

CONFIG_GRKERNSEC=y
CONFIG_GRKERNSEC_CUSTOM=y

2.  PaX

Combattere lo sfruttamento dei bug del software

PaX introduce una coppia di meccanismi di sicurezza che rende difficile per degli attaccanti sfruttare bug che coinvolgano la corruzione della memoria (quindi non trattare PaX come se proteggesse da tutti i bug). Il documento di introduzione a PaX parla di tre possibili tecniche di exploit:

  1. introdurre/eseguire codice arbitrario
  2. eseguire codice esistente al di fuori del normale flusso di esecuzione del programma originale
  3. eseguire codice esistente nel normale flusso di esecuzione del programma originale con dati arbitrari

Un metodo di prevenzione impedisce che il codice eseguibile possa essere memorizzato in aree di memoria scrivibile. Un processo richiede cinque differenti regioni di memoria

  1. Una sezione dati che contiene dati globali e allocati staticamente
  2. Una regione BSS (Block Started by Symbol) che contiene informazioni i dati zero-initialized del processo.
  3. Una regione codice, chiamata anche segmento testo, che contiene le istruzioni eseguibili.
  4. Un heap che contiene la memoria allocata dinamicamente.
  5. Uno stack che contiene le variabili locali.

Il primo metodo di prevenzione di Pax, chiamato NOEXEC, ha come scopo quello di fornire del controllo sulla generazione a runtime di codice eseguibile. Le pagine di memoria che non contengono codice eseguibile vengono marcate come non-eseguibili. Questo significa che heap e stack, che contengono solo dati e non dovrebbero contenere codice eseguibile, sono marcati come non-eseguibili. Gli exploit che inseriscono del codice in questa area con l'intento di mandarlo in esecuzione falliranno.

In realtà NOEXEC fa più di questo, i lettori interessati possono soddisfare la loro curiosità leggendo la Documentazione PaX riguardante NOEXEC.

Il secondo metodo di prevenzione di Pax, chiamato ASLR (Address Space Layout Randomization), rende casuali gli indirizzi dati alle richieste di memoria. Mentre precedentemente la memoria veniva assegnata sequenzialmente (il che significa che gli exploit sanno dove le regioni di memoria di un processo sono situate) ASLR rende casuali questa allocazione, rendendo vane le tecniche che contano su questa informazione.

Sono disponibili altre informazioni online su ASLR.

Abilitare PaX

Le impostazioni del kernel raccomandate per PaX sono:

Codice 2.1: Configurazione del kernel raccomandata per PaX

#
# Controllo PaX
#
# CONFIG_GRKERNSEC_PAX_SOFTMODE is not set
CONFIG_GRKERNSEC_PAX_EI_PAX=y
CONFIG_GRKERNSEC_PAX_PT_PAX_FLAGS=y
CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS=y
# CONFIG_GRKERNSEC_PAX_HAVE_ACL_FLAGS is not set
# CONFIG_GRKERNSEC_PAX_HOOK_ACL_FLAGS is not set

#
# Protezione dello spazio degli indirizzi
#
CONFIG_GRKERNSEC_PAX_NOEXEC=y
# CONFIG_GRKERNSEC_PAX_PAGEEXEC is not set
CONFIG_GRKERNSEC_PAX_SEGMEXEC=y
CONFIG_GRKERNSEC_PAX_EMUTRAMP=y
CONFIG_GRKERNSEC_PAX_MPROTECT=y
# CONFIG_GRKERNSEC_PAX_NOELFRELOCS is not set
CONFIG_GRKERNSEC_PAX_ASLR=y
CONFIG_GRKERNSEC_PAX_RANDKSTACK=y
CONFIG_GRKERNSEC_PAX_RANDUSTACK=y
CONFIG_GRKERNSEC_PAX_RANDMMAP=y
CONFIG_GRKERNSEC_PAX_RANDEXEC=y
# CONFIG_GRKERNSEC_KMEM is not set
# CONFIG_GRKERNSEC_IO is not set
CONFIG_GRKERNSEC_PROC_MEMMAP=y
CONFIG_GRKERNSEC_HIDESYM=y

Se si sta utilizzando un sistema non-x86 tenere presente che CONFIG_GRKERNSEC_PAX_NOEXEC è assente. Si dovrebbe, quindi, selezionare CONFIG_GRKERNSEC_PAX_PAGEEXEC poiché è l'unica implementazione non-exec disponibile.

Controllare PaX

Non tutte le applicazioni Linux sono felici delle restrizioni imposte da PaX, per esempio xorg-x11, java, mplayer, xmms e altri. Se si sta pensando di usarli si può elevare la protezione per queste applicazioni usando chpax e paxctl.

Codice 2.2: Installare le utilità chpax e paxctl

# emerge sys-apps/chpax
# emerge sys-apps/paxctl

chpax fornisce uno script di inizializzazione che gestisce per noi le impostazioni per le applicazioni maggiormente conosciute:

Codice 2.3: Aggiungere lo script di inizializzazione chpax al runlevel di default

# rc-update add chpax default

pax-utils è una piccola "cassetta degli attrezzi" che contiene applicazioni utili per amministrare un server PaX.

Codice 2.4: Installare pax-utils

# emerge pax-utils

Alcuni strumenti interessanti includono scanelf e pspax:

  • Con scanelf è possibile effettuare una scansione attraverso directory di librerie e file binari ed elencare i vari permessi e tipi ELF che riguardano l'esecuzione di un setup ideale pax/grsec.
  • Con pspax si possono visualizzare i flags/capabilities/xattr dal punto di vista del kernel.

Verificare le impostazioni di PaX

Peter Busser ha scritto una raccolta di test di regressione chiamata paxtest. Questo strumento ha lo scopo di testare vari casi di possibili vettori di attacco e comunicarne i risultati. Quando lo si esegue questo crea un file di log chiamato paxtest.log nella directory corrente di lavoro.

Codice 2.5: Installare ed seguire paxtest

# emerge paxtest

# paxtest
Executable anonymous mapping             : Killed
Executable bss                           : Killed
Executable data                          : Killed
Executable heap                          : Killed
Executable stack                         : Killed
Executable anonymous mapping (mprotect)  : Killed
Executable bss (mprotect)                : Killed
Executable data (mprotect)               : Killed
Executable heap (mprotect)               : Killed
Executable stack (mprotect)              : Killed
Executable shared library bss (mprotect) : Killed
Executable shared library data (mprotect): Killed
Writable text segments                   : Killed
Anonymous mapping randomisation test     : 16 bits (guessed)
Heap randomisation test (ET_EXEC)        : 13 bits (guessed)
Heap randomisation test (ET_DYN)         : 25 bits (guessed)
Main executable randomisation (ET_EXEC)  : 16 bits (guessed)
Main executable randomisation (ET_DYN)   : 17 bits (guessed)
Shared library randomisation test        : 16 bits (guessed)
Stack randomisation test (SEGMEXEC)      : 23 bits (guessed)
Stack randomisation test (PAGEEXEC)      : No randomisation
Return to function (strcpy)              : Vulnerable
Return to function (memcpy)              : Vulnerable
Return to function (strcpy, RANDEXEC)    : Killed
Return to function (memcpy, RANDEXEC)    : Killed
Executable shared library bss            : Killed
Executable shared library data           : Killed

Nel Precedente esempio si vede che:

  • strcpy e memcpy sono elencate come Vulnerabili. Questo è un risultato atteso e normale - sta semplicemente mostrando le necessità per una tecnologia come ProPolice/SSP
  • Non c'è "randomisation" (casualità) per PAGEEXEC. Questo è normale poiché, come suggerito, la configurazione del kernel per x86 non ha attiva l'impostazione PAGEEXEC. Tuttavia su architetture che supportano un reale NX (non-executable) bit (la maggior parte, incluso x86_64), PAGEEXEC è il solo metodo disponibile per NOEXEC e non va a penalizzare le prestazioni.

3.  RBAC

Role Based Access Control

Ci sono due meccanismi di base per il controllo degli accessi usati per prevenire accessi non autorizzati ai file (o informazioni in generale): DAC (Discretionary Access Control) e MAC (Mandatory Access Control). Linux usa in modo predefinito il meccanismo DAC: il creatore di un file può decidere chi ha accesso al file stesso. Un sistema MAC forza chiunque a seguire delle regole impostate dall'amministratore.

L'implementazione di MAC che grsecurity supporta si chiama Role Based Access Control. RBAC associa dei ruoli con ogni utente. Ogni ruolo definisce quali operazioni possono essere fatte su determinati oggetti. Dato un insieme ben formato di ruoli ed operazioni i propri utenti saranno costretti ad effettuare solo quelle attività che gli sono state permesse. La regola predefinita "deny-all" assicura che un utente non possa eseguire azioni alle quali non si era pensato.

Configurare il Kernel

La configurazione del Kernel raccomandata per RBAC è:

Codice 3.1: Configurazione raccomandata del Kernel per RBAC

#
# Role Based Access Control Options
#
CONFIG_GRKERNSEC_ACL_HIDEKERN=y
CONFIG_GRKERNSEC_ACL_MAXTRIES=3
CONFIG_GRKERNSEC_ACL_TIMEOUT=30

Lavorare con gradm

gradm è uno strumento che consente di amministrare e mantenere una policy per il proprio sistema. Con esso è possibile abilitare o disabilitare il sistema RBAC, rileggere i ruoli RBAC, cambiare il vostro ruolo, impostare una password per la modalità admin, etc.

Quando si installa gradm viene installata una policy predefinita in /etc/grsec/policy:

Codice 3.2: Installare gradm

# emerge gradm

Le policy RBAC non sono attivate in modo predefinito. È compito dell'amministratore di sistema decidere quando il sistema stesso debba seguire una politica di RBAC, invece che di Gentoo. Prima di attivare il sistema RBAC bisogna impostare una password per l'amministratore.

Codice 3.3: Attivare il sistema RBAC

# gradm -P
Setting up grsecurity RBAC password
Password: (Inserire una password appropriata)
Re-enter Password: (Reinserire la stessa password per conferma)
Password written in /etc/grsec/pw
# gradm -E

Per disabilitare il sistema RBAC bisogna eseguire gradm -D. Se non si è autorizzati è necessario prima passare al ruolo di amministratore:

Codice 3.4: Disabilitare il sistema RBAC

# gradm -a admin
Password: (Inserire la propria password da amministratore)
# gradm -D

Per lasciare il ruolo di amministratore eseguire gradm -u admin:

Codice 3.5: Uscire dal ruolo di amministratore

# gradm -u admin

Creare una Policy

Il sistema RBAC inizia con una caratteristica simpatica chiamata "learning mode". Il learning mode può generare una policy iniziale con i minimi privilegi per il proprio sistema. Questo è stato pensato per risparmiare tempo e soldi rendendo possibile il rapido dispiego di molteplici server sicuri.

Per utilizzare il learning mode è necessario attivarlo usando gradm:

Codice 3.6: Attivare il learning mode di RBAC

# gradm -F -L /etc/grsec/learning.log

Adesso usiamo il nostro sistema facendo le cose che faremmo normalmente. Cerchiamo di evitare operazioni di rsync, eseguire il locate e ogni altra operazione che faccia uso pesante dell'I/O e che possa rallentare il tempo di processamento.

Quando si ritiene di aver usato sufficientemente il proprio sistema per ottenere una buona policy autorizziamo il processo gradm stesso e suggeriamo ruoli in /etc/grsec/learning.roles:

Codice 3.7: Processamento dei log del learning mode

# gradm -F -L /etc/grsec/learning.log -O /etc/grsec/learning.roles

Nota: Occorre disabilitare la modalità apprendimento di RBAC prima di fare questa operazione. Per farlo si può usare gradm -D for this.

Verificare /etc/grsec/learning.roles e salvarlo in /etc/grsec/policy (permessi 0600) una volta terminato.

Codice 3.8: Salvare le policy

# mv /etc/grsec/learning.roles /etc/grsec/policy
# chmod 0600 /etc/grsec/policy

Adesso si dovrebbe essere in grado di abilitare il proprio sistema RBAC con le policy apprese.

Perfezionare la propria policy

Una interessante caratteristica di grsecurity2.x è Set Operation Support per il file di configurazione. Attualmente sono supportate unioni, intersezioni e differenza tra insiemi (di oggetti in questo caso).

Codice 3.9: Insiemi di esempio

define objset1 {
/root/blah rw
/root/blah2 r
/root/blah3 x
}

define somename2 {
/root/test1 rw
/root/blah2 rw
/root/test3 h
}

Questo è un esempio del suo uso e gli oggetti risultanti che saranno aggiunti al vostro soggetto:

Codice 3.10: Esempio dell'operatore &

subject /somebinary o
$objset1 & $somename2

Quanto sopra si espanderebbe in:

Codice 3.11: Setting dei soggetti risultanti

subject /somebinary o
/root/blah2 r

Questo è il risultato dell'operatore & che prende entrambi gli insiemi e restituisce i file che esistono contemporaneamente in entrambi gli insiemi e i relativi permessi.

Codice 3.12: Esempio dell'operatore |

subject /somebinary o
$objset1 | $somename2

Questo esempio sarebbe equivalente a:

Codice 3.13: Impostazioni degli soggetti risultanti

subject /somebinary o
/root/blah rw
/root/blah2 rw
/root/blah3 x
/root/test1 rw
/root/test3 h

Questo è il risultato dell'operatore | che prende entrambi gli insiemi e restituisce i file che esistono in un solo insieme. Se il file dovesse esistere in entrambi gli insiemi questo viene ugualmente restituito e il mode contiene le flag che esistono in un solo insieme.

Codice 3.14: Esempio dell'operatore -

subject /somebinary o
$objset1 - $somename2

Questo esempio sarebbe equivalente a:

Codice 3.15: Impostazioni dei soggetti risultanti

subject /somebinary o
/root/blah rw
/root/blah2 h
/root/blah3 x

Questo è il risultato dell'operatore - che prende i due insiemi e restituisce il file che esiste nell'insieme di sinistra ma non nella corrispondenza con il file nell'insieme di destra. Se il file esiste nell'insieme di sinistra e viene trovato una corrispondenza a destra (il nome del file è lo stesso o una directory padre esiste nell'insieme di destra), il file viene restituito e il mode del secondo insieme è rimosso dal primo insieme, e quel file viene restituito.

In un qualche oscuro pseudo-linguaggio questo potrebbe essere visto come:

Codice 3.16: Spiegazione con pseudo-linguaggio

if ( ($objset1 contiene /tmp/blah rw) e
     ($objset2 contiene /tmp/blah r) )
then
  $objset1 - $objset2 dovrebbe contenere /tmp/blah w

if ( ($objset1 contiene /tmp/blah rw) and
     ($objset2 contiene / rwx) )
then
  $objset1 - $objset2 dovrebbe contenere /tmp/blah h

Per quanto riguarda l'ordine di precedenza (dalla più alta alla più bassa): "-, & |".

Se non si vuole avere la seccatura di ricordare le precedenze è stato incluso il supporto per le parentesi, cosi si possono scrivere espressioni come:

Codice 3.17: Esempio di parentesi

(($set1 - $set2) | $set3) & $set4

4.  Protezione del FileSystem

Combattere Chroot e abusi del filesystem

Grsecurity2 include diverse patch che impediscono agli utenti di guadagnare conoscenze non necessarie riguardo al sistema. Questo include restrizione sull'uso di /proc, sul chrooting, sul linking ecc.

Configurazione del kernel

Per la protezione del filesystem si raccomanda la seguente configurazione del grsecurity kernel

Codice 4.1: Attivare la protezione del Filesystem

#
# Filesystem Protections
#
CONFIG_GRKERNSEC_PROC=y
# CONFIG_GRKERNSEC_PROC_USER is not set
CONFIG_GRKERNSEC_PROC_USERGROUP=y
CONFIG_GRKERNSEC_PROC_GID=10
CONFIG_GRKERNSEC_PROC_ADD=y
CONFIG_GRKERNSEC_LINK=y
CONFIG_GRKERNSEC_FIFO=y
CONFIG_GRKERNSEC_CHROOT=y
CONFIG_GRKERNSEC_CHROOT_MOUNT=y
CONFIG_GRKERNSEC_CHROOT_DOUBLE=y
CONFIG_GRKERNSEC_CHROOT_PIVOT=y
CONFIG_GRKERNSEC_CHROOT_CHDIR=y
CONFIG_GRKERNSEC_CHROOT_CHMOD=y
CONFIG_GRKERNSEC_CHROOT_FCHDIR=y
CONFIG_GRKERNSEC_CHROOT_MKNOD=y
CONFIG_GRKERNSEC_CHROOT_SHMAT=y
CONFIG_GRKERNSEC_CHROOT_UNIX=y
CONFIG_GRKERNSEC_CHROOT_FINDTASK=y
CONFIG_GRKERNSEC_CHROOT_NICE=y
CONFIG_GRKERNSEC_CHROOT_SYSCTL=y
CONFIG_GRKERNSEC_CHROOT_CAPS=y

Attivare il meccanismo di sicurezza

Quando si usa un kernel compilato con le precedenti impostazioni (o comunque con impostazioni simili) è possibile abilitare/disabilitare molte delle opzioni attraverso /proc filesystem o via sysctl.

L'esempio seguente mostra un frammento di un tipico /etc/sysctl.conf:

Codice 4.2: Esempio di impostazioni all'interno di /etc/sysctl.conf

kernel.grsecurity.chroot_deny_sysctl = 1
kernel.grsecurity.chroot_caps = 1
kernel.grsecurity.chroot_execlog = 0
kernel.grsecurity.chroot_restrict_nice = 1
kernel.grsecurity.chroot_deny_mknod = 1
kernel.grsecurity.chroot_deny_chmod = 1
kernel.grsecurity.chroot_enforce_chdir = 1
kernel.grsecurity.chroot_deny_pivot = 1
kernel.grsecurity.chroot_deny_chroot = 1
kernel.grsecurity.chroot_deny_fchdir = 1
kernel.grsecurity.chroot_deny_mount = 1
kernel.grsecurity.chroot_deny_unix = 1
kernel.grsecurity.chroot_deny_shmat = 1

È possibile abilitare o disabilitare le impostazioni anche usando il comando sysctl:

Codice 4.3: Abilitare le impostazioni di sysctl

(Attivare la caratteristca exec_logging)
# sysctl -w kernel.grsecurity.exec_logging = 1
(Disattivare la caratteristica exec_logging
# sysctl -w kernel.grsecurity.exec_logging = 0

C'è un'impostazione di sysctl veramente importante appartenente a grsecurity, denominato kernel.grsecurity.grsec_lock. Se abilitata non si ha la possibilità di modificare nessun'altra impostazione.

Codice 4.4: Interfaccia per il blocco di sysctl

# sysctl -w kernel.grsecurity.grsec_lock = 1

5.  Verifica del Kernel

Estendere la facilità di logging del proprio sistema

grsecurity fornisce funzionalità aggiuntive al kernel inerenti al logging. Con il Kernel Auditing di grsecurity il kernel ci informa quando una applicazione è stata avviata, quando un dispositivo viene montato, ecc.

Le varie impostazioni per il Kernel Audit

La seguente configurazione del kernel può essere usata per abilitare il Kernel Audit di grsecurity:

Codice 5.1: Attivare il Kernel Auditing

#
# Kernel Auditing
#
# CONFIG_GRKERNSEC_AUDIT_GROUP is not set
CONFIG_GRKERNSEC_EXECLOG=y
CONFIG_GRKERNSEC_RESLOG=y
CONFIG_GRKERNSEC_CHROOT_EXECLOG=y
CONFIG_GRKERNSEC_AUDIT_CHDIR=y
CONFIG_GRKERNSEC_AUDIT_MOUNT=y
CONFIG_GRKERNSEC_AUDIT_IPC=y
CONFIG_GRKERNSEC_SIGNAL=y
CONFIG_GRKERNSEC_FORKFAIL=y
CONFIG_GRKERNSEC_TIME=y
CONFIG_GRKERNSEC_PROC_IPADDR=y
CONFIG_GRKERNSEC_AUDIT_TEXTREL=y

6.  Restrizioni per i processi

Protezione degli eseguibili

Con grsecurity è possibile imporre restrizioni agli eseguibili. Poichè la maggior parte degli exploit lavorano attraverso uno o più processi attivi questa protezione può preservare la salute del proprio sistema.

Protezione di rete

Lo stack TCP/IP di Linux è vulnerabile ad attacchi di tipo prediction-based. grsecurity include una patch "randomizzatrice" per evitare questo tipo di attacchi. Oltre a questo si possono comunque abilitare delle restrizioni sui socket, respingendo l'accesso da parte di un gruppo di reti tutte insieme.

Impostazioni del kernel

Le seguenti impostazioni abilitano diverse protezioni sia per gli eseguibili che di rete:

Codice 6.1: Impostazioni del kernel

#
# Protezione per gli eseguibili
#
CONFIG_GRKERNSEC_EXECVE=y
CONFIG_GRKERNSEC_DMESG=y
CONFIG_GRKERNSEC_RANDPID=y
CONFIG_GRKERNSEC_TPE=y
CONFIG_GRKERNSEC_TPE_ALL=y
CONFIG_GRKERNSEC_TPE_GID=100

#
# Protezione di rete
#
CONFIG_GRKERNSEC_RANDNET=y
CONFIG_GRKERNSEC_RANDISN=y
CONFIG_GRKERNSEC_RANDID=y
CONFIG_GRKERNSEC_RANDSRC=y
CONFIG_GRKERNSEC_RANDRPC=y
# CONFIG_GRKERNSEC_SOCKET is not set

7.  La Toolchain Hardened

Sebbene questo esuli dallo scopo di questo articolo, si vuole menzionare l'uso dell'hardened toolchain che completa l'uso del modello grsec/PaX da userspace.

8.  Risorse



Stampa

Aggiornato il 31 dicembre 2012

Oggetto: Questo documento illustra le caratteristiche delle patch di sicurezza gresecurity 2.x, supportate dalle opzioni di configurazione del kernel e dagli strumenti forniti dal progetto grsecurity per innalzare la sicurezza del proprio sistema ad elevati standard.

solar
Autore

Sven Vermeulen
Autore

Paolo Palana
Traduzione

Donate to support our development efforts.

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