No Habr há poucos artigos dedicados ao sistema operacional Qubes, e aqueles que vi pouco descrevem a experiência de uso. Espero corrigir isso, usando o Qubes como uma ferramenta de proteção do ambiente Windows e, ao mesmo tempo, avaliar o número de usuários de língua russa desse sistema.
Por que Qubes?
A história do término do suporte técnico ao Windows 7 e a crescente preocupação dos usuários levaram à necessidade de organizar o trabalho desse sistema operacional, considerando os seguintes requisitos:
- garantir o uso de um Windows 7 totalmente ativado, com a possibilidade de o usuário instalar atualizações e diversos aplicativos (inclusive pela Internet);
- implementar a exclusão total ou seletiva de interações de rede com base em condições (modos de operação off-line e filtragem de tráfego);
- fornecer a possibilidade de conexão seletiva de dispositivos e mídias removíveis.
Esse conjunto de restrições pressupõe um usuário claramente preparado, uma vez que a administração independente é permitida, e as restrições não estão relacionadas a bloquear suas ações potenciais, mas sim a evitar possíveis erros ou impactos destrutivos de software. Ou seja, não existe um infrator interno no modelo.
Na busca por uma solução, rapidamente abandonamos a ideia de implementar restrições por meio de ferramentas integradas ou adicionais do Windows, uma vez que é bastante difícil limitar efetivamente um usuário com privilégios de administrador, deixando-lhe a possibilidade de instalar aplicativos.
A próxima opção para solucionar o problema foi a isolamento através da virtualização. Ferramentas amplamente conhecidas para virtualização de desktop (como o virtualbox) são mal adaptadas para atender às demandas de segurança, e as restrições mencionadas teriam que ser implementadas pelo usuário, que precisaria constantemente alternar ou ajustar as propriedades da máquina virtual (MV), o que aumenta os riscos de erros.
Ao mesmo tempo, tivemos experiência com o uso do Qubes como sistema operacional de desktop, mas havia dúvidas sobre a estabilidade ao trabalhar com o Windows como convidado. Decidimos testar a versão atual do Qubes, uma vez que as limitações impostas se encaixam muito bem na melhoradas da arquitetura deste sistema, especialmente a implementação de modelos de máquinas virtuais e a integração visual. A seguir, tentarei resumir brevemente as ideias e ferramentas do Qubes, usando como exemplo a solução do problema proposto.
Tipos de virtualização do Xen
No núcleo do Qubes está o hipervisor Xen, que minimiza suas funções de gerenciamento de recursos de CPU, memória e máquinas virtuais. Todo o restante do trabalho com dispositivos está concentrado no dom0 baseado no kernel Linux (no Qubes, é utilizado uma distribuição Fedora para o dom0).
O Xen suporta vários tipos de virtualização (eu vou usar exemplos para a arquitetura Intel, embora o Xen suporte outras):
- paravirtualização (PV) — modo de virtualização sem uso de suporte de hardware, semelhante à virtualização de contêineres, que pode ser usado para sistemas com um kernel adaptado (é assim que o dom0 funciona);
- virtualização completa (HVM) — neste modo, o suporte de hardware é utilizado para os recursos da CPU, enquanto todos os outros dispositivos são emulados pelas ferramentas do QEMU. Este é o método mais universal para executar diferentes sistemas operacionais;
- paravirtualização de hardware (PVH — Hardware ParaVirtualizado) — modo de virtualização que utiliza suporte de hardware quando o kernel do sistema operacional convidado utiliza drivers adaptados às capacidades do hipervisor (por exemplo, memória compartilhada), eliminando a necessidade de emulação do QEMU e aumentando a performance de entrada e saída. O kernel Linux a partir da versão 4.11 pode operar neste modo.
A partir da versão 4.0 do Qubes, por motivos de segurança, há uma rejeição ao uso do modo de paravirtualização (também em relação às vulnerabilidades conhecidas da arquitetura Intel, que são parcialmente mitigadas ao utilizar a virtualização completa), o modo PVH é utilizado por padrão.
Ao utilizar a emulação (modo HVM), o QEMU é iniciado em uma VM isolada chamada stubdomain, reduzindo assim os riscos de exploração de possíveis falhas na implementação (o projeto QEMU contém muito código, incluindo para compatibilidade).
Esse modo deve ser utilizado para Windows, no nosso caso.
Máquinas Virtuais de Serviço
Na arquitetura de segurança do Qubes, uma das principais funcionalidades do hipervisor é a passagem de dispositivos PCI para o ambiente convidado. A exclusão de hardware permite isolar a parte host do sistema de ataques externos. O Xen suporta isso para os modos PV e HVM, sendo que, no segundo caso, é necessária a assistência do IOMMU (Intel VT-d) — gerenciamento de memória de hardware para dispositivos virtualizados.
Assim, várias máquinas virtuais do sistema são criadas:
- sys-net, que recebe dispositivos de rede e é usada como ponte para outras VMs, por exemplo, aquelas que implementam funções de firewall ou cliente de rede VPN;
- sys-usb, que recebe USB e outros controladores de dispositivos periféricos;
- sys-firewall, que não utiliza dispositivos, mas funciona como um firewall para as VMs conectadas.
Para trabalhar com dispositivos USB, são utilizados serviços de proxy, que garantem, entre outros:
- para a classe de dispositivos HID (dispositivo de interface humana) a transmissão de comandos para o dom0;
- para mídias removíveis o redirecionamento de volumes de dispositivos para outras VMs (exceto dom0);
- o redirecionamento direto de dispositivos USB (uso de USBIP e ferramentas de integração).
Com essa configuração, um ataque bem-sucedido através da pilha de rede ou de dispositivos conectados pode resultar na comprometimento apenas da VM de serviço em execução, e não de todo o sistema no geral. E após a reinicialização da VM de serviço, ela será carregada em seu estado original.
Ferramentas de Integração de VM
Existem várias maneiras de interagir com a área de trabalho da máquina virtual — instalando aplicativos no sistema convidado ou emulando vídeo através de virtualização. Como aplicativos convidados, podem ser utilizados diferentes softwares de acesso remoto (RDP, VNC, Spice, etc.) ou adaptados a um hipervisor específico (esse tipo de ferramenta costuma ser chamado de utilitários convidados). Também é possível utilizar uma variante mista, onde o hipervisor emula I/O para o sistema convidado, ao mesmo tempo em que oferece a possibilidade de usar um protocolo que combina I/O, como no caso do Spice. Nesse contexto, os softwares de acesso remoto geralmente otimizam a imagem, uma vez que se espera que funcionem através de uma rede, o que afeta a qualidade da imagem de maneira negativa.
O Qubes fornece suas próprias ferramentas para a integração de VMs. Em primeiro lugar, está o subsistema gráfico — janelas de várias VMs são exibidas em uma única área de trabalho com uma moldura colorida própria. De modo geral, as ferramentas de integração são baseadas nas capacidades do hipervisor — memória compartilhada (Xen grant table), meios de notificação (Xen event channel), armazenamento compartilhado xenstore e protocolo de comunicação vchan. Com eles, são implementados os componentes básicos qrexec e qubes-rpc, bem como serviços aplicacionais — redirecionamento de áudio ou USB, transferência de arquivos ou conteúdo da área de transferência, execução de comandos e lançamento de aplicativos. Há a possibilidade de estabelecer políticas que permitem restringir os serviços disponíveis nas VMs. Na imagem abaixo, um exemplo do procedimento de inicialização de interação entre duas VMs.
Dessa forma, o trabalho nas VMs é realizado sem o uso da rede, o que permite utilizar plenamente VMs autônomas para evitar vazamentos de informações. Por exemplo, assim é realizada a separação de operações criptográficas (PGP/SSH), onde chaves privadas são utilizadas em VMs isoladas e não saem de seus limites.
Modelos, VMs aplicacionais e VMs descartáveis
Todo o trabalho do usuário no Qubes é realizado em máquinas virtuais. O sistema operacional host principal é utilizado para gerenciar suas operações e visualizá-las. O sistema operacional é instalado juntamente com um conjunto básico de máquinas virtuais baseadas em templates (TemplateVM). Este template é uma VM Linux baseada na distribuição Fedora ou Debian, com ferramentas de integração instaladas e configuradas, além de partições dedicadas para o sistema e para o usuário. A instalação e atualização de software é feita pelo gerenciador de pacotes padrão (dnf ou apt) a partir de repositórios configurados com verificação obrigatória de assinatura digital (GnuPG). O objetivo dessas VMs é garantir a confiança nas VMs de aplicação que são executadas com base nelas.
A VM de aplicação (AppVM) ao ser iniciada usa um snapshot da partição do sistema correspondente ao template da VM, e após ser finalizada, exclui esse snapshot sem salvar alterações. Os dados necessários para o usuário são armazenados em uma partição de usuário única para cada VM de aplicação, que é montada no diretório pessoal.
Uma VM descartável (disposibleVM) pode ser útil do ponto de vista da segurança. Essa VM é criada a partir de um template no momento da inicialização e é executada com um único objetivo — rodar um aplicativo, encerrando seu funcionamento após seu fechamento. VMs descartáveis podem ser usadas para abrir arquivos suspeitos, cujo conteúdo pode levar à exploração de vulnerabilidades em aplicativos específicos. A possibilidade de iniciar uma VM descartável está integrada ao gerenciador de arquivos (Nautilus) e ao cliente de e-mail (Thunderbird).
Uma VM Windows também pode ser usada para criar um template e uma VM descartável, para isso o perfil do usuário é transferido para uma partição separada. No nosso caso, esse template será utilizado pelo usuário para tarefas de administração e instalação de aplicativos. A partir desse template, várias VMs de aplicação serão criadas — com acesso limitado à rede (usando as capacidades padrão do sys-firewall) e sem acesso à rede de forma alguma (não sendo criado um dispositivo de rede virtual). Para trabalhar nessas VMs, todas as alterações e aplicativos instalados no template estarão disponíveis e mesmo no caso de inserção de malware, elas não teriam acesso à rede para comprometer.
Luta pelo Windows
As funcionalidades descritas acima são a base do Qubes e funcionam de forma bastante estável; as dificuldades começam com o Windows. Para a integração do Windows, é necessário usar o conjunto de ferramentas Qubes Windows Tools (QWT), que inclui drivers para funcionar com Xen, o driver qvideo e um conjunto de utilitários para troca de informações (recepção e transferência de arquivos, área de transferência). O processo de instalação e configuração é detalhadamente documentado no site do projeto, portanto, compartilharemos nossa experiência de uso.
A principal dificuldade é, na verdade, a falta de suporte para as ferramentas desenvolvidas. Os principais desenvolvedores (QWT), ao que parece, estão indisponíveis e o projeto de integração com o Windows está aguardando um desenvolvedor líder. Portanto, em primeiro lugar, era necessário avaliar a funcionalidade e entender a possibilidade de suporte, se necessário, de forma independente. O aspecto mais desafiador para desenvolvimento e depuração é o driver gráfico, que emula o adaptador de vídeo e a tela para formar imagens na memória compartilhada, permitindo a exibição de toda a área de trabalho ou a janela do aplicativo na janela do sistema host. Durante a análise do funcionamento do driver, adaptamos o código para a montagem em um ambiente Linux e testamos o esquema de depuração entre dois sistemas Windows convidados. Na fase de crossbuilding, fizemos várias alterações que simplificavam para nós, principalmente na parte de instalação "silenciosa" dos utilitários, além de eliminar a notável degradação de desempenho durante longos períodos de operação na VM. Documentamos os resultados de nosso trabalho em uma apresentação separada. , assim, por um breve período, o desenvolvedor líder do Qubes.
A etapa mais crítica em termos de estabilidade do sistema convidado é a inicialização do Windows, onde pode-se observar a conhecida tela azul (ou até mesmo não vê-la). Para a maioria dos erros identificados, havia várias opções de contorno — desistir dos drivers Xen para dispositivos de bloco, desativar o balanceamento de memória da VM, fixar as configurações de rede e minimizar o número de núcleos. Nossa montagem de ferramentas para convidados é instalada e funciona em uma versão totalmente atualizada do Windows 7 e Windows 10 (com exceção do qvideo).
Ao migrar de um ambiente físico para um virtual, surge o problema da ativação do Windows ao usar versões OEM pré-instaladas. Esses sistemas utilizam ativação baseada em licenças gravadas no UEFI do dispositivo. Para que a ativação funcione corretamente, é necessário transmitir para o sistema convidado uma das seções ACPI do sistema hospedeiro inteiramente (tabela SLIC) e ajustar um pouco as outras, especificando o fabricante. O Xen permite configurar o conteúdo das tabelas ACPI adicionais, mas sem modificar as principais. Uma solução foi encontrada em um patch de um projeto semelhante, o OpenXT, que foi adaptado para o Qubes. As correções se mostraram úteis não apenas para nós e foram transmitidas para o repositório principal do Qubes e para a biblioteca Libvirt.
As desvantagens óbvias das ferramentas de integração do Windows incluem a falta de suporte para áudio, dispositivos USB e a dificuldade em trabalhar com mídia, já que não há suporte de hardware para GPU. No entanto, esses fatores não impedem o uso de VMs para o trabalho com documentos de escritório, nem dificultam a execução de aplicativos corporativos específicos.
A exigência de alternar para um modo de operação offline ou com rede limitada após a criação do modelo de VM do Windows foi atendida pela criação de configurações apropriadas para VMs aplicacionais, e a possibilidade de conexão seletiva de dispositivos removíveis também foi solucionada pelos meios nativos do sistema operacional — ao conectar, eles ficam disponíveis na VM sistema sys-usb, de onde podem ser "encaminhados" para a VM desejada. A área de trabalho do usuário se parece aproximadamente assim.
A versão final do sistema foi recebida positivamente (na medida em que uma solução tão complexa permite) pelos usuários, e os meios nativos do sistema permitiram expandir sua aplicação para o ambiente de trabalho móvel do usuário com acesso via VPN.
Em conclusão
A virtualização em geral permite reduzir os riscos de usar sistemas Windows sem suporte — não força a compatibilidade com novos hardwares, permite excluir ou controlar o acesso ao sistema pela rede ou por dispositivos conectados, e possibilita a implementação de um ambiente para execuções únicas.
O sistema operacional Qubes, baseado na ideia de isolamento através da virtualização, ajuda a utilizar esses e outros mecanismos para garantir a segurança. Por um lado, muitos veem no Qubes, antes de tudo, uma busca por anonimato, mas é um sistema útil tanto para engenheiros que frequentemente combinam projetos, infraestruturas e segredos de acesso, quanto para pesquisadores em segurança. A separação de aplicativos, dados e a formalização de sua interação são os primeiros passos na análise de ameaças e no design do sistema de proteção. Essa separação ajuda a estruturar a informação e reduzir a probabilidade de erro devido ao fator humano — urgência, cansaço, etc.
Atualmente, o foco principal no desenvolvimento está na expansão da funcionalidade dos ambientes Linux. Uma versão 4.1 está prestes a ser lançada, baseada no Fedora 31 e incorporando versões atuais dos componentes-chave Xen e Libvirt. Vale ressaltar que o Qubes é desenvolvido por profissionais de segurança da informação, que sempre lançam atualizações rapidamente em caso de novas ameaças ou erros identificados.
Epílogo
Uma das funcionalidades experimentais que estamos desenvolvendo permite criar VMs com suporte a acesso remoto a GPUs com base na tecnologia Intel GVT-g, o que possibilita utilizar os recursos da placa gráfica e ampliar significativamente as áreas de aplicação do sistema. No momento da escrita deste artigo, essa funcionalidade está operando para as versões de teste do Qubes 4.1 e está disponível em .
Fonte: habr.com
