Re: [ml] Whitepaper sulla virtualizzazione e sicurezza

>> vantaggi del chroot: isolare quanto piu' possibile un contesto
>>                      quindi un eventuale apache non puo' inviare
>>                      segnali ad un processo con la cwd esterna
>>                      alla jail, oppure non ha visione del filesytem
>>                      esterno alla jail, etc. etc.
>>
> 
> 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.


> È cambiato qualcosa da allora? In generale,
> il fatto di essere il un ambiente chroot non limita molto la tua
> interazione con il kernel, ma solo con il filesystem, e quindi in
> particolare hai la possibilità di fare syscall e di sfruttare
> vulnerabilità del kernel, driver compresi, per fare privilege
> escalation e per eseguire codice che a quel punto opera sulla
> macchina intera.

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.


> 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

> anche con il controllo
> completo del kernel della macchina virtuale, non puoi fare più di
> quello che l'hypervisor ti concede. È vero che la granularità è
> quella del sistema operativo, ma è il sistema operativo della
> macchina virtuale, sulla quale di principio puoi arrivare ad avere
> un controllo completo. Se sulla tua macchina virtuale gira un server
> apache, e tu sei già riuscito a compromettere quel server fino al
> punto da riuscire ad eseguire codice arbitrario come root, cosa
> riesci ad ottenere di più? 

l'intera macchina virtuale e le risorse con cui essa
integisce. Es:
* Risorse HW che vengono da lei utilizzate
* VFS dell'intera macchina virtuale
* accesso al segmento di rete con cui la macchina virtuale è connessa
* ....

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.

D'altro canto riagganciandoci ai discorsi precedenti, mi và bene
che ciò venga fatto allorquando voglio ottimizzare i costi su risorse
hardware. Ed al momento è l'unico motivo che continuo a vedere per
utilizzare la virtualizzazione (para, software o quello che sia).
Un motivo intrinseco alla sicurezza, lo vedo soltanto per i sistemi
proprietari che non consentono Jail fatte a modo (garantendo un completo
partizionamento sui contesti, granularità: il singolo processo)


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