¿Puede el paso de Ethernet a una máquina virtual KVM aislar las vulnerabilidades del kernel relacionadas con la red?

Esta es una pregunta difícil de responder ya que medir la superficie de ataque es difícil. Pero supongamos que lo "medimos" por lo que creemos que es la cantidad de procesamiento que los datos no confiables pasan en alguna parte de la pila de redes.

  

¿Tengo razón al suponer que con ambos métodos (PCI y USB passthrough), en realidad estoy reduciendo la superficie de ataque en el núcleo del host en lo que respecta a la red? En mi opinión, con esa solución, el núcleo del host simplemente pasa a través de los datos a la máquina virtual y ninguno de los tráficos de la red toca ninguna parte del código de red del núcleo del host. ¿Es eso correcto?

Por lo que yo sé, sí. Los métodos de transferencia reducen el procesamiento que el sistema operativo del host realiza a los datos. Por ejemplo, la evidencia de esto se puede encontrar en la documentación de 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.

Esto significa que el sistema operativo host ni siquiera utiliza un controlador para manejar los datos de paso (PCI).

  

¿Hay problemas evidentes al pasar a través de un dispositivo a través de USB que hace que el aislamiento de las redes en la máquina virtual sea inútil / inútil? No me preocupa la seguridad física de la máquina, por ejemplo, No tengo que defenderme contra alguien que esté enchufando un adaptador USB falso que podría convencer al controlador USB 3 del host para que haga cualquier cosa que no debería hacer. Mi objetivo principal es hacer que las explotaciones remotas sean más difíciles.

Como puede leer aquí , VirtualBox usa un controlador para manejar la administración de paso a través de USB. Esto significa que la superficie de ataque del host es tan grande como la superficie que expone el controlador. Este conductor vive en tu host. Por lo tanto, esta es la compensación. Puede hacer que el host ejecute la pila de red o empujarlo hacia una VM y hacer que el host ejecute solo los controladores necesarios. Tenga en cuenta que parece (al menos para VirtualBox) que estos controladores no manejan los datos reales. Pero todavía lo estoy considerando como superficie de ataque, por si acaso.

  

¿Es todo el esfuerzo una causa perdida? P.ej. ¿Me preocupan los agujeros en una parte probada y verdadera del kernel, mientras agrego una superficie de ataque más grande al sistema mediante el uso de la virtualización? ¿Realmente estoy reduciendo la seguridad general del sistema mediante el uso de KVM?

Creo que estás reduciendo la superficie de ataque del host en general. Pero el precio que está pagando (complejidad, penalizaciones de tiempo de ejecución) debe ser considerado. Solo debe tomar una decisión de diseño, de acuerdo con sus requisitos.

Para resumir mis pensamientos:

Parece que su solución reducirá la superficie de ataque al precio del rendimiento. La superficie de ataque que queda en el host o bien no existirá (paso a través de PCI) o solo será un controlador que maneje las "reclamaciones" de VM a través de dispositivos USB (paso a través de USB).

Sí, esto puede reducir el área de superficie de ataque del kernel del host. También puede ser útil para aislar dispositivos en el caso de que haya roto la tabla DMAR y no pueda protegerse de los ataques DMA de lo contrario. Esto es algo que he hecho en el pasado para la mayoría de los dispositivos PCI. Algunas cosas a considerar:

Utilice VFIO, no el paso a través de PCI

VFIO es más nuevo y aislará correctamente los dispositivos en sus grupos IOMMU , mientras que el paso a través de PCI se puede omitir potencialmente si hay dispositivos que no se pasan a través de los cuales están en el mismo grupo de IOMMU. Desde el enlace de arriba:

  

Los grupos de IOMMU intentan describir los conjuntos más pequeños de dispositivos que pueden considerarse aislados desde la perspectiva de la IOMMU. [...] La asignación de dispositivos KVM heredados permitirá al usuario asignar estos dispositivos por separado, pero se garantiza que la configuración fallará. VFIO se rige por los grupos de IOMMU y, por lo tanto, evita configuraciones que violan este requisito más básico de la granularidad de IOMMU.

Cuidado con las ROM de opción

Sin embargo, hay una cosa que debes tener en cuenta. Sin embargo, cuando pasa el dispositivo PCI directamente a un invitado, el invitado obtiene acceso directo al espacio de configuración de PCI, incluido el acceso de lectura / escritura a la ROM opcional. Una ROM de opción es un poco de firmware almacenado en ciertos dispositivos que se ejecuta por el BIOS durante el inicio temprano. Si el núcleo invitado es secuestrado, incluso si no puede escapar al host, podrá escribir en la ROM de opción en el dispositivo físico y esperar hasta que vuelva a arrancar, en cuyo momento el BIOS llama a la ROM de opción. , sometiéndote a un rootkit de BIOS.

Sin embargo, hay una manera de mitigar este riesgo. Intel TXT le permite verificar las ROM opcionales antes de llamarlas. Esto requiere que configure tboot, que habilita varias características de TXT en el arranque, correctamente. La documentación oficial está disponible aquí . Esto es muy importante, ¡así que no lo ignore!

Harden los componentes del espacio de usuario

Por el momento, la mayoría de las vulnerabilidades estarán presentes en el componente del espacio de usuario (QEMU, o quizás kvmtool), por lo que asegurar esto debería ser una prioridad alta. Suponiendo que utilizará QEMU, debe asegurarse de que restringe el acceso de su sistema de archivos a un directorio vacío con la directiva -chroot . Debe pasar a un usuario dedicado y sin privilegios con la directiva -runas , y debe habilitar un sandbox seccomp con la directiva -sandbox . La superficie de ataque puede reducirse aún más de otras formas, deshabilitando funciones innecesarias (ACPI, RTC, etc.) y estableciendo límites de recursos. También se recomienda utilizar un MAC como AppArmor o SELinux. Si va a compilar QEMU desde la fuente, puede endurecerlo aún más en tiempo de compilación con los indicadores de gcc correctos.

Endurece ambos núcleos

Es muy importante, si quieres reducir la superficie de ataque, usar grsecurity tanto para el anfitrión como para el invitado. Además, grsecurity proporcionará PaX, que tiene componentes que fortalecen los componentes del espacio de usuario como QEMU. Si QEMU se usa con -enable-kvm , entonces es seguro usar la configuración de PaX más estricta con él. La versión comercial de grsecurity no es necesaria. Todo lo que es es un núcleo estable que no se actualiza tan a menudo. No es necesario a menos que esté ejecutando servidores de alta disponibilidad.