Windows Server "Longhorn" - Virtualização

Em janeiro de 1992 duas personalidades ilustres do campo da ciência da computação travaram uma histórica discussão pela USENET. De um lado estava o professor Andrew S. Tanembaum, que argumentava as vantagens de um sistema operacional usar uma arquitetura de microkernel. Do outro lado estava Linus Torvalds, que defendia a sua decisão de usar um kernel monolítico para o seu então nascente sistema operacional Linux. De certa forma as posições refletiam  a personalidade e o background de cada um: Tanembaum é um acadêmico e considerava o microkernel o desenho mais elegante e mais "correto", enquanto o pragmático Torvalds como engenheiro de software se preocupava com aspectos mais "mundanos", como facilidade de desenvolvimento e performance.

O tempo se encarregou de mostrar que a decisão de Torvalds estava correta.  Nestes 15 anos o Linux cresceu para se tornar um dos melhores sistemas operacionais do mercado, com o seu principal competidor usando também um kernel monolítico (David Cutler - e o patrão - são também pragmáticos por excelência), enquanto os projetos baseados em microkernel fracassaram.

Isso não quer dizer que vários dos pontos levantados por Tanembaum não fossem válidos. Considerando aqui segurança em especial, um kernel monolítico representa de fato um passo para trás. Ao colocar os drivers de dispositivo e outros componentes dentro do mesmo espaço do kernel, sem definir uma fronteira de segurança entre eles, um kernel monolítico faz com que qualquer vulnerabilidade ou código malicioso dentro do kernel possa comprometer inteiramente o sistema. Na linguagem de segurança da informação, em um kernel monolítico o Trusted Computing Base (TCB) é o kernel inteiro. Já um sistema baseado em microkernel tem um núcleo mínimo, não-extensível e isolado dos demais componentes. Isso quer dizer que o TCB pode ser minimizado e protegido contra por exemplo uma vulnerabilidade em um sistema de arquivos ou um driver malicioso.

A assinatura digital de componentes do kernel, o PatchGuard, a mudança de vários tipos de drivers para fora do kernel, todos esses são passos importantes para reduzir o risco de comprometimento do kernel implementados no Windows Vista, mas de certa forma são apenas paliativos já que não introduzem um verdadeiro isolamento do TCB. Esse isolamento na verdade envolveria acrescentar um custo de performance e a complexidade no desenvolvimento, as mesmas que sepultaram o uso geral dos microkernels na década de 90.

Mas graças a lei de Moore o que era proibitivo em 1992 já não parece ser mais em 2007.  Não seria hora de rever o próprio modelo de arquitetura do kernel? O próprio Tanembaum ressuscitou essa discussão no ano passado em um paper intitulado "Can We Make Operating Systems Reliable and Secure?", onde ele descreve quatro abordagens possíveis de arquiteturas de sistema operacional mais seguras. Elas são apresentadas em ordem de quão radical seria a mudança em relação ao modelo monolítico usado atualmente. A menos radical seria embalar os drivers em um "wrapper" que monitoraria a interação destes componentes com o resto do kernel, algo que lembra o que o PatchGuard faz hoje no Windows Vista. Já as duas mais radicais seriam usar a arquitetura tradicional de microkernel, como faz o MINIX 3; ou implementar modelo onde a própria linguagem de desenvolvimento força o uso de processos não-extensíveis e isolados, como usado pelo sistema operacional Singularity da Microsoft Research.

A abordagem que me parece mais promissora no entanto seria o que Tanembaum chama de "paravirtualização", onde uma máquina virtual executaria os drivers de dispositivo e interrupções, enquanto outras máquinas virtuais rodariam as aplicações em modo usuário. Estas máquinas virtuais rodam em cima de um hypervisor, uma fina camada de software software que faz a gerência das máquinas virtuais e garante o isolamento entre elas. O próprio hypervisor é isolado das máquinas virtuais pela arquitetura do processador, e toda a comunicação é feita com ele usando "hypercalls" bem definidas. O resultado é que, mesmo que máquina virtual tenha sua segurança comprometida, ela não irá conseguiria afetar as demais máquinas virtuais ou o hypervisor.

Modelo de paravirtualização proposto por Tanembaum, usando a implementação L4Linux

Esse modelo não está distante. A mudança mais radical do Windows Server "Longhorn" é que ele traz integrado ao sistema operacional um novo sistema de virtualização, que os nossos criativos marketeiros denominaram Windows Server Virtualization. Ao invés de ter usar um sistema operacional completo como host como faz o Microsoft Virtual PC, o Windows Server Virtualization implementa em sua base um hypervisor mínimo (de 160KB), chamado Viridian. O hypervisor controla o uso dos processadores, mantém as regras de acesso a memória e controla o acesso aos dispositivos - o mesmo papel tradicionalmente reservado a um microkernel.

O hypervisor não é extensível, o que reduz drasticamente o tamanho do TCB, e roda isolado dentro do "ring -1" disponível nos processadores Intel VT e AMD Pacifica. A figura abaixo mostra conceitualmente a arquitetura adotada:

Visão conceitual do Windows Server Virtualization, mostrando o hypervisor e as máquinas virtuais

Uma das máquinas virtuais é especial: ela é chamada de "partição primária", e contém dentro dela o chamado "stack de virtualização". Neste stack estão todas as funções de virtualização que ficam fora do hypervisor, e a sua principal função é gerenciar a memória e a comunicação entre as máquinas virtuais. A partição primária roda sempre o Windows "Longhorn", e é um dos papéis que pode ser implementado no Server Core para reduzir a superfície de ataque e complexidade.

Uma característica do Windows Server Virtualization é a de que os drivers normais de dispositivos são instalados somente nesta partição primária. Nas outras máquinas virtuais ficam apenas os chamados Virtual Server Clients (VSCs), que fazem o papel de um driver para uma determinada classe de dispositivos, e que falam com os drivers reais através de um bus de comunicação (VMBus) gerenciado pelo hypervisor. Os dispositivos são assim abstraídos e um driver problemático não poderá corromper uma máquina virtual, já que não está rodando nela. Um ponto interessante é que máquinas virtuais Linux com a tecnologia Xen podem usar a mesma arquitetura de VSCs e rodar normalmente sobre o hypervisor do Windows Server Virtualization.

O Windows Server Virtualization suporta máquinas virtuais de 64-bits, máquinas virtuais multiprocessadas, adição online de processadores e memória, migração automática de máquinas virtuais, clusterização, alta performance etc. etc. (um vídeo de demonstração está disponível aqui para os interessados). Mas como o nosso foco é segurança, vamos nos concentrar aqui em quais seriam os impactos positivos em termos de segurança. E eles são vários:

¦ Usando virtualização um mesmo servidor físico pode ser compartilhado por várias aplicações (por exemplo servidor de arquivos, banco de dados e correio eletrônico), cada uma colocada em sua própria máquina virtual. Isso não só torna mais fácil delegar a administração destas aplicações, mas também minimiza a superfície de ataque e o impacto no caso de uma aplicação ser comprometida. Nesse caso apenas uma aplicação seria afetada, estando as outras protegidas pelo isolamento entre as máquinas virtuais.

¦ Devido ao hypervisor rodar isolado das máquinas virtuais no "ring -1", é bastante improvável que ele seja comprometido em um evental incidente com uma máquina virtual. Assim, se antes o procedimento em caso de um incidente de segurança era reformatar a máquina e instalar o sistema de novo do zero, com o Windows Server Virtualization pode bastar a você remover a máquina virtual e pedir para o hypervidor instanciar uma nova.  

¦ Ainda na resposta a incidentes, uma máquina virtual comprometida pode ser também facilmente parada e submetida a uma análise forense online, sem necessidade do uso de hardware especial. Da mesma forma pode ser detectado malware (como rootkits) rodando dentro do kernel, mesmo que eles não sejam persistentes e somente estejam armazenados em memória.

¦ Ataques que tentem comprometer partes do hardware como a BIOS e placas PCI seriam bloqueadas pela própria arquitetura de virtualização, e em tese só poderiam ser lançados a partir da partição primária. Da mesma forma seriam bloquados ataques que tentam criar o seu próprio hypervisor, como o "blue pill".

Isso é só o começo. Com uma arquitetura usando um chip TPM, é possível que no futuro se possa garantir que o hypervisor somente irá iniciar se o hardware e todo os componentes de pré-boot estejam íntegros, protegendo o sistema e todas as máquinas virtuais de ataques offline. É possível visualizar no futuro um anti-malware rodando dentro do hypervisor, fiscalizando as máquinas virtuais e detectando comportamentos considerados maliciosos. Ao introduzir uma arquitetura similar a um microkernel e reduzir o TCB, a virtualização pode mudar totalmente os nossos paradigmas de ataques e defesas.

Mesmo fazendo parte do Windows "Longhorn", o Windows Server Virtualization deve ser lançado um pouco depois do restante do sistema operacional. Ainda não existe uma versão pública disponível para testes, mas uma deve ser lançada muito em breve.

Comments

• Anonymous
  January 01, 2003
  Joanna Rutkowska fez esta semana a sua apresentação na Black Hat 2007 , onde apresentou a nova versão

• Anonymous
  January 01, 2003
  O principal problema da assinatura digital do código do kernel não são ferramentas como o Atsiv , que

• Anonymous
  January 01, 2003
  Boa pergunta Gustavo. A gerência da virtualização é feita pela partição primária, e alguém com controle dessa partição poderia certamente parar e remover as outras máquinas virtuais. Por isso a recomendação da Microsoft é a de instalar a partição primária sempre que possível como Server Core, e não rodar nela qualquer outro serviço de forma a reduzir a superfície de ataque. Não é dificil imaginar também que em ambientes mais seguros a partição primária vai estar ligada somente na rede de gerenciamento, sem estar exposta a ataques vindos da rede corporativa.

• Anonymous
  January 01, 2003
  Obrigado Pedro. O modelo de licenciamento do Longhorn ainda não está definido, mas tomando como exemplo Windows 2003 uma licença da versão Enterprise inclui também o uso do sistema operacional em até 4 quatro instâncias de máquina virtual. Já para o SQL Server a licença inclui você ter ele rodando em quantas máquinas virtuais você quiser naquele servidor. Uma coisa interessante também do licenciamento da Microsoft é que você só paga licenças por máquinas virtuais ativas, ou seja, que estejam rodando simultaneamente. Máquina virtual parada não precisa de licença.

• Anonymous
  April 10, 2007
  Cima. Caso um driver comprometa a partição primária, este não traria riscos às outras VMs, já que a partição primária é responsável por gerenciar a memória delas? A propósito, parabéns (mais uma vez) pelo excelente artigo. Vai dar gosto de ver essa "tranqueira" toda funcionando. Abraço.

• Anonymous
  April 10, 2007
  Muito bom Cima, parabéns! Gostei de ver... aprendi sobre isso no semestre passado, gostei, e é bom ler o que há de novo acontecendo no mundo na área de SOs e Segurança. []s, Vinicius

• Anonymous
  April 10, 2007
  The comment has been removed

• Anonymous
  April 11, 2007
  Cima, O artigo está fantástico. Parabéns! Os "criativos marketeiros" da Microsoft terão trabalho em divulgar as novas funções do Windows tão bem como você fez nesta série de artigos. Quanto ao segregamento de papéis específicos (servidor de arquivos, banco de dados, etc) teremos algum auxílio da turma de licensiamento para ajudar na segurança?

• Anonymous
  May 07, 2007
  The comment has been removed