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

8

Eseguo due sistemi operativi su due partizioni disco separate sulla stessa macchina fisica (un MacBook Pro moderno). Per isolarli gli uni dagli altri, ho seguito i seguenti passi:

  1. Configurato / etc / fstab con ro, noauto (sola lettura, senza auto-mount)

  2. Codifica completamente ogni partizione con una chiave di crittografia separata     (impegnato nella memoria)

Supponiamo che un virus infetti la mia prima partizione all'insaputa di me. Esco dalla prima partizione (che crittografa il volume), quindi spengo la macchina per cancellare la RAM. Quindi disintegro e avvio nella seconda partizione. Posso essere ragionevolmente sicuro che il virus non ha / non può infettare entrambe le partizioni o sto giocando con il fuoco qui? Mi rendo conto che gli MBP non vengono forniti con un TPM, quindi l'infezione da boot loader che passa inosservata è ancora una possibilità teorica. Tuttavia, questo rischio sembra pari al rischio che l'hypervisor VMWare / VirtualBox venga sfruttato durante l'esecuzione di un sistema operativo guest, soprattutto perché la linea MBP utilizza UEFI anziché BIOS.

Questo porta alla mia domanda: l'approccio dual-partitioning delineato sopra più o meno sicuro rispetto all'utilizzo di una macchina virtuale per l'isolamento dei servizi? Questo cambierebbe se sul mio computer fosse installato un TPM?

Sfondo:

Nota che ovviamente sto prendendo tutte le solite precauzioni aggiuntive, come il controllo degli aggiornamenti del software del sistema ogni giorno, non l'accesso come utente amministratore a meno che non sia assolutamente necessario, eseguendo programmi antivirus in tempo reale su entrambe le partizioni, eseguendo un host- firewall basato, monitoraggio delle connessioni di rete in uscita, ecc. La mia domanda è in realtà un controllo pubblico per vedere se sto trascurando qualcosa qui e cercare di capire se il mio schema dual-boot è effettivamente più sicuro della rotta della Macchina Virtuale. Ancora più importante, sto solo cercando di saperne di più sui problemi di sicurezza.

EDIT # 1:

Come sottolineato nei commenti, lo scenario è un po 'paranoico per il mio caso particolare d'uso. Pensa alle persone che potrebbero trovarsi in contesti aziendali o governativi e stanno prendendo in considerazione l'idea di utilizzare una macchina virtuale per eseguire servizi o applicazioni considerati "ad alto rischio". Stanno meglio usando una VM o uno scenario dual-boot come ho delineato? Una risposta che pesa efficacemente tutti i pro / contro per quel trade-off è ciò che cerco davvero in una risposta a questo post.

EDIT # 2:

Questa domanda è stata parzialmente alimentata dal dibattito sul fatto che una macchina virtuale effettivamente protegga un sistema operativo host a tutti. Personalmente, penso di sì, ma considera questa citazione di Theo de Raadt sulla mailing list di OpenBSD:

x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes.

-http: //kerneltrap.org/OpenBSD/Virtualization_Security

Citando l'argomento di Theo, non lo approvo. Sto semplicemente sottolineando che ci sono molte prospettive qui, quindi sto cercando di saperne di più sul problema.

    
posta Mark 27.06.2012 - 23:22
fonte

4 risposte

10

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.

    
risposta data 28.06.2012 - 00:07
fonte
6

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.

    
risposta data 29.06.2012 - 08:27
fonte
4

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.

    
risposta data 27.06.2012 - 23:36
fonte
0

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.

    
risposta data 29.03.2014 - 04:47
fonte

Leggi altre domande sui tag