O universo Linux mudou para sempre. Sua tecnologia deixou de ser “algo estranho” nas conversas de informática e hoje está presente em milhões de smartphones, tablets, modems, roteadores, dispositivos vestíveis e veículos, sem esquecer seu domínio no espaço de servidores. Com a chamada Internet das Coisas batendo à porta, a segurança do kernel Linux não pode continuar com seu modelo atual, e várias vozes recomendam a implementação de uma nova estratégia que permita ao kernel “proteger a si mesmo”, ficando um passo à frente das vulnerabilidades.
A dois metros da minha mesa acumula poeira um smartphone com Android 2.3 que hoje cumpre a função de lanterna. Embora tudo que eu precise fazer para que ele volte ao seu papel original de smartphone seja colocar um chip, a versão do sistema operacional é tão antiga que não sei se vale a pena correr o risco. Nessa mesma situação estão milhões de dispositivos com um kernel Linux em segundo plano. Eles são robustos, flexíveis e estáveis, mas, ao não receberem atualizações, tornam-se inseguros. Desenvolvedores, fabricantes, distribuidores, provedores de conectividade e usuários, todos carregam um pouco de culpa sobre os ombros, e se a essa situação somarmos o potencial da Internet das Coisas, somos obrigados a falar de milhões de dispositivos adicionais completamente em risco. Espera-se que alguns desses gadgets funcionem por cinco ou dez anos sem receber uma única atualização, e, com essa mecânica, o kernel Linux fica preso entre a espada e a parede.
A necessidade de autoproteção do kernel
Em outras palavras, o kernel Linux não pode continuar perseguindo bugs. De acordo com Kees Cook, desenvolvedor no Google e responsável pelo Linux Kernel Self-Protection Project, o “tempo de vida” de um bug no kernel (ou seja, desde sua introdução até o patch) varia entre 3,3 e 6,4 anos. Esses vazios se tornaram um parâmetro inaceitável, e os atacantes observam com cuidado cada novo “commit” para detectar e explorar bugs. Isso define a proteção avançada do kernel como uma missão fundamental, no entanto, existe outro inconveniente: 85% dos bugs no kernel não nascem do seu núcleo, mas sim dos controladores integrados. O baixo controle de qualidade demonstrado por alguns fabricantes é preocupante e contribui para a incerteza de segurança que atravessa o kernel.
Agora, os desafios não são apenas técnicos, mas também políticos. O olho treinado notará que esse “conflito” tem muito em comum com o debate de “kernel monolítico vs. microkernel” que agitou os entusiastas do Linux mais de uma vez e que continua sendo fonte de notáveis intercâmbios. Ainda assim, como disse no início, o universo Linux mudou para sempre. Novos problemas de segurança exigem novas soluções, e uma espécie de “imunidade geral” no kernel não soa tão mal. Retirar os controladores do kernel e transferir seu funcionamento para o “userland” está longe de ser uma solução mágica, mas aí está o ponto: não precisamos de soluções mágicas, mas de soluções robustas que protejam o kernel em longo prazo. A palestra de Kees Cook dura pouco mais de 45 minutos e ali ele detalha alguns dos avanços feitos pelo Self-Protection Project, além de sugestões adicionais para implementar no futuro. Se esse tema te atrai, vale a pena vê-la.
