Re: [ml] Whitepaper sulla virtualizzazione e sicurezza

> Assolutamente non da parte mia, anzi preferisco una critica
> costruttiva: al di la' che uno puo' essere piu' o meno d'accordo.

grazie, mi fa piacere perche' voglio capirci di piu' anch'io...

> Sono d'accordo con te quando dici che Xen va verificato. Tanto per
> dirtene una, la "live migration" tra due hypervisor si basa come
> "sicurezza" su un access list IP-based. Niente "strong authentication"
> (manco utente/pwd) e niente crittografia tra i due sistemi mentre
> copiano le pagine di memoria. Fai tu cosa puoi fare ... ;-)

ok, per ora sorvoliamo sulla questione implementazione e prendiamo
in considerazione il modello proposto con tutti gli annessi e connessi
idem dicasi un eventuali mancato code review.

> Sinceramente non sono cosi' in gamba da capire se e' possibile passare
> da un dominio all'altro .... bisognerebbe capire se l'interazione tra
> l'hypervisor (dom0) e il domU possa essere alterata in modo da mandare
> comandi al dom0. Chiunque fosse interessato a metterci le mano dentro
> mi faccia un fischio .... mi piacerebbe capirne di piu'!

allora, se dai un occhio al wiki scoprirai che Xen mette a disposizione
della API per far interagire i dom (es: shared memory). Che tu riesca o
meno a prendere il controllo dell'hypervisor poco importa IMHO.
Fatto sta' che viene concesso ai dom di interagire come se fossero dei
processi a se stanti.

Ora, se la paginazione viene gestita dall'hypervisor come letto, pur non
conoscendo la gestione della VM siamo sicuri che una pagina rilasciata a
domU non venga di seguito allocata a domV senza prima essere azzerata o
ripulita in qualche modo? Certo, hai lo stesso problema all'interno di
Kernel ma qui parliamo di una situazione in cui questi problemi non
dovrebbero proprio esistere visto alla base dovrebbe esserci una
perfetta equiriPARTIZIONE delle risorse.

Vi pongo tutte queste domande/esampi non per fare il
"saputello/scettico" quanto perche' se magari c'e' qualcuno che ha
approfondito meglio il discorso ... ben venga!!

Al tempo stesso, credo che di esempi come quello di cui sopra se ne
possano fare una miriade.

> Invece non sono d'accordo sui chroot/bsd jail. Due cose:
> supportabilita' e gestibilita.

Ok, pero' ti chiedo la cortesia di chiarirmi meglio le idee:

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.

nel caso della virtualizzazione, se non si vuol fare all'interno un jail
la granularita' del contesto e' quella del sistema operativo e quindi la
granularita' stessa del partizionamento e' quella del sistema operativo.
Questa differenza e' sostanziale ...
mi chiedo quindi, in che modo riesci a garantire "sicurezza" a questo
livello di granularita'?
(NB: tralasciamo il discorso del "proxy syscall")

Potresti, per favore, fornirmi un esempio di messa in sicurezza tramite
Xen/VMWare?

Grazie in anticipo.

Ah, dimenticavo il vantaggio di fare un application layer proxy
sfruttando come canale di comunicazione tra' il proxy e il servizio e'
quello di evitare che venga utilizzato come canale di trasmissione un
qualunque tipo di NIC reale o virtuale (nell'esempio, apache lo metti in
bind su localhost e quindi non hai bisogno di un qualche packet screener
aggiuntivo).