Kees Cook, ex-administrador-chefe de sistema do kernel.org e líder da equipe de segurança do Ubuntu que agora trabalha no Google para proteger o Android e o ChromeOS, expressou preocupação com o processo atual de correção de bugs nas ramificações estáveis do kernel. Toda semana, cerca de cem correções são incluídas nas ramificações estáveis, e após o fechamento da janela para aceitação de alterações na próxima versão, ela se aproxima de mil (os mantenedores mantêm as correções até que a janela seja fechada e após a formação de “ -rc1” publicam os acumulados de uma só vez), o que é demais e exige muita mão de obra para produtos de manutenção baseados no kernel Linux.
Segundo Kies, o processo de correção de bugs no kernel não está recebendo a atenção que merece, e o kernel carece de pelo menos 100 desenvolvedores adicionais para coordenar seu trabalho. Os desenvolvedores principais do kernel corrigem bugs regularmente, mas não há garantia de que essas correções serão implementadas nas variantes do kernel usadas por fabricantes terceirizados. Os usuários de diversos produtos baseados em Linux também não têm como controlar quais bugs foram corrigidos ou qual kernel é usado em seus dispositivos. Em última análise, os fabricantes são responsáveis pela segurança de seus produtos, mas com o ritmo acelerado de lançamentos de patches em branches estáveis do kernel, eles se veem diante de uma escolha: implementar todas as correções, implementar seletivamente as mais importantes ou ignorar todas as correções.
Como resultado, sem uma ramificação dedicada para correções de vulnerabilidades e sem informações sobre as implicações de segurança de qualquer problema específico, os fornecedores do kernel Linux são forçados a migrar continuamente todas as correções das ramificações estáveis mais recentes. No entanto, esse trabalho é trabalhoso e encontra resistência dentro das empresas devido a preocupações com a introdução de alterações regressivas que possam prejudicar a funcionalidade do produto.
Como lembrete, Linus Torvalds acredita que todos os bugs são importantes e que as vulnerabilidades não devem ser separadas de outros tipos de bugs nem priorizadas. Isso porque, para o desenvolvedor médio que não é um profissional de segurança, a conexão entre uma correção e uma vulnerabilidade potencial não é imediatamente óbvia (para muitas correções, apenas uma auditoria separada revela suas implicações de segurança). Linus acredita que a identificação de vulnerabilidades potenciais no fluxo geral de patches deve ser responsabilidade dos especialistas em segurança das equipes responsáveis pela manutenção dos pacotes do kernel nas distribuições Linux.
Kees Cook acredita que a única solução para manter a segurança do kernel a um custo razoável a longo prazo é as empresas transferirem os engenheiros envolvidos na portabilidade de correções para compilações locais do kernel em um esforço conjunto e coordenado para manter correções e vulnerabilidades no kernel principal (upstream ). Em sua forma atual, muitos fabricantes não usam as versões mais recentes do kernel em seus produtos e fazem backport das correções internamente, ou seja, Acontece que engenheiros de empresas diferentes duplicam o trabalho uns dos outros, resolvendo o mesmo problema.
Por exemplo, se 10 empresas, cada uma com um engenheiro fazendo o backport das mesmas correções, redirecionarem esses engenheiros para a correção de bugs upstream, em vez de fazerem o backport de uma única correção, eles poderiam corrigir 10 bugs diferentes para o bem comum ou participar da revisão de mudanças propostas e impedir que código com bugs seja incluído no núcleo. Os recursos também poderiam ser direcionados para a criação de novas ferramentas de teste e análise de código que identificariam automaticamente classes recorrentes de bugs logo no início.
Keith Cook também sugere um uso mais ativo de testes automatizados e de fuzzing diretamente durante o desenvolvimento do kernel, o uso de sistemas de integração contínua e o abandono do gerenciamento de desenvolvimento arcaico baseado em e-mail. Atualmente, a eficácia dos testes é prejudicada pelo fato de os principais processos de teste estarem separados do desenvolvimento e ocorrerem após os lançamentos. Keith também recomendou o uso de linguagens que ofereçam suporte mais robusto durante o desenvolvimento para reduzir o número de erros. alto nível de segurança, como o Rust.
Fonte: opennet.ru
