Il doppio avvio di un sistema operativo è più o meno sicuro rispetto all'utilizzo di una macchina virtuale?

Rispondi prima, quindi perché: una macchina virtuale può essere più sicura.

Da un punto di vista pratico, esistono codice e malware che possono infettare entrambe le partizioni di avvio, il BIOS e anche i dispositivi hardware. Quindi, una VM ha leggermente più vantaggi in una superficie di attacco ridotta da un punto di vista generico: il potenziale codice di hopping delle VM è il più grande specifico della VM. È probabile che questo codice sia specifico per il tipo di VM utilizzato, come il recente collegamento . Nota che richiedeva una macchina virtuale specifica (kvm o xen), suoneria, ecc.

Quindi, dal punto di vista del codice ostile, virtualizzato è più sicuro.

Avvicinandosi dall'angolo di rete, molti utenti di soluzioni di virtualizzazione hanno una maggiore flessibilità a livello di rete tramite NAT all'interno di NAT, PAT o altre funzionalità che un sistema operativo potrebbe non supportare nativamente, o la propria sicurezza avanzata attraverso l'uso delle VM. È abbastanza banale migliorare una postura sicura usando una VM specifica per ispezionare tutto il traffico i / o con la virtualizzazione.

Quindi, dal punto di vista della sicurezza della rete, la virtualizzazione è più sicura.

Sulle operazioni guest. La bellezza dei sistemi operativi di clonazione in secondo ... A seconda del tipo di soluzione di virtualizzazione utilizzata, una VM disattivata può essere applicata in modo trasparente in modo trasparente senza l'intervento dell'utente. È banale prendere una VM generica e bloccarla usando varie guide di indurimento dove c'è una funzionalità minima, tranne che per applicazioni specifiche. Le VM semplificano l'esecuzione di livelli estremi di hardening come l'esecuzione di privilegi minimi sugli archivi di certificati attendibili (ad es. Elimina la maggior parte dei certificati dalle CA commerciali ad eccezione di quelli che sto usando) Questo tipo di attività può essere molto più veloce con una VM a causa della capacità per eseguire un'istantanea e recuperare da modifiche catastrofiche. Inoltre, una VM nella sua interezza può essere facilmente impacchettata in un file e salvata da qualche parte, su una USB, ecc. Inoltre, quando si pensa ai compromessi, rendersi conto che nella virtualizzazione, un compromesso può essere molto meno privilegiato rispetto a quello normale. In un hypervisor di tipo 1, ad esempio, è l'hypervisor stesso l'istanza più privilegiata sul computer. Aumentare i livelli di cerchi per un utente malintenzionato. Può anche essere usato per concedere agli sviluppatori l'accesso amministrativo / root, senza concedere detti amministratori di dominio degli sviluppatori, o privilegi sul LDAP aziendale.

Quindi, dal punto di vista delle operazioni guest, virtualizzato è più sicuro.

Tuttavia, mi concentrerò sulla premessa per un secondo - che i sistemi operativi nativi di tipo nativo virtualizzati e avviati sono o-o scelte. Non lo sono, in quanto è possibile avviare un sistema operativo virtualizzato utilizzando soluzioni di terze parti come se si trattasse di un'opzione di avvio doppio. Il software come vboot consente l'avvio in formato VHD / VMDK / VDI / raw.

Per quanto riguarda i tipi di virtualizzazione, ce ne sono alcuni che sono applicabili a questo caso. Quelli sono la virtualizzazione di tipo 1 (bare metal), la virtualizzazione di tipo 2 (sistema operativo ospitato) e considero parziale, sistema operativo e amp; paravirtualizzazione al di fuori del campo di applicazione. La principale soluzione di virtualizzazione x86 di tipo 1, hypervisor VMware vsphere, utilizza un approccio microkernel con una superficie di attacco minima. La virtualizzazione di tipo 2 ha superfici di attacco più grandi poiché si basano su un intero sistema operativo sottostante. Quindi, i commenti di Theo sui sistemi operativi completi non sono corretti quando applicati a VMware.

Ecco alcune propaganda VMware sull'argomento

link

Naturalmente, la sicurezza è spesso un compromesso tra usabilità e sicurezza. È importante considerare una situazione di minaccia che un utente è probabile incontrare e che distribuirà risorse contro di te per attaccarti. Se sei uno stato-nazione o una banca hai bisogno di protezioni estese. Aziende, altro Utenti individuali di poca notorietà - protezioni abbastanza buone. Tieni presente che una buona soluzione di sicurezza ti protegge abbastanza, ma non ha un impatto negativo sull'usabilità al punto di essere un ostacolo. La gestione del rischio generale è un argomento diverso, degno di revisione altrove.

Non ho parlato di approcci di sicurezza più esotici, come i thin client che potrebbero essere utilizzati per espandere la sicurezza della virtualizzazione riducendo ulteriormente le superfici di attacco o il blocco del TPM in combinazione con un hypervisor di tipo 1.

Ognuno di questi è più sicuro al riguardo.

Se si desidera creare un ambiente "sandbox" in cui è possibile sperimentare codice pericoloso, farlo in una macchina virtuale è più sicuro rispetto a un ambiente con doppio avvio. Questo risulta dalla tua domanda come ciò che stai chiedendo. Il motivo per cui è perché una macchina virtuale non ha accesso diretto al tuo hardware, viene eseguito come un programma emulato all'interno di un programma in modo tale che il l'intero ambiente di runtime esiste solo nella misura consentita dal sistema di virtualizzazione (presupponendo che non vi siano bug di sicurezza nell'hypervisor). Se il tuo sistema VM dichiara che l'accesso al disco fisso è impossibile, allora il programma in esecuzione non può accedere al disco rigido.

Se, al contrario, vuoi "sfuggire" al tuo ambiente standard e creare un ambiente sicuro, allora il dual-boot è l'unico modo per arrivarci. Il motivo è che poiché una VM esiste come un programma all'interno del desktop standard, eventuali problemi di sicurezza nel desktop standard possono estendersi anche alla VM stessa: il desktop può intercettare trafffic, sequenze di tasti, accesso al disco, ecc. VM. Quindi, se il tuo desktop non è sicuro, la tua VM non può essere sicura. Questo sembra non essere quello che ti serviva, ma potrebbe essere utile comprenderlo per un utilizzo futuro.

Personalmente sembra che sia al limite della paranoia per le persone che non stanno facendo ricerche sui malware.

Se utilizzi 2 sistemi operativi diversi, avrai bisogno di malware che sappia leggere i due diversi file system.

Se è in esecuzione su una VM, è necessario che il malware sia mirato specificamente all'hypervisor in modo che possa uscire dalla sandbox.

Stai già mitigando alcuni dei modi più ovvi per cui qualcosa ti può infettare eseguendo con privilegi più bassi e così via. In caso contrario, le migliori attività di attenuazione sarebbero backup regolari, scansione per malware o per me, quando si esegue un sistema basato su UNIX, è possibile eseguire i correttori di file che utilizzano i checksum per monitorare le modifiche ai file e inviarli via email quando vengono rilevati file / modifiche sospette.

Inoltre con una VM è possibile creare una cartella condivisa in cui salvare i dati permanenti, quindi basta scattare un'istantanea della VM, eseguire i corsi, quindi eseguire il rollback dell'istantanea in modo da cancellare tutto ciò che potrebbe essere accaduto alla VM. . Il malware dovrebbe conoscere in modo specifico la tua condivisione per poter essere copiata su una condivisione e anche in quel caso non può essere eseguita.

Mentre la sicurezza deve essere stratificata per essere efficace, non ci vuole molto per fare alcune cure di base per l'uso medio. Personalmente, se temi che alcune attività in particolare causino problemi, farei semplicemente uno snapshot e eseguirò il rollback durante il lavoro. L'utilizzo di diversi OS e il controllo del checksum dei file dovrebbe dirti se è successo qualcosa, quindi il ripristino dai backup sarebbe probabilmente più che sufficiente, poiché qualsiasi cosa per rompere la VM e influire sui diversi SO dovrebbe essere molto mirata solo per te.

Ci sono alcuni rischi teorici (che non sono stati ancora provati) che renderebbero l'approccio dual-boot meno sicuro. Questi implicano lo scaricamento di un trojan su un componente hardware non standard. Ad esempio, infettando il firmware della batteria con qualcosa che andrà poi in overflow nel power manager del kernel. Questo potrebbe attraversare i confini di riavvio e non hai davvero voce in capitolo. L'approccio VM non soffrirebbe di questa debolezza.

Per quanto ne so, questi sono a prova di concetto nella migliore delle ipotesi, ma poi di nuovo, è nel mondo dei whitehat. Non sarei sorpreso se la NSA ha questo funzionamento.