Il passthrough ethernet USB su una macchina virtuale KVM può isolare le vulnerabilità del kernel relative alla rete?

Questa è una domanda difficile a cui rispondere poiché misurare la superficie di attacco è difficile. Ma supponiamo di "misurarlo" in base a ciò che pensiamo sia la quantità di elaborazione dei dati non attendibili in una parte dello stack di rete.

Am I right in assuming that with both methods (PCI & USB passthrough), I'm actually reducing the attack surface in the host kernel in regards to networking? In my mind, with that solution, the host kernel simply passes through data to the virtual machine and none of the network traffic touches any part of host kernel's networking code. Is that right?

Per quanto ne so, sì. I metodi passthrough riducono l'elaborazione del sistema operativo host nei dati. Ad esempio, è possibile trovare prove di ciò nella documentazione di VirtualBox:

this feature allows to directly use physical PCI devices on the host by the guest even if host doesn't have drivers for this particular device.

Ciò significa che il sistema operativo host non utilizza nemmeno un driver per gestire i dati passthrough (PCI).

Are there glaring problems with passing through a device via USB that renders the isolation of networking in the virtual machine useless/pointless? I'm not worried about the physical security of the machine, e.g. I don't have to defend against someone plugging in a rogue USB adapter that would convince the host's USB 3 controller to do anything it wasn't supposed to do. My main goal is to make remote exploits more difficult.

Come puoi leggere qui , VirtualBox utilizza un driver per gestire la gestione passthrough USB. Ciò significa che la superficie di attacco dell'host è grande quanto la superficie esposta dal driver. Questo driver vive nel tuo host. Pertanto, questo è il compromesso. O l'host esegue lo stack di rete o lo spinge verso il basso su una VM e fa in modo che l'host esegua solo i driver richiesti. Si noti che sembra (almeno per VirtualBox) che questi driver non gestiscono i dati effettivi. Ma lo sto ancora contando come superficie d'attacco, per ogni evenienza.

Is the whole endeavor a lost cause? E.g. am I worried about holes in a tried-and-true part of the kernel, while adding a larger attack surface to the system by using virtualization? Am I actually decreasing the overall security of the system by using KVM?

Penso che stai riducendo la superficie di attacco dell'host in generale. Ma il prezzo che stai pagando (complessità, penalità di runtime) deve essere considerato. C'è solo una decisione progettuale che devi prendere, in base alle tue esigenze.

Per riassumere i miei pensieri:

Sembra che la tua soluzione ridurrà la superficie di attacco al prezzo della prestazione. La superficie di attacco lasciata all'host non esisterà (passthrough PCI) o sarà solo un driver che gestisce le "attestazioni" della VM su dispositivi USB (passthrough USB).

Sì, questo può ridurre la superficie di attacco del kernel host. Può anche essere utile per isolare i dispositivi nel caso in cui abbiate rotto la tabella DMAR e non sia possibile proteggere dagli attacchi DMA in altro modo. Questo è qualcosa che ho fatto in passato per la maggior parte dei dispositivi PCI. Alcune cose da considerare:

Utilizza VFIO, non passthrough PCI

VFIO è più recente e isolerà correttamente i dispositivi nei gruppi IOMMU , mentre il passthrough PCI può potenzialmente essere bypassato se ci sono dispositivi che non sono passati attraverso lo stesso gruppo IOMMU. Dal link precedente:

IOMMU groups try to describe the smallest sets of devices which can be considered isolated from the perspective of the IOMMU. [...] Legacy KVM device assignment will allow a user to assign these devices separately, but the configuration is guaranteed to fail. VFIO is governed by IOMMU groups and therefore prevents configurations which violate this most basic requirement of IOMMU granularity.

Fai attenzione alle ROM delle opzioni

C'è una cosa che dovresti tenere a mente, però. Quando si passa il dispositivo PCI direttamente a un guest, l'ospite ottiene un accesso raw allo spazio di configurazione PCI, incluso l'accesso in lettura / scrittura all'opzione ROM. Un'opzione ROM è un po 'di firmware memorizzato su determinati dispositivi che viene eseguito dal BIOS durante l'avvio iniziale. Se il kernel guest viene dirottato, anche se non può fuggire nell'host, sarà in grado di scrivere sull'opzione ROM sul dispositivo fisico e attendere il prossimo riavvio, momento in cui l'opzione ROM viene richiamata dal BIOS , sottoponendoti a un rootkit BIOS.

Tuttavia, esiste un modo per mitigare questo rischio. Intel TXT consente di verificare le ROM opzionali prima che vengano chiamate. Ciò richiede il settaggio di boot, che abilita correttamente varie funzioni TXT all'avvio. La documentazione ufficiale è disponibile qui . Questo è molto importante, quindi non ignorarlo!

Indurisci i componenti dello spazio utente

Di gran lunga, la maggior parte delle vulnerabilità sarà presente nel componente userspace (QEMU, o forse kvmtool), quindi la protezione di questa dovrebbe essere una priorità elevata. Supponendo che userete QEMU, dovreste assicurarvi che limiti il suo accesso al filesystem a una directory vuota con la direttiva -chroot . Deve passare a un utente dedicato e non privilegiato con la direttiva -runas e deve abilitare una sandbox seccomp con la direttiva -sandbox . La superficie di attacco può essere ulteriormente ridotta in altri modi, disattivando le funzioni non necessarie (ACPI, RTC, ecc.) E impostando i limiti delle risorse. Si consiglia inoltre l'uso di un MAC come AppArmor o SELinux. Se compilerai QEMU dal codice sorgente, puoi rafforzarlo ulteriormente in fase di compilazione con i giusti flag di gcc.

Annulla entrambi i kernel

È molto importante, se vuoi una superficie di attacco ridotta, usare grsecurity sia per l'host che per l'ospite. Inoltre, grsecurity fornirà PaX, che ha componenti che rafforzano i componenti dello spazio utente come QEMU. Se QEMU viene utilizzato con -enable-kvm , allora è sicuro usare le impostazioni di PaX più severe con esso. La versione commerciale di grsecurity non è necessaria. Tutto ciò che è è un kernel stabile che non si aggiorna tanto spesso. Non è necessario a meno che tu non stia utilizzando un server ad alta disponibilità.