Quali sono le precauzioni di sicurezza adottate per garantire che un dominio virtualizzato non possa compromettere il suo host

L'implementazione della macchina virtuale è un kernel per il kernel.

In un tipico sistema operativo, c'è application code (aka "userland") e kernel code . Usano lo stesso insieme di istruzioni; tuttavia, la CPU sa, in qualsiasi momento, se sta eseguendo l'applicazione o il codice del kernel. Quando il codice dell'applicazione tenta di eseguire alcuni codici opzionali che accedono all'hardware (il in e il out opcode per x86), la CPU trap : passa temporaneamente al codice del kernel (l'indirizzo di quel codice è registrato in una tabella specifica). Il codice del kernel decide cosa fare con l'accesso (concedilo, modificalo, uccidi il processo di applicazione ...). Se il codice del kernel decide di concedere l'accesso, o il kernel lo blocca, ma fa finta di averlo eseguito, allora il codice dell'applicazione può credere che possa accedere direttamente all'hardware.

Allo stesso modo, quando il codice dell'applicazione legge o scrive dati in memoria, utilizza un'astrazione di memoria: uno spazio di indirizzo virtuale che viene mappato alla memoria fisica (o meno ...) tramite MMU . La MMU usa le tabelle che il kernel riempie (e, ovviamente, il kernel si preoccupa di non rendere queste tabelle parte dello spazio degli indirizzi visibile dal codice dell'applicazione). In questo modo, l'applicazione si trova in un mondo magico in cui è solo in un grande spazio di indirizzamento, mentre in realtà ci sono diverse applicazioni eseguite simultaneamente, che non possono vedersi.

Una macchina virtuale utilizza la stessa struttura, un livello più alto. Quando il kernel accede all'hardware o alla MMU, in realtà è sotto esame dell'implementazione della macchina virtuale (il hypervisor ) che intrappola gli accessi indesiderati.

I dettagli variano molto. La distinzione principale è se il kernel è consapevole del fatto che viene eseguito in una macchina virtuale o meno. Con Xen , il kernel è a conoscenza; sa che è sotto il controllo di una divinità superiore (l'hypervisor) e non tenta di attingere direttamente all'hardware; invece, chiede graziosamente attraverso un'interfaccia dedicata. Con VirtualBox , il kernel non è a conoscenza; il sistema operativo guest crede che funzioni su hardware vero, e la VM lavora duramente per mantenere l'illusione.

Altre differenze possono essere fatte sulle modalità con cui viene applicata la virtualizzazione (cioè come l'hypervisor può intercettare il codice del kernel). I processori x86 recenti offrono un supporto specifico con codici opzionali dedicati . I processori x86 più vecchi, in modalità a 32 bit, possono utilizzare i vari resti di meccanismi di protezione meno recenti (i registri di segmento ei quattro "anelli", per lo più) (questi sono stati rimossi dalla modalità a 64 bit, motivo per cui la macchina virtuale a 64 bit deve usa AMD-V / VT-x). Altre tecniche includono l'emulazione di ogni opcode virtualizzato (per l'intera macchina emulata, o parti di esso), possibilmente con una traduzione dinamica più o meno (ovvero una compilazione JIT), aas QEMU funziona in situazioni cross-CPU.

C'è un intero armamentario di termini sull'argomento (virtualizzazione, paravirtualizzazione, emulazione, simulazione, hypervisor ...) che non è completamente consensuale e spesso abbastanza bizantino. Alcuni lettori che si aggrappano a determinate dottrine di terminologia probabilmente sono stati in qualche modo irritati dal modo sciolto in cui uso i termini.

Concettualmente, una macchina virtuale è un emulatore. Hai mai visto gli emulatori Nintendo, dove tieni incollato un vecchio gioco Nintendo e emula la console Nintendo? Funziona così: l'emulatore legge ripetutamente un'istruzione dal gioco, quindi emula l'effetto dell'esecuzione di tale istruzione (simulando l'hardware Nintendo, ma utilizzando il software in esecuzione sul tuo computer), e così via.

Una macchina virtuale è proprio così, tranne che per emulare l'hardware Nintendo, emula l'hardware Intel x86. Una macchina virtuale legge un'istruzione dall'ospite, emula il suo effetto (all'interno della sandbox), quindi passa all'istruzione successiva. Poiché l'emulazione viene eseguita dal software, è possibile scrivere il software per verificare che gli effetti dell'istruzione rimangano all'interno della sandbox.

Concettualmente, è così che funziona una macchina virtuale. In pratica, le macchine virtuali non funzionano in questo modo; l'emulazione è molto lenta, quindi le macchine virtuali utilizzano vari metodi per velocizzare il processo. Molti processori moderni includono il supporto hardware per la virtualizzazione per far funzionare una macchina virtuale il più velocemente possibile. Ma puoi pensare ad un emulatore di CPU grande, onesto, magicamente veloce, e questo ti darà la giusta intuizione.

Quindi, concettualmente, è così che una macchina virtuale può garantire che l'ospite non possa fuggire dalla sandbox. La macchina virtuale può controllare l'effetto di ogni istruzione per assicurarsi che non scappi, ed eseguire l'istruzione solo se tutto è OK.

Per ulteriori informazioni su questo argomento, ti consiglio di leggere le seguenti domande su questo sito:

• Quanto sono sicure le macchine virtuali? Falso senso di sicurezza?

• Una macchina virtuale impedisce ai malware di fare del male?

Ciò dipenderebbe dal tipo di virtualizzazione, con la virtualizzazione dell'hardware (Xen, ESX, Hyper-V), come D.W. dice, nessun problema.

Tuttavia con la virtualizzazione del kernel (LXC, openVZ) c'è ancora il rischio di uscire dal carcere. Con openVZ non ci sono stati exploit segnalati di recente per irrompere sul computer host, ma con LXC ce ne sono.

Da un punto di vista della sicurezza mi raccomando di utilizzare la virtualizzazione dell'hardware piuttosto che la virtualizzazione del kernel.

• link
• link