Não há muitos artigos sobre Habré dedicados ao sistema operacional Qubes, e aqueles que vi não descrevem muito da experiência de usá-lo. Abaixo do corte, espero corrigir isso usando o exemplo do uso do Qubes como meio de proteção (contra) o ambiente Windows e, ao mesmo tempo, estimar o número de usuários do sistema que falam russo.
Por que Qubes?
A história do fim do suporte técnico ao Windows 7 e a crescente ansiedade dos utilizadores levaram à necessidade de organizar o trabalho deste SO, tendo em conta os seguintes requisitos:
- garantir a utilização do Windows 7 totalmente ativado com possibilidade de o usuário instalar atualizações e diversos aplicativos (inclusive via Internet);
- implementar exclusão completa ou seletiva de interações de rede com base em condições (operação autônoma e modos de filtragem de tráfego);
- fornecem a capacidade de conectar seletivamente mídias e dispositivos removíveis.
Este conjunto de restrições pressupõe um usuário claramente preparado, uma vez que é permitida a administração independente, e as restrições não estão relacionadas ao bloqueio de suas possíveis ações, mas à exclusão de possíveis erros ou efeitos destrutivos do software. Aqueles. Não há infrator interno no modelo.
Em nossa busca por uma solução, abandonamos rapidamente a ideia de implementar restrições usando ferramentas integradas ou adicionais do Windows, uma vez que é bastante difícil restringir efetivamente um usuário com direitos de administrador, deixando-o com a capacidade de instalar aplicativos.
A próxima solução foi o isolamento usando virtualização. Ferramentas conhecidas para virtualização de desktops (por exemplo, como o virtualbox) são pouco adequadas para resolver problemas de segurança e as restrições listadas terão que ser feitas pelo usuário alternando ou ajustando constantemente as propriedades da máquina virtual convidada (doravante denominada como VM), o que aumenta o risco de erros.
Ao mesmo tempo, tínhamos experiência no uso do Qubes como sistema de desktop do usuário, mas tínhamos dúvidas sobre a estabilidade de trabalhar com Windows convidado. Optou-se por verificar a versão atual do Qubes, uma vez que as limitações indicadas enquadram-se muito bem no paradigma deste sistema, nomeadamente a implementação de templates de máquinas virtuais e integração visual. A seguir, tentarei falar brevemente sobre as ideias e ferramentas do Qubes, usando o exemplo de solução do problema.
Tipos de virtualização Xen
Qubes é baseado no hipervisor Xen, que minimiza as funções de gerenciamento de recursos do processador, memória e máquinas virtuais. Todo o resto do trabalho com dispositivos está concentrado no dom0 baseado no kernel Linux (Qubes para dom0 usa a distribuição Fedora).
O Xen suporta vários tipos de virtualização (darei exemplos para arquitetura Intel, embora o Xen suporte outros):
- paravirtualização (PV) - um modo de virtualização sem uso de suporte de hardware, que lembra a virtualização de containers, pode ser utilizado para sistemas com kernel adaptado (dom0 opera neste modo);
- virtualização completa (HVM) - neste modo, o suporte de hardware é usado para recursos do processador e todos os outros equipamentos são emulados usando QEMU. Esta é a forma mais universal de executar vários sistemas operacionais;
- paravirtualização de hardware (PVH - ParaVirtualized Hardware) - modo de virtualização que utiliza suporte de hardware quando, para trabalhar com hardware, o kernel do sistema convidado utiliza drivers adaptados às capacidades do hipervisor (por exemplo, memória compartilhada), eliminando a necessidade de emulação QEMU e aumentando o desempenho de E/S. O kernel Linux a partir de 4.11 pode funcionar neste modo.
A partir do Qubes 4.0, por questões de segurança, o uso do modo de paravirtualização é abandonado (inclusive devido a vulnerabilidades conhecidas na arquitetura Intel, que são parcialmente mitigadas pelo uso da virtualização completa); o modo PVH é usado por padrão.
Ao usar a emulação (modo HVM), o QEMU é iniciado em uma VM isolada chamada stubdomain, reduzindo assim os riscos de exploração de possíveis erros na implementação (o projeto QEMU contém muito código, inclusive para compatibilidade).
No nosso caso, este modo deve ser usado para Windows.
Máquinas virtuais de serviço
Na arquitetura de segurança Qubes, um dos principais recursos do hipervisor é a transferência 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; no segundo caso, requer suporte para IOMMU (Intel VT-d) - gerenciamento de memória de hardware para dispositivos virtualizados.
Isso cria várias máquinas virtuais de sistema:
- sys-net, para o qual são transferidos dispositivos de rede e que serve de ponte para outras VMs, por exemplo, aquelas que implementam funções de firewall ou cliente VPN;
- sys-usb, para o qual são transferidos controladores USB e outros dispositivos periféricos;
- sys-firewall, que não utiliza dispositivos, mas funciona como firewall para VMs conectadas.
Para trabalhar com dispositivos USB, são utilizados serviços de proxy, que fornecem, entre outras coisas:
- para a classe de dispositivo HID (dispositivo de interface humana), enviando comandos para dom0;
- para mídia removível, redirecionamento de volumes de dispositivos para outras VMs (exceto dom0);
- redirecionando diretamente para um dispositivo USB (usando USBIP e ferramentas de integração).
Nessa configuração, um ataque bem-sucedido através da pilha de rede ou de dispositivos conectados pode levar ao comprometimento apenas da VM de serviço em execução, e não de todo o sistema como um todo. E após reiniciar a 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 de uma máquina virtual - instalando aplicativos no sistema convidado ou emulando vídeo usando ferramentas de virtualização. Os aplicativos convidados podem ser várias ferramentas universais de acesso remoto (RDP, VNC, Spice, etc.) ou adaptados a um hipervisor específico (essas ferramentas são geralmente chamadas de utilitários convidados). Uma opção mista também pode ser usada, quando o hipervisor emula E/S para o sistema convidado e fornece externamente a capacidade de usar um protocolo que combina E/S, por exemplo, como o Spice. Ao mesmo tempo, as ferramentas de acesso remoto costumam otimizar a imagem, pois envolvem o trabalho em rede, o que não afeta positivamente a qualidade da imagem.
Qubes fornece suas próprias ferramentas para integração de VM. Em primeiro lugar, este é um subsistema gráfico - as janelas de diferentes VMs são exibidas em uma única área de trabalho com seu próprio quadro colorido. Em geral, as ferramentas de integração são baseadas nos recursos do hipervisor - memória compartilhada (tabela de concessão Xen), ferramentas de notificação (canal de eventos Xen), armazenamento compartilhado xenstore e protocolo de comunicação vchan. Com a ajuda deles, são implementados os componentes básicos qrexec e qubes-rpc e serviços de aplicativos - redirecionamento de áudio ou USB, transferência de arquivos ou conteúdo da área de transferência, execução de comandos e inicialização de aplicativos. É possível definir políticas que permitem limitar os serviços disponíveis em uma VM. A figura abaixo é um exemplo do procedimento de inicialização da interação de duas VMs.
Assim, o trabalho na VM é realizado sem utilização de rede, o que permite o aproveitamento total das VMs autônomas para evitar vazamento de informações. Por exemplo, é assim que a separação de operações criptográficas (PGP/SSH) é implementada, quando chaves privadas são utilizadas em VMs isoladas e não vão além delas.
Modelos, aplicativos e VMs únicas
Todo o trabalho do usuário no Qubes é feito em máquinas virtuais. O sistema host principal é usado para controlá-los e visualizá-los. O sistema operacional é instalado junto com um conjunto básico de máquinas virtuais baseadas em modelos (TemplateVM). Este modelo é uma VM Linux baseada na distribuição Fedora ou Debian, com ferramentas de integração instaladas e configuradas e sistema dedicado e partições de usuário. A instalação e atualização do software são realizadas por um 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 de tais VMs é garantir a confiança nas VMs de aplicativos lançadas com base nelas.
Na inicialização, uma VM de aplicativo (AppVM) usa um instantâneo da partição do sistema do modelo de VM correspondente e, após a conclusão, exclui esse instantâneo sem salvar as alterações. Os dados exigidos pelo usuário são armazenados em uma partição de usuário exclusiva para cada VM do aplicativo, que é montada no diretório inicial.
Usar VMs descartáveis (disposableVM) pode ser útil do ponto de vista da segurança. Essa VM é criada com base em um modelo no momento da inicialização e é iniciada com uma finalidade - executar um aplicativo, concluindo o trabalho após seu fechamento. VMs descartáveis podem ser usadas para abrir arquivos suspeitos cujo conteúdo pode levar à exploração de vulnerabilidades específicas de aplicativos. A capacidade de executar uma VM única está integrada ao gerenciador de arquivos (Nautilus) e ao cliente de e-mail (Thunderbird).
A VM do Windows também pode ser usada para criar um modelo e uma VM única, movendo o perfil do usuário para uma seção separada. Em nossa versão, tal modelo será utilizado pelo usuário para tarefas de administração e instalação de aplicativos. Com base no modelo, várias VMs de aplicativos serão criadas - com acesso limitado à rede (capacidades padrão de firewall de sistema) e sem acesso à rede (um dispositivo de rede virtual não é criado). Todas as alterações e aplicativos instalados no modelo estarão disponíveis para funcionar nessas VMs e, mesmo que programas de marcadores sejam introduzidos, eles não terão acesso à rede para comprometimento.
Lute pelo Windows
Os recursos descritos acima são a base do Qubes e funcionam de forma bastante estável; as dificuldades começam com o Windows. Para integrar o Windows, você deve usar um conjunto de ferramentas convidadas Qubes Windows Tools (QWT), que inclui drivers para trabalhar com Xen, um driver qvideo e um conjunto de utilitários para troca de informações (transferência de arquivos, área de transferência). O processo de instalação e configuração está documentado detalhadamente no site do projeto, por isso compartilharemos nossa experiência de aplicação.
A principal dificuldade é essencialmente a falta de suporte às ferramentas desenvolvidas. Os principais desenvolvedores (QWT) parecem não estar disponíveis e o projeto de integração do Windows está aguardando um desenvolvedor líder. Portanto, antes de mais nada, foi necessário avaliar o seu desempenho e compreender a possibilidade de apoiá-lo de forma independente, se necessário. O mais difícil de desenvolver e depurar é o driver gráfico, que emula o adaptador de vídeo e o monitor para gerar uma imagem na memória compartilhada, permitindo exibir toda a área de trabalho ou a janela do aplicativo diretamente na janela do sistema host. Durante a análise do funcionamento do driver, adaptamos o código para montagem em ambiente Linux e elaboramos um esquema de depuração entre dois sistemas convidados Windows. Na fase de crossbuild, fizemos várias alterações que simplificaram as coisas para nós, principalmente em termos de instalação “silenciosa” de utilitários, e também eliminaram a irritante degradação de desempenho ao trabalhar em uma VM por muito tempo. Apresentamos os resultados do trabalho em separado , portanto, não por muito tempo Desenvolvedor líder do Qubes.
A etapa mais crítica em termos de estabilidade do sistema convidado é a inicialização do Windows, aqui você pode ver a familiar tela azul (ou nem mesmo vê-la). Para a maioria dos erros identificados, houve várias soluções alternativas – eliminação de drivers de dispositivo de bloco Xen, desativação do balanceamento de memória VM, correção de configurações de rede e minimização do número de núcleos. Nossas ferramentas convidadas são instaladas e executadas em Windows 7 e Windows 10 totalmente atualizados (exceto qvideo).
Ao passar de um ambiente real para um virtual, surge um problema com a ativação do Windows se forem usadas versões OEM pré-instaladas. Esses sistemas usam ativação com base em licenças especificadas na UEFI do dispositivo. Para processar corretamente a ativação, é necessário traduzir uma de todas as seções ACPI do sistema host (tabela SLIC) para o sistema convidado e editar levemente as demais, registrando o fabricante. O Xen permite personalizar o conteúdo ACPI de tabelas adicionais, mas sem modificar as principais. Um patch de um projeto OpenXT semelhante, adaptado para Qubes, ajudou na solução. As correções pareceram úteis não apenas para nós e foram traduzidas 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 complexidade de trabalhar com mídia, já que não há suporte de hardware para GPU. Mas o acima exposto não impede a utilização da VM para trabalhar com documentos de escritório, nem impede o lançamento de aplicações corporativas específicas.
O requisito de alternar para o modo operacional sem rede ou com rede limitada após a criação de um modelo de VM do Windows foi atendido criando as configurações apropriadas de VMs de aplicativos, e a possibilidade de conectar seletivamente mídia removível também foi resolvida por ferramentas padrão do sistema operacional - quando conectado , eles estão disponíveis na VM do sistema sys-usb, de onde podem ser "encaminhados" para a VM necessária. A área de trabalho do usuário se parece com isto.
A versão final do sistema foi positivamente (até onde uma solução tão abrangente permite) aceita pelos usuários, e as ferramentas padrão do sistema possibilitaram expandir a aplicação para a estação de trabalho móvel do usuário com acesso via VPN.
Em vez de uma conclusão
A virtualização em geral permite reduzir os riscos de usar sistemas Windows sem suporte - não força a compatibilidade com novo hardware, permite excluir ou controlar o acesso ao sistema pela rede ou através de dispositivos conectados, e permite que você implementar um ambiente de lançamento único.
Baseado na ideia de isolamento por meio da virtualização, o Qubes OS ajuda você a aproveitar esses e outros mecanismos de segurança. Do lado de fora, muitas pessoas veem o Qubes principalmente como um desejo de anonimato, mas é um sistema útil tanto para engenheiros, que muitas vezes fazem malabarismos com projetos, infraestruturas e segredos para acessá-los, quanto para pesquisadores de segurança. A separação de aplicações, dados e a formalização de sua interação são as etapas iniciais da análise de ameaças e do projeto de sistemas de segurança. Essa separação ajuda a estruturar as informações e reduzir a probabilidade de erros devido ao fator humano – pressa, cansaço, etc.
Atualmente, a principal ênfase no desenvolvimento está na expansão da funcionalidade dos ambientes Linux. A versão 4.1 está sendo preparada para lançamento, que será baseada no Fedora 31 e incluirá versões atuais dos principais componentes Xen e Libvirt. Vale ressaltar que o Qubes é criado por profissionais de segurança da informação que sempre lançam atualizações prontamente caso novas ameaças ou erros sejam identificados.
Posfácio
Uma das capacidades experimentais que estamos desenvolvendo nos permite criar VMs com suporte para acesso de convidados à GPU baseada na tecnologia Intel GVT-g, o que nos permite aproveitar os recursos do adaptador gráfico e expandir significativamente o escopo do sistema. No momento em que este artigo foi escrito, essa funcionalidade funcionava para versões de teste do Qubes 4.1 e estava disponível em .
Fonte: habr.com