
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
Archivio: Aprile 2007 ml@sikurezza.org Soggetto: Re: [ml] Whitepaper sulla virtualizzazione e sicurezza Mittente: Claudio Telmon Data: Tue, 3 Apr 2007 10:05:01 +0200 (CEST)
Daniele Bellucci wrote: > 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. È 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. > 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 ... 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: 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ù? La logica dovrebbe essere: niente, se sei in una macchina virtuale, il resto della macchina se sei solo in un chroot. Questo naturalmente come modello, prescindendo quindi da difetti implementativi. > mi chiedo quindi, in che modo riesci a garantire "sicurezza" a questo > livello di granularita'? > (NB: tralasciamo il discorso del "proxy syscall") > 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). 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? ciao - Claudio -- Claudio Telmon claudio@xxxxxxxxxx http://www.telmon.org
[ Home | Liste | F.A.Q. |
Risorse | Cerca... ]
www.sikurezza.org - Italian Security Mailing List
(c) 1999-2005