Re: [ml] Whitepaper sulla virtualizzazione e sicurezza

Daniele Bellucci wrote:
>> Hmm, ti riferisci al semplice chroot? L'ultima volta che ho provato
>> (su linux), un processo che girava come root in un chroot poteva
>> tranquillamente fare un mount del filesystem root in una qualsiasi
>> directory, nonché del filesystem proc, il che è praticamente come
>> essere fuori dal chroot. 
> 
> mi spieghi come ha fatto?
> perchè se avessi utilizzato una qualche Jail seria (ES:GRSecurity)
> tutti questi problemi non sarebbero sorti.

Niente GRSecurity. Solo chroot. L'ho chiesto apposta ;) Una banale
syscall, appunto.

> ok le sycall, ma non ok l'interazione con i driver.
> Con un minimo di dimestichezza, ci vuol poco a fare un modulo kernel (e
> tanti altri se ne trovano pronti all'uso) che impediscono i problemi di
> cui sopra. Vedi poi le capability, RBAC etc. etc.

A parte che le syscall non sono certo poco, su questo non sono
d'accordo, per vari motivi.

Per prima cosa, non vedo come tu possa impedire l'interazione fra i
dati generati dall'utente e i driver, a meno naturalmente di
togliergli l'accesso alle funzionalità offerte dai driver.

Poi, l'idea che un "modulo scritto da qualcuno con un po' di
dimestichezza", ovvero buttare del codice scritto in proprio nel
kernel, sia una buona pratica dal punto di vista della sicurezza non
rientra nella mia concezione di sicurezza ;) Magari è questione di
gusti.

Soprattutto, se stiamo confrontando due modelli, le cose non
pertinenti non entrano in gioco: cose come le capability le puoi
applicare in entrambi i casi, e in entrambi aiutano. Lo stesso per
GRSecurity. Ho qualche dubbio in più sulla pertinenza di RBAC, ma
vale comunque lo stesso discorso.

> 
> 
>> Se ho ben capito il discorso, la logica della virtualizzazione
>> dovrebbe essere diversa. La virtualizzazione (mi riferisco alla
>> virtualizzazione completa, altrimenti le cose sono meno lineari) non
>> ti permette di vedere il sistema guest: 
> 
> che bisogno potrei avere di vedere il sistema guest?
> l'unico che vedo è quello di accedere alle altre macchine virtuali

Xen ti offre un'interfaccia per farle comunicare? Non so perché c'è,
ma non mi sembra una grande idea dal punto di vista della sicurezza,
e su questo sono d'accordo. Tolta questa (che è un problema
specifico di Xen e non della virtualizzazione, Xen funzionerebbe
anche senza), a me sembra che per vedere una macchina virtuale da
un'altra dovresti passare dal sistema host. Come altrimenti?

> l'intera macchina virtuale e le risorse con cui essa
> integisce. Es:
> * Risorse HW che vengono da lei utilizzate

La macchina virtuale non vede l'harware direttamente, a differenza
del kernel sul quale gira il un ambiente in chroot. L'accesso
all'hardware è controllato dallo strato di virtualizzazione, che ti
fa vedere quello che vuole. Ne sono un esempio chiaro i dischi
virtuali di vmware. Se poi lo strato di virtualizzazione vuole, ti
da un accesso più diretto (vedi usb sempre in vmware), ma solo se
vuole.

> * VFS dell'intera macchina virtuale

Che è dedicato alla tua applicazione, e se sei già root non ti offre
niente di più di quanto già hai.

> * accesso al segmento di rete con cui la macchina virtuale è connessa

Stessa cosa per il chroot, direi.

> * ....
> 
> e non ultimo: la possibilità di infettare il kernel
> in esecuzione sulla macchina virtuale, crearme una backdoor
> che nasconde processi, socket, file descriptor, etc. etc.
> 
> Cosa è cambiato rispetto al caso in cui questa macchina fosse
> reale e non virtuale?
> 
> A mio avviso, niente.

A mio avviso, tanto :) Un esempio è questa cosa su cui stanno
lavorando qui a Pisa:
http://www-serra.unipi.it/sicurezza/tesi1.pdf
In pratica dalla macchina host vai a curiosare direttamente nella
memoria della macchina guest, senza fermare la macchina e senza
farci girare processi. Niente processi nascosti, niente rootkit.

> 
>> Non l'ho capita, me la spieghi meglio? Se il proxy è in serie prima
>> del server ed è effettivamente un proxy (e quindi non fa routing)
>> qual'è la differenza, per quanto riguarda il packet screening,
>> rispetto a farli comunicare su localhost?
> 
> Immagina due processi generici che comunicano tramite
> Shared Memory. Xen permette di shareare pagine di memoria
> tra i dom, da quanto letto.

Dovresi modificare apache per interagire in questo modo con un
"reverse proxy", anziché con sessioni tcp, giusto? In cosa
differisce rispetto a farli comunicare via localhost (nel senso
dell'interfaccia virtuale), che è quello che avevo capito
all'inizio? Ovvero, continua a non essermi chiaro il vantaggio in
termini di sicurezza.

ciao

- Claudio

-- 

Claudio Telmon
claudio@xxxxxxxxxx
http://www.telmon.org