[ Home | Liste | F.A.Q. | Risorse | Cerca... ]


[ Data: precedente | successivo | indice ] [ Argomento: precedente | successivo | indice ]


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