Particionando minha vida digital em domínios de segurança
por Joanna Rutkowska
Tradução: Disruptura
Qubes OS & Invisible Things Lab
O diagrama abaixo ilustra como eu decompus minha vida digital em domínios de segurança. Este é um esquema bastante sofisticado e a maioria dos usuários provavelmente irá querer algo mais simples, mas eu ainda acho que é interessante para discuti-lo. Os domínios são implementados como ligeiros AppVMs no Qubes OS. O diagrama também mostra para qual tipo de conectividade de rede cada domínio é permitido.
Vamos discutir este diagrama passo a passo. Os três domínios básicos são o trabalho (verde), pessoal (amarelo) e vermelho (para fazer todas as coisas não confiáveis, insensíveis) – estes são marcados no diagrama com quadros em negrito.
Uma rápida explicação sobre rótulos de domínio (cores) – No Qubes OS a cada domínio, além de um nome distinto, também é atribuído um rótulo que é basicamente uma das várias cores. Essas cores, que são usadas para desenhar decorações de janelas pelo gerenciador de janelas confiável (quadros de cores), são supostamente fáceis de usar, facilmente visíveis, indicando o quanto uma determinada janela é confiável.
A interpretação dessas cores fica por conta de quem usa. Para mim, de alguma forma é óbvio associar a cor vermelha a algo que não é confiável e perigoso (a “luz vermelha” – pare! Perigo!), Verde com algo que é seguro e confiável, enquanto amarelo e laranja com algo entre ambos. Eu também estendi este esquema, para incluir azul e preto, que eu interpreto como indicando progressivamente domínios mais confiáveis do que verde, com preto sendo algo de alta confiabilidade.
De volta aos meus domínios: o domínio trabalho (“work”) é onde tenho acesso ao meu e-mail de trabalho, onde mantenho minhas chaves de PGP de trabalho, onde preparo relatórios, slides, artigos, etc. Também mantenho aqui vários contratos e NDAs (sim, são PDFs, mas recebidos de partes confiáveis via e-mail criptografado e assinado – caso contrário, abro em máquinas virtuais descartáveis). O domínio trabalho tem apenas acesso de rede ao meu servidor de e-mail de trabalho (SMTP / IMAP4 sobre SSL) e nada mais.
Para outras tarefas relacionadas ao trabalho que requerem algum acesso à Web, como a edição do Qubes Wiki, aceitação de convites no LinkedIn, download de fotos legais do fotolia.com para minhas apresentações, especificações e manuais da intel.com, eu uso o domínio workpub, que eu atribuí o rótulo amarelo, ou seja, eu considero ele um pouco menos confiável, e eu certamente nunca colocarei as minhas chaves PGP lá, ou qualquer trabalho relacionado a informações confidenciais.
O domínio pessoal (“personal”) é onde todas minhas coisas não relacionados com o trabalho são realizadas (e-mail pessoal e calendário, fotos de férias, vídeos, etc). Não tem acesso à Web, mas se eu estivesse em redes sociais, eu provavelmente permitiria HTTPS para algo como o Facebook.
Sendo de alguma forma uma coisa paranoica, eu também tenho um domínio especial muito pessoal (“very personal”), que eu uso para a comunicação com o meu companheiro quando estou longe de casa. Nós usamos o PGP, é claro, e eu tenho chaves PGP separadas para esta finalidade. Embora não discutamos nenhum assunto secreto e sensível lá, nós ainda preferimos manter nossas conversas íntimas privadas.
Eu uso compras (“shopping”) para acessar todos os sites de comércio eletrônico na Internet. Basicamente, o que define este domínio é o acesso aos números do meu cartão de crédito e ao meu endereço pessoal (para envio). Porque eu realmente não tenho um cartão de crédito corporativo dedicado, eu faço todas as compras neste domínio, de alimentos, passando por equipamentos esportivos e reservas de hotel / avião terminando. Se eu tivesse cartões de crédito de negócios separados, então provavelmente dividiria meu domínio compras em “compras pessoais” e “compras de trabalho”. Eu também tenho domínio banco (“banking”), que eu uso apenas para gerir a minha conta bancária (que combina novamente as minhas contas pessoais e de empresa).
Tenho também alguns domínios especializados relacionados ao trabalho, que eu raramente uso. O domínio trabalho-admin (“work-admin”) é usado para gerenciar quase todos os servidores ITL, como nosso servidor web, repositórios Qubes e servidores wiki, servidor de e-mail e gerenciamento de DNS, etc. Este domínio é permitido apenas o tráfego SSH para esses servidores, e HTTPS para alguns servidores de gerenciamento baseados na Web. O trabalho-blog (“work-blog”) é usado para gerenciar este blog que você está lendo agora. A razão pela qual é separado do trabalho-admin ou trabalho, é porque eu sou super paranoica, e porque eu temo que se alguém invade o serviço blogger, e posteriormente explora um bug no meu navegador que eu uso para editar o meu blog, pode ser capaz de também obter acesso de administrador para todos os servidores ITL.
Da mesma forma, se alguém de alguma forma comprometa, por exemplo o Console de Gerenciamento da AWS, e, em seguida, explore o meu navegador no trabalho-admin, então eu gostaria de, pelo menos, manter o acesso ao meu blog. Se eu usasse twitter, eu provavelmente também iria gerenciá-lo a partir deste domínio do trabalho-blog, a menos que fosse uma conta pessoal do twitter, caso em que eu iria executá-lo do pessoal.
O domínio qubes-dev é usado para todo o desenvolvimento Qubes, mesclando branch de outros desenvolvedores (depois que eu verificar assinaturas em suas tags, é claro!), Construindo RPMs / ISOs (sim, Qubes Beta 1 será enviado como um DVD ISO!), e finalmente validá-los. Como as chaves de assinatura estão lá, este domínio é muito sensível. Este domínio é permitido apenas acesso de rede SSH ao nosso servidor Qubes git. Novamente, mesmo se alguém invadiu este servidor Git, ainda não seria um grande problema para nós, porque nós assinamos e verificamos todas as tags nos outros repos (a menos que alguém pudesse também modificar o SSH / Git daemons rodando lá para que eles posteriormente explorasse um bug hipotético no meu software de cliente git quando eu me conectasse ao servidor).
Eu também decidi manter todas as coisas relacionadas à contabilidade em um domínio separado – sempre que eu recebo uma fatura eu copio para o domínio contabilidade (“accounting”). A razão para isso é que eu não confio nesses PDFs como confio nos que eu mantenho no domínio trabalho.
Uma vez por ano, movo o material antigo do meu domínio trabalho para o domínio arquivos de trabalho (velhos conteúdos de e-mail, contratos antigos e NDAs). Isso é para minimizar o impacto potencial em caso de ataque no meu domínio trabalho (ele pode ser atacado, por exemplo, explorando um bug hipotético no handshake do protocolo do Thunderbird usando um ataque MITM ou um possível bug no GPG).
O domínio cofre (“vault”) é um altamente confiável, onde eu gero e mantenho todas as minhas senhas (usando keepass) e mestre GPG chaves. Naturalmente, este domínio cofre não tem acesso à rede. A maioria dessas senhas, como a senha de acesso ao servidor de e-mail, também é mantida nos domínios específicos que os usam, como o domínio trabalho e mais especificamente no cliente Thunderbird (não há absolutamente nenhum ponto em não permitir que o Thunderbird se lembre do Senha – se ele foi invadido seria apenas roubá-lo da próxima vez que eu entro com ela manualmente)
E finalmente, há o domínio vermelho (eu tentei chamá-lo de lixo ou aleatório no passado , mas acho que vermelho ainda é um nome melhor). O domínio vermelho é totalmente não confiável – se ele for invadido, eu não me importo – é só recriá-lo em segundos. Nem sequer faço backup! Eu deixo lá tudo o que não se encaixa em outros domínios, e que não me obriga a fornecer qualquer informação importante. Eu não diferencio navegações entre os relacionados a trabalho e pessoal com o surf mesmo – eu não me importo com anonimato para todas as tarefas que eu faço lá. Se eu estivesse preocupada com o anonimato, eu criaria um domínio anônimo separado, e filtraria o tráfego através de um proxy tor.
Isso tudo parece agradável e fácil, mas há uma coisa que complica a imagem acima …
Fluxos de dados entre os domínios
O diagrama abaixo mostra os mesmos domínios, mas adicionalmente com setas que simbolizam fluxos de dados típicos entre eles.
Você pode ver que a maioria dos fluxos de dados habituais são de domínios mais confiáveis para domínios menos confiáveis - por exemplo, copiar e colar um URL que recebo por e-mail no meu domínio trabalho, para que eu possa abri-lo no navegador não confiável em vermelho ou Movendo faturas do meu domínio trabalho (onde eu os recebo por e-mail) para o domínio contabilidade.
Mas há, infelizmente, também algumas transferências de domínios menos confiáveis para os mais confiáveis. Um exemplo é copiar e colar um URL interessante que eu acabei de me deparar ao navegar no domínio vermelho e que eu gostaria de compartilhar com alguém do trabalho ou um amigo. Assim eu preciso copiar e colá-lo para o meu e-mail no domínio trabalho ou pessoal.
Agora, copiar dados de domínios menos confiáveis para os mais confiáveis apresenta um problema significativo. Embora se possa pensar que colar um URL no editor de e-mail do Thunderbird é uma operação bastante inofensiva, ainda é uma entrada não confiável – e nós realmente não sabemos o que o domínio vermelho realmente colou em sua área de transferência local e o que vamos colar no editor de e-mail no domínio trabalho. E ainda mais assustador é o exemplo de copiar o arquivo gráfico descolado da Web para o meu domínio trabalho para que eu possa usá-lo nos slides de apresentação (por exemplo, ataques do xkcd a partir de um JPEG ou outro formato malicioso, explorando bugs no código de renderização, são conhecidos há mais de uma década).
Mas este problema – como lidar com fluxos de dados de sistemas menos confiáveis para os mais confiáveis - não é facilmente resolvível na prática, infelizmente….
Algumas pessoas que projetam e constroem sistemas de alta segurança para uso militar e governamental tomam uma abordagem um pouco oposta – eles dizem que não estão preocupados com transferências de dados menos confiáveis para mais confiáveis, desde que possam garantir que não haja nenhuma maneira para realizar uma transferência na direção oposta.
Assim, eles estariam satisfeitos caso pudéssemos construir um sistema que garantisse que um domínio mais confiável nunca transferiria dados para um domínio menos confiável (mesmo se ambos os domínios estejam comprometidos!) em “transferências” unidirecionais. Na prática, isso significa que precisamos eliminar todos os canais encobertos entre dois domínios cooperantes. A palavra cooperar é uma palavra-chave aqui, e que faz com que toda essa ideia não seja prática, na minha humilde opinião.
A eliminação dos canais encobertos entre domínios cooperantes é certamente necessária neste esquema, porque a suposição é que a transferência de dados a partir do domínio menos confiável poderia ter efetivamente comprometido o domínio mais confiável. Mas isso não deve resultar em qualquer vazamento de dados de volta para o domínio origem e, consequentemente, para a rede menos segura, que o domínio menos confiável é presumivelmente conectado. Uma das hipóteses aqui é que o usuário de tal sistema está conectado a mais de uma rede isolada. Mesmo nesse caso, a eliminação de todos os canais encobertos entre domínios (ou, pelo menos, minimizando sua banda para algo inutilizável – o que é inutilizável, de fato?) é um grande desafio e provavelmente só poderia ser feito quando estivermos prontos para sacrificar significativamente o desempenho do sistema (truques inteligentes de programação são necessários para minimizar os canais secretos temporais).
Gostaria de deixar claro que não interessa eliminar os canais secretos cooperativos entre os domínios no Qubes em qualquer momento num futuro próximo, e talvez a longo prazo também. Eu simplesmente não acredito em tal abordagem , e eu também não gosto que essa abordagem não faça nada para preservar a integridade do domínio mais confiável – ele só se concentra no aspecto do isolamento. Assim, talvez o ataque não consiga vazar os segredos de volta para o domínio menos confiável, mas pode fazer tudo o mais neste domínio mais confiável. Quão bom é o isolamento, se não mantivermos a integridade?
Uma solução alternativa para manipular as transferências de dados menos confiáveis para mais confiáveis é ter “conversores” confiáveis ou “verificadores” capazes de lidar com tipos de arquivos específicos, como JPEGs, e garantir que obtenhamos um arquivo não malicioso no domínio destino. Embora isso possa lembrar a velha tecnologia de antivírus, nesse caso é algo diferente. Aqui, os conversores confiáveis provavelmente seriam programas escritos em uma linguagem segura, rodando em outro domínio confiável, em vez de um A/V horrível com um enorme banco de dados de assinaturas de padrões “ruins” do que pode aparecer em um arquivo JPEG. O problema óbvio com tal abordagem é que alguém precisa escrever esses conversores e escrevê-los para todos os tipos de arquivo que desejamos permitir a transferência para os domínios mais confiáveis. Talvez possível a longo prazo, e talvez possamos fazê-lo em alguma versão futura do Qubes….
Neste momento, estamos ignorando esse problema e dizemos que todas as transferências menos confiáveis para mais confiáveis devem ser feitas pelo próprio risco do usuário 🙂 Enquanto isso você está convidado a enviar conversores confiáveis para seu(s) tipo(s) de arquivo favorito(s).
Copiando arquivos entre domínios
Falando em copiar arquivos entre domínios, há outro truque de segurança aqui. Se imaginássemos duas máquinas separadas fisicamente que não compartilhassem recursos de rede comuns, a única maneira de mover arquivos entre essas duas máquinas seria através de algo como uma unidade USB ou um CD-ROM ou DVD. Mas inserir uma unidade USB ou CD-ROM em uma máquina dispara um monte de ações: de analisar informações fornecidas pelo dispositivo, carregar drivers necessários (para USB), analisar a tabela de partição do driver, montar e finalmente analisar o sistema de arquivos. Cada uma dessas etapas exige que o sistema operacional da máquina execute um monte de processamento de entrada não confiável, e o espaço para ataque potencial aqui é bem grande. Assim, mesmo se pudéssemos limitar-nos a copiar apenas arquivos inofensivos entre máquinas/domínios (talvez eles fossem de alguma forma verificados por um grupo de confiança entre eles, como discutido acima), ainda há uma enorme chance de que o domínio origem comprometa o domínio destino.
Em Qubes Alfa temos utilizado um mecanismo de cópia de arquivos similar, utilizando um controle virtual para cópia de ficheiros entre domínios. No Qubes Beta 1 vamos fornecer um novo esquema baseado no mesmo canal de memória compartilhada que usamos para virtualização GUI – os detalhes técnicos estarão disponíveis em breve em nosso wiki. O elemento mais sensível neste novo esquema é o utilitário similar ao un-cpio que é executado no domínio destino e descompacta o blob de entrada na árvore de diretórios pré-definida (por exemplo, /home/user/entrant/from-{domainname}/). Acreditamos que possamos escrever uma utilidade bastante segura como un-cpio, em contraste com a segurança de todos os elementos mencionados anteriormente (análise de dispositivos USB, análise de partições, análise de fs). O Qubes Beta 1 está planejado para ser lançado no final de março (N.T. Lançado em Março de 2011).
Particionando a aplicação e facilidade de uso
Para que qualquer esquema de particionamento de segurança faça sentido na vida real, é necessário ter algum mecanismo de execução que assegure que o usuário não o ignore por engano. Especificamente para esta finalidade nós traremos suporte de firewall no Qubes Beta 1, que eu vou cobrir em um artigo separado em breve.
Outra coisa é fazer que o particionamento seja fácil de usar. Por exemplo, eu gostaria de ser capaz de configurar uma dica na política que, quando clico em um URL em um e-mail que recebi no meu domínio trabalho, ele abrisse automaticamente no navegador padrão do domínio vermelho. Atualmente não fazemos isso em Qubes, mas estamos pensando em fazê-lo em um futuro próximo.
Resumo
Participar da vida digital em domínios de segurança não é certamente um processo fácil e requer algum tempo pensando. Esse processo também é muito usuário específico. O esquema de particionamento que eu criei para mim é bastante sofisticado, e a maioria das pessoas provavelmente pode querer algo muito mais simples. Em caso de implantações corporativas, o esquema seria projetado por administradores de TI ou CIO, e aplicados automaticamente aos usuários. Problema muito maior são os usuários domésticos e de pequenas empresas, que precisariam criar o próprio particionamento. Talvez em futuras versões do Qubes forneceremos alguns modelos prontos para usar selecionando grupos de usuários “típicos”.
[1] Texto foi traduzido do inglês e contribuições com eventuais erros e melhoria da tradução são bem-vindas!
Links úteis
Como usar o Whonix no Qubes OS – Sistema operacional para navegação anônima, baseado no Debian e Tor