Greg Kroah-Hartman, da Linux Foundation, fez uma palestra abrangente na semana que passou sobre o estado atual e os desafios futuros da segurança do kernel Linux. Falando no Open Source Summit (OSS) Japão 2023, Kroah-Hartman – mantenedor do kernel estável do Linux e membro importante da equipe de segurança do kernel Linux – lançou luz sobre o cenário em evolução da segurança de software de código aberto, desafios regulatórios e a resposta do kernel Linux a esses problemas. Assim, o Linux aprimora segurança do kernel para evitar ataques ao sistema operacional.
Dificilmente passa um dia sem que surja um problema de segurança de software, e os governos estão agora a tentar orientar a forma como as empresas e organizações devem mitigar os problemas de segurança. Só há um problema: os governos mal entendem como usar software, muito menos como os desenvolvedores de código aberto criam software.
Por exemplo, a Lei de Resiliência Cibernética (CRA) proposta pela União Europeia está cheia de boas intenções, mas não é adequada para quem cria software de código aberto. Embora a versão mais recente seja muito melhor, como salientou Kroah-Hartman, ainda significa que, uma vez que “todo o mundo vende os seus dispositivos e produtos para a UE, isto definirá os seus requisitos de segurança”.
Estamos prontos para lidar com esta nova onda de regulamentação? Não, não estamos.
Quanto à comunidade Linux, Kroah-Hartman disse que a equipe de segurança do kernel Linux é fundamentalmente reativa, ao contrário de outras equipes de segurança que adotam uma postura proativa. Desde a sua criação formal em 2005, a equipe tem operado informalmente, sem afiliações corporativas ou contratos. Isto permite neutralidade e flexibilidade na abordagem de questões de segurança. Essa abordagem promoveu a confiança entre as empresas e gerenciou e fez triagem eficaz de problemas de segurança.
“Existem outros grupos, equipes de segurança do kernel e outros projetos”, acrescentou ele, “que são proativos. Mas não é isso que fazemos. Apenas reagimos aos problemas”.
E há muitos problemas para resolver. Por exemplo, Kroah-Hartman destacou os desafios contínuos com a segurança de hardware, especialmente após vulnerabilidades como Spectre e Meltdown. Na verdade, como ele destacou, já se passaram mais de três anos desde que esses bugs graves de CPU apareceram, e enquanto “eles continuam tentando consertá-los no hardware, outro foi anunciado há algumas horas. Portanto, isso não terá fim tão cedo”.
Isto sublinha as complexidades de lidar com embargos de hardware e os ciclos de desenvolvimento mais longos de hardware em comparação com software. Idealmente, Kroah-Hartman deseja que as empresas de hardware “acertem a bola mais rápido”, um sentimento ecoado por governos e órgãos reguladores.
Linux aprimora segurança do kernel para evitar ataques ao sistema operacional
Kroah-Hartman também destacou que “muitas pessoas [hoje] não percebem que, embora o modelo de distribuição comercial do Linux não esteja morto, ele não é mais a maioria, de longe. 80% dos servidores e sistemas do mundo funcionam gratuitamente e projetos de código aberto baseados em Debian, Fedora ou openSUSE” – não Red Hat Enterprise Linux (RHEL) ou SUSE Linux Enterprise Server (SLES).
Essa realidade complicou os desafios de segurança porque, explicou Korah-Hartman, “as comunidades que trabalham com estes projetos de código aberto não podem assinar um acordo de confidencialidade (NDA) porque os membros da sua comunidade vivem noutros países ou trabalham para empresas diferentes. “
Em vez disso, a equipe de segurança dos desenvolvedores do kernel Linux é um “grupo informal ad hoc” sem contrato. Kroah-Hartman continuou: “E essa foi a melhor coisa que poderia acontecer para preparar o terreno para que fizéssemos isso de uma forma neutra para a empresa e o governo. Isso nos salvou de muitos problemas.”
Notícias Relacionadas
Linux 6.12
Como compilar e instalar o Linux Kernel 6.12: Tutorial completo e detalhado
Compilar e instalar o Linux Kernel manualmente é uma habilidade valiosa para usuários avançados e entusiastas de tecnologia. Essa prática permite personalizar o kernel para suas necessidades específicas, otimizar o desempenho do sistema e adicionar suporte a hardwares mais recentes antes que eles sejam incluídos nas distribuições padrão. Neste tutorial, você aprenderá a baixar, compilar […]
Linux kernel
Linux 6.13: avanços no gerenciamento de energia com AMD e Intel
O Linux 6.13 marca um novo capítulo no gerenciamento de energia para hardware moderno. Com mudanças significativas para sistemas AMD e Intel, as atualizações incluem desde ajustes no driver AMD P-State até novos valores de EPP para processadores Intel Xeon Granite Rapids. O objetivo dessas modificações é maximizar desempenho e eficiência energética. Lembre-se que o […]
Como funciona: As pessoas enviam relatórios de segurança aos membros do grupo. Não há nem uma lista de e-mail. Há apenas um pequeno grupo, que não representa nenhuma empresa. Kroah-Hartman acrescentou: “Está tudo em segredo e, desde 2005, nunca tivemos nenhum vazamento”.
O que eles fazem, continuou Kroah-Hartman, “é fazer a triagem dos relatórios, descobrir o que há de errado e atrair os desenvolvedores adequados, se eles ainda não estiverem na lista, para criar a correção o mais rápido possível.”
Quando dizem “o mais rápido possível”, eles estão falando sério. “Assim que tivermos uma solução, o máximo que poderemos esperar são sete dias. Isto é”, continuou Kroah-Hartman, “depois de termos uma solução. Quando recebemos um relatório, começamos a trabalhar nele o mais rápido possível. Tivemos algumas correções que levarão mais de um ano. Tivemos alguns problemas de rede. Acho que demoramos 18 meses antes de consertá-lo corretamente. Mas depois que consertamos, a correção entra em ação.”
E as correções de segurança?
O grupo também não faz anúncios de correções de segurança. “Não anunciamos nada. Não dizemos nada de especial. Apenas inserimos para que pareça uma correção de bug normal.”
Sim, isso deixa as pessoas com raiva. Mas, explicou Kroah-Hartman, “para as pessoas da equipe de segurança, um bug é um bug, é um bug. Não há nada de especial nas correções de segurança. E se chamarmos as correções de segurança de especiais, isso implica que outras correções não são especiais.”
Isso é um erro porque, de acordo com Kroah-Hartman, “qualquer bug tem o potencial de ser um problema de segurança no nível do kernel”. Uma pequena correção de bug que ele fez anos atrás no TTY, um subsistema secundário do Linux hoje, revelou ter uma falha de segurança mortal. Ele permitiu que qualquer pessoa fizesse root em sistemas RHEL. Você nunca sabe onde ou quando surgirá um problema de segurança.
Kroah-Hartman também observou que, embora o “kernel do Linux tenha cerca de 30 milhões de linhas de código, você usa apenas cerca de dois milhões de linhas em seu servidor, 4 milhões em seu telefone e um milhão e meio em sua TV. Não sabemos o que você está usando. O Linux está em todo lugar, em seus carros, em satélites e em máquinas de ordenha de vacas. Não sabemos seu caso de uso. Não sabemos como você está usando o Linux. Não sabemos o que você está usando. Não sei qual é o modelo de segurança.” Portanto, tudo e qualquer coisa deve ser considerado essencial.
Então, o que você pode fazer para se proteger? Kroah-Hatman enfatizou que você deve sempre usar o kernel estável de longo prazo (LTS) mais recente.
Infelizmente, poucas distribuições Linux fazem isso. Ele criticou as empresas que não atualizam seus kernels regularmente. Sistemas desatualizados, de onde ele está, são inerentemente inseguros.
Esta não é apenas a opinião dele. Após anos de estudo, Kroah-Hartman citou a equipe de segurança do Google Android, que descobriu que os kernels estáveis ??do Linux corrigiram todos os problemas de segurança recentes conhecidos antes de serem relatados. Eles documentaram provas de que usar kernels estáveis ??sempre funciona e que seus sistemas estarão seguros. Como engenheiro de kernel do Google Linux, Kees Cook disse: “Então, o que um fornecedor deve fazer? A resposta é simples, embora dolorosa: atualizar continuamente para a versão mais recente do kernel, seja principal ou estável.”
