Non hai moitos artigos sobre Habré dedicados ao sistema operativo Qubes, e os que vin non describen gran parte da experiencia de usalo. Por debaixo do corte, espero corrixilo usando o exemplo de uso de Qubes como medio de protección (contra) o ambiente Windows e, ao mesmo tempo, estimar o número de usuarios rusofalantes do sistema.
Por que Qubes?
A historia do fin do soporte técnico para Windows 7 e a crecente ansiedade dos usuarios levou á necesidade de organizar o traballo deste SO, tendo en conta os seguintes requisitos:
- garantir o uso de Windows 7 totalmente activado coa posibilidade de que o usuario instale actualizacións e varias aplicacións (incluíndo a través de Internet);
- implementar a exclusión completa ou selectiva das interaccións de rede en función das condicións (operación autónoma e modos de filtrado de tráfico);
- proporcionar a capacidade de conectar selectivamente medios e dispositivos extraíbles.
Este conxunto de restricións presupón un usuario claramente preparado, xa que se permite a administración independente, e as restricións non están relacionadas co bloqueo das súas posibles accións, senón coa exclusión de posibles erros ou efectos destrutivos do software. Eses. Non hai ningún delincuente interno no modelo.
Na nosa procura dunha solución, abandonamos rapidamente a idea de implementar restricións usando ferramentas integradas ou adicionais de Windows, xa que é bastante difícil restrinxir de forma efectiva a un usuario con dereitos de administrador, deixándolle a posibilidade de instalar aplicacións.
A seguinte solución foi o illamento mediante a virtualización. As ferramentas coñecidas para a virtualización de escritorios (por exemplo, como virtualbox) son pouco adecuadas para resolver problemas de seguridade e as restricións indicadas terán que facerlas o usuario cambiando ou axustando constantemente as propiedades da máquina virtual convidada (en diante como VM), o que aumenta o risco de erros.
Ao mesmo tempo, tiñamos experiencia usando Qubes como sistema de escritorio do usuario, pero tiñamos dúbidas sobre a estabilidade de traballar con Windows convidado. Decidiuse comprobar a versión actual de Qubes, xa que as limitacións indicadas encaixan moi ben no paradigma deste sistema, especialmente a implementación de modelos de máquinas virtuais e a integración visual. A continuación, tentarei falar brevemente das ideas e ferramentas de Qubes, utilizando o exemplo de resolución do problema.
Tipos de virtualización Xen
Qubes baséase no hipervisor Xen, que minimiza as funcións de xestión de recursos do procesador, memoria e máquinas virtuais. Todo o demais traballo con dispositivos concéntrase en dom0 baseado no núcleo de Linux (Qubes para dom0 usa a distribución Fedora).
Xen admite varios tipos de virtualización (porei exemplos para a arquitectura Intel, aínda que Xen admite outros):
- paravirtualización (PV): un modo de virtualización sen o uso de soporte de hardware, que lembra a virtualización de contedores, pódese usar para sistemas cun núcleo adaptado (dom0 funciona neste modo);
- virtualización completa (HVM): neste modo, utilízase soporte de hardware para os recursos do procesador e todos os demais equipos emulan mediante QEMU. Esta é a forma máis universal de executar varios sistemas operativos;
- paravirtualización de hardware (PVH - ParaVirtualized Hardware) - un modo de virtualización que utiliza soporte de hardware cando, para traballar con hardware, o núcleo do sistema convidado usa controladores adaptados ás capacidades do hipervisor (por exemplo, memoria compartida), eliminando a necesidade de emular QEMU e aumentar o rendemento de E/S. O núcleo de Linux a partir da versión 4.11 pode funcionar neste modo.
A partir de Qubes 4.0, por razóns de seguridade, abróchase o uso do modo de paravirtualización (incluso debido a vulnerabilidades coñecidas na arquitectura de Intel, que son parcialmente mitigadas polo uso da virtualización completa); o modo PVH úsase por defecto.
Cando se usa a emulación (modo HVM), QEMU lánzase nunha máquina virtual illada chamada stubdomain, co que se reducen os riscos de explotar posibles erros na implementación (o proxecto QEMU contén moito código, incluso para compatibilidade).
No noso caso, este modo debería usarse para Windows.
Servizo de máquinas virtuais
Na arquitectura de seguridade Qubes, unha das capacidades fundamentais do hipervisor é a transferencia de dispositivos PCI ao contorno de hóspedes. A exclusión de hardware permítelle illar a parte host do sistema de ataques externos. Xen admite isto para os modos PV e HVM, no segundo caso require soporte para IOMMU (Intel VT-d): xestión de memoria de hardware para dispositivos virtualizados.
Isto crea varias máquinas virtuais do sistema:
- sys-net, ao que se transfiren dispositivos de rede e que se utiliza como ponte para outras máquinas virtuales, por exemplo, as que implementan as funcións dun firewall ou dun cliente VPN;
- sys-usb, ao que se transfiren controladores USB e outros dispositivos periféricos;
- sys-firewall, que non usa dispositivos, pero funciona como un firewall para máquinas virtuales conectadas.
Para traballar con dispositivos USB utilízanse servizos proxy, que proporcionan, entre outras cousas:
- para a clase de dispositivo HID (dispositivo de interface humana), enviando comandos a dom0;
- para medios extraíbles, redirección de volumes de dispositivos a outras máquinas virtuales (excepto dom0);
- redirixindo directamente a un dispositivo USB (usando USBIP e ferramentas de integración).
Nesta configuración, un ataque exitoso a través da pila de rede ou dos dispositivos conectados pode levar a comprometer só a máquina virtual do servizo en execución, e non todo o sistema no seu conxunto. E despois de reiniciar o servizo VM, cargarase no seu estado orixinal.
Ferramentas de integración de VM
Hai varias formas de interactuar co escritorio dunha máquina virtual: instalando aplicacións no sistema convidado ou emulando vídeo mediante ferramentas de virtualización. As aplicacións convidadas poden ser varias ferramentas de acceso remoto universais (RDP, VNC, Spice, etc.) ou adaptadas a un hipervisor específico (esteas ferramentas adoitan denominarse utilidades convidadas). Tamén se pode usar unha opción mixta, cando o hipervisor emula E/S para o sistema convidado e proporciona externamente a posibilidade de usar un protocolo que combina E/S, por exemplo, como Spice. Ao mesmo tempo, as ferramentas de acceso remoto adoitan optimizar a imaxe, xa que implican traballar a través dunha rede, o que non repercute positivamente na calidade da imaxe.
Qubes ofrece as súas propias ferramentas para a integración de máquinas virtuales. Primeiro de todo, este é un subsistema de gráficos: as fiestras de diferentes máquinas virtuales móstranse nun único escritorio co seu propio marco de cor. En xeral, as ferramentas de integración baséanse nas capacidades do hipervisor: memoria compartida (táboa de subvencións Xen), ferramentas de notificación (canle de eventos Xen), almacenamento compartido xenstore e protocolo de comunicación vchan. Coa súa axuda impléntanse os compoñentes básicos qrexec e qubes-rpc, e os servizos de aplicacións: redirección de audio ou USB, transferencia de ficheiros ou contidos do portapapeis, execución de comandos e inicio de aplicacións. É posible establecer políticas que che permitan limitar os servizos dispoñibles nunha máquina virtual. A figura seguinte é un exemplo do procedemento para inicializar a interacción de dúas máquinas virtuales.
Así, o traballo na máquina virtual realízase sen utilizar unha rede, o que permite o pleno uso de máquinas virtuales autónomas para evitar fugas de información. Por exemplo, así se implementa a separación de operacións criptográficas (PGP/SSH), cando se usan chaves privadas en máquinas virtuales illadas e non van máis alá delas.
Modelos, aplicacións e máquinas virtuales únicas
Todo o traballo dos usuarios en Qubes realízase en máquinas virtuais. O sistema principal utilízase para controlalos e visualizalos. O SO está instalado xunto cun conxunto básico de máquinas virtuais baseadas en modelos (TemplateVM). Este modelo é unha máquina virtual Linux baseada na distribución Fedora ou Debian, con ferramentas de integración instaladas e configuradas, e particións de usuario e sistema dedicadas. A instalación e actualización do software realízase por un xestor de paquetes estándar (dnf ou apt) desde repositorios configurados con verificación obrigatoria de sinatura dixital (GnuPG). O propósito de tales máquinas virtuales é garantir a confianza nas máquinas virtuales de aplicación lanzadas sobre a súa base.
No inicio, unha máquina virtual de aplicación (AppVM) usa unha instantánea da partición do sistema do modelo de máquina virtual correspondente e, ao finalizar, elimina esta instantánea sen gardar os cambios. Os datos requiridos polo usuario gárdanse nunha partición de usuario única para cada VM da aplicación, que está montada no directorio de inicio.
Usar máquinas virtuales desbotables (disposableVM) pode ser útil dende o punto de vista da seguridade. Tal VM créase en base a un modelo no momento do inicio e lánzase cun único propósito: executar unha aplicación e completar o traballo despois de pechar a mesma. As máquinas virtuales desbotables pódense usar para abrir ficheiros sospeitosos cuxos contidos poidan levar á explotación de vulnerabilidades específicas de aplicacións. A capacidade de executar unha máquina virtual única está integrada no xestor de ficheiros (Nautilus) e no cliente de correo electrónico (Thunderbird).
A máquina virtual de Windows tamén se pode usar para crear un modelo e unha máquina virtual única movendo o perfil de usuario a unha sección separada. Na nosa versión, tal modelo será utilizado polo usuario para tarefas de administración e instalación de aplicacións. En función do modelo, crearanse varias máquinas virtuales de aplicacións, con acceso limitado á rede (capacidades estándar de firewall sys) e sen acceso á rede (non se crea un dispositivo de rede virtual). Todos os cambios e aplicacións instaladas no modelo estarán dispoñibles para funcionar nestas máquinas virtuales, e aínda que se introduzan programas de marcadores, non terán acceso á rede para comprometerse.
Loita por Windows
As funcións descritas anteriormente son a base de Qubes e funcionan de forma bastante estable; as dificultades comezan con Windows. Para integrar Windows, debes utilizar un conxunto de ferramentas convidadas Qubes Windows Tools (QWT), que inclúe controladores para traballar con Xen, un controlador de qvideo e un conxunto de utilidades para o intercambio de información (transferencia de ficheiros, portapapeis). O proceso de instalación e configuración está documentado en detalle na páxina web do proxecto, polo que compartiremos a nosa experiencia de aplicación.
A principal dificultade é esencialmente a falta de soporte para as ferramentas desenvolvidas. Parece que Key Developers (QWT) non está dispoñible e o proxecto de integración de Windows está á espera dun desenvolvedor principal. Por iso, en primeiro lugar, foi necesario avaliar o seu rendemento e comprender a posibilidade de apoialo de forma independente, se fose necesario. O máis difícil de desenvolver e depurar é o controlador de gráficos, que emula o adaptador de vídeo e a pantalla para xerar unha imaxe na memoria compartida, o que permite mostrar todo o escritorio ou a xanela da aplicación directamente na xanela do sistema host. Durante a análise do funcionamento do controlador, adaptamos o código para a montaxe nun ambiente Linux e elaboramos un esquema de depuración entre dous sistemas convidados de Windows. Na fase de construción cruzada, fixemos varios cambios que simplificaron as cousas para nós, principalmente en termos de instalación "silenciosa" de utilidades, e tamén eliminamos a molesta degradación do rendemento cando traballamos nunha máquina virtual durante moito tempo. Presentamos os resultados do traballo nunha parte , polo que non por moito tempo Desenvolvedor principal Qubes.
A etapa máis crítica en canto á estabilidade do sistema convidado é o inicio de Windows, aquí podes ver a coñecida pantalla azul (ou nin sequera vela). Para a maioría dos erros identificados, houbo varias solucións: eliminar os controladores de dispositivos de bloque Xen, desactivar o equilibrio da memoria da máquina virtual, corrixir a configuración da rede e minimizar o número de núcleos. As nosas ferramentas para invitados constrúen instalacións e execútanse en Windows 7 e Windows 10 totalmente actualizados (excepto qvideo).
Ao pasar dun ambiente real a un virtual, xorde un problema coa activación de Windows se se usan versións OEM preinstaladas. Estes sistemas usan a activación baseada nas licenzas especificadas na UEFI do dispositivo. Para procesar correctamente a activación, é necesario traducir unha das seccións ACPI completas do sistema host (táboa SLIC) ao sistema convidado e editar lixeiramente as demais, rexistrando o fabricante. Xen permite personalizar o contido ACPI das táboas adicionais, pero sen modificar as principais. Un parche dun proxecto similar de OpenXT, que foi adaptado para Qubes, axudou coa solución. As correccións non só nos pareceron útiles e foron traducidas ao repositorio principal de Qubes e á biblioteca Libvirt.
As desvantaxes obvias das ferramentas de integración de Windows inclúen a falta de soporte para audio, dispositivos USB e a complexidade de traballar con medios, xa que non hai soporte de hardware para a GPU. Pero o anterior non impide o uso da VM para traballar con documentos ofimáticos, nin tampouco o lanzamento de aplicacións corporativas específicas.
O requisito de cambiar ao modo operativo sen rede ou cunha rede limitada despois de crear un modelo de máquina virtual de Windows cumpriuse creando as configuracións adecuadas de máquinas virtuales de aplicacións e a posibilidade de conectar selectivamente medios extraíbles tamén se solucionou mediante ferramentas do sistema operativo estándar cando se conectan. , están dispoñibles na VM do sistema sys-usb, desde onde se poden "reenviar" á VM requirida. O escritorio do usuario parece algo así.
A versión final do sistema foi aceptada positivamente (na medida que o permita unha solución tan ampla) polos usuarios, e as ferramentas estándar do sistema permitiron ampliar a aplicación á estación de traballo móbil do usuario con acceso vía VPN.
En vez de unha conclusión
A virtualización en xeral permítelle reducir os riscos de usar sistemas Windows sen soporte: non obriga a compatibilidade co hardware novo, permite excluír ou controlar o acceso ao sistema a través da rede ou a través de dispositivos conectados e permite implementar un ambiente de lanzamento único.
Baseándose na idea do illamento mediante a virtualización, Qubes OS axúdache a aproveitar estes e outros mecanismos para a seguridade. Desde fóra, moitas persoas ven en Qubes principalmente como un desexo de anonimato, pero é un sistema útil tanto para os enxeñeiros, que adoitan facer malabarismos con proxectos, infraestruturas e segredos para acceder a eles, como para os investigadores de seguridade. A separación de aplicacións, os datos e a formalización da súa interacción son os pasos iniciais da análise de ameazas e do deseño do sistema de seguridade. Esta separación axuda a estruturar a información e reducir a probabilidade de erros debido ao factor humano: présa, fatiga, etc.
Actualmente, o principal énfase no desenvolvemento é ampliar a funcionalidade dos ambientes Linux. Prepárase a versión 4.1 para o lanzamento, que estará baseada en Fedora 31 e incluirá as versións actuais dos compoñentes clave Xen e Libvirt. Cómpre sinalar que Qubes é creado por profesionais da seguridade da información que sempre lanzan actualizacións de inmediato se se identifican novas ameazas ou erros.
Posterior
Unha das capacidades experimentais que estamos a desenvolver permítenos crear máquinas virtuales con soporte para o acceso de convidados á GPU baseada na tecnoloxía Intel GVT-g, o que nos permite utilizar as capacidades do adaptador gráfico e ampliar significativamente o alcance do sistema. No momento de escribir este artigo, esta funcionalidade funciona para as versións de proba de Qubes 4.1 e está dispoñible en .
Fonte: www.habr.com