O trabalho de segurança do kernel Linux

• A equipe de segurança do kernel Linux corrige as vulnerabilidades relatadas o mais rápido possível e as mescla no repositório público, sem fazer avisos ou anúncios separados
• Essa equipe é separada da equipe de CVE do kernel, responsável pela emissão de CVEs, e todos atuam em caráter individual, operando independentemente de vínculo com empresas
• Bugs de segurança são tratados da mesma forma que bugs comuns e, após a correção, não são marcados como “patches de segurança” separados
• Não mantém embargo por mais de 7 dias, e a maioria das correções é divulgada imediatamente
• Essa abordagem leva em conta a natureza do open source e a diversidade dos ambientes de uso, mantendo a transparência e a independência da resposta de segurança do kernel

---

O papel da equipe de segurança do kernel Linux

• A equipe de segurança do kernel é um grupo de desenvolvedores que classifica potenciais bugs de segurança relatados e os corrige rapidamente
  • Eles são responsáveis por uma resposta de segurança reativa, separada das medidas preventivas de longo prazo conduzidas pelo Kernel Self-Protection Project
• O processo de relato é feito por e-mail em texto simples, e HTML, anexos binários e criptografia não são permitidos
  • Relatos criptografados não podem ser processados devido à estrutura com múltiplos destinatários
• Os membros da equipe são desenvolvedores centrais que representam os principais subsistemas do kernel e não podem compartilhar o conteúdo das discussões com empregadores ou terceiros
  • Essa independência permite uma resposta consistente, independentemente de exigências legais de diferentes países, como a CRA

Procedimento de correção de bugs

• Se o bug relatado estiver relacionado a um subsistema específico, o mantenedor desse subsistema é incluído na discussão por e-mail para resolver o problema
  • Em subsistemas com problemas recorrentes, o mantenedor pode participar diretamente da lista de discussão da equipe de segurança
• Se o relator fornecer o patch de correção, o crédito é atribuído a ele; caso contrário, os desenvolvedores resolvem por conta própria
• Quando a correção é concluída, ela é mesclada no branch principal do kernel e nas releases stable

Política de embargo

• Períodos de embargo superiores a 7 dias não são permitidos, e a maioria das correções é divulgada imediatamente
• Após a correção, o relator pode fazer um anúncio externo se quiser, mas a própria equipe de segurança não faz nenhum anúncio
• A atribuição de CVEs é feita depois pela equipe de CVE do kernel, separadamente da equipe de segurança

O princípio de que “bug é só bug”

• Em 2008, Linus Torvalds deixou claro que bugs de segurança não devem ser marcados separadamente
  • A justificativa é que a distinção como “correção de segurança” distorce a importância dos outros bugs
• Todas as correções de bugs são igualmente importantes e são aplicadas imediatamente, sem distinção entre segurança, funcionalidade ou desempenho

Por que não existem avisos de segurança

• Quase todos os bugs em nível de kernel podem potencialmente se tornar problemas de segurança
  • Eles podem assumir várias formas, como vazamento de memória, negação de serviço e exposição de informações
• Por causa da natureza do open source, os desenvolvedores não conhecem o ambiente real dos usuários
  • Uma correção trivial para um usuário pode ser uma vulnerabilidade crítica para outro
• Por isso, a política é simples
  • Bugs conhecidos são corrigidos imediatamente
  • Releases corrigidas são distribuídas o mais rápido possível
• A posição é que, mais do que a preocupação de que “a correção possa causar problemas”, é mais perigoso deixar um bug conhecido sem correção

Questões de segurança de hardware

• Problemas que envolvem tanto o sistema operacional quanto o hardware, como os casos Spectre e Meltdown, exigem procedimentos excepcionais
  • Para isso, foi criada a “Hardware Security Policy”, que viabiliza a colaboração por meio de uma lista de discussão criptografada e restrita
• Esse processo é lento e complexo, mas recentemente muitos bugs de hardware estão sendo resolvidos sem esse procedimento
• No futuro, os requisitos de tempo de resposta da legislação CRA tendem a tornar embargos longos ainda mais difíceis

Como surgiu a equipe de segurança do kernel

• Antes de 2005, não existia um canal oficial de contato para segurança
  • Os relatos eram feitos apenas por redes informais entre desenvolvedores
• Em 2005, a discussão começou com uma proposta por e-mail de Steve Bergman, e
  Chris Wright escreveu o patch que adicionou o contato de segurança e a documentação
  • Depois disso, o alias de e-mail central ([e-mail]) foi formalizado

Ausência de avisos de segurança e de alertas antecipados

• A equipe de segurança do kernel não opera nenhum tipo de aviso de segurança nem lista de alertas antecipados
  • A atribuição de IDs CVE é responsabilidade da equipe de CVE do kernel, e a equipe de segurança não participa disso
• Há muitos pedidos por uma lista de alertas antecipados, mas ela não existe por causa do risco de vazamento e do princípio de caráter público
  • A posição é: “se um governo permitisse isso, então esse projeto provavelmente não estaria sendo usado de verdade”

---

[GN⁺]

Comentários do Hacker News

• Recentemente, as tecnologias que tornam a experiência de virtualização fluida no desktop Linux estão avançando rapidamente
  Os drivers de GPU passaram a oferecer suporte a contextos nativos via Mesa, e as funcionalidades de compartilhamento entre convidado e host no Wayland também estão melhorando
  Antes, era necessário fazer parsing de protocolos complexos como sommelier ou wayland-proxy-virtwl, mas agora o projeto wl-cross-domain-proxy está implementando isso da forma correta
  Entre os VMMs que usam esses recursos estão o muvm, e como solução que integra tudo isso existe o munix

  • Muito interessante. Fico curioso se seria possível fazer migração ao vivo de apps entre máquinas usando munix
    Seria incrível conseguir pausar, transferir e depois retomar uma máquina virtual desse jeito

• É por isso que a Red Hat continua importante mesmo em 2025
  Esse tipo de trabalho de infraestrutura sempre será necessário

  • Dá até para defender o argumento oposto
    Quando a Red Hat faz cherry-pick de commits relacionados a segurança, como ela vai saber quais commits no upstream têm relação com segurança se ninguém disser isso?

• Às vezes sonho com um SO 100% seguro
  Talvez verificação formal ou Rust sejam a chave
  Queria ter a certeza de que ele não pode ser invadido

  • Um “SO que não pode ser hackeado” soa ótimo. Mas no fim ainda existem os ataques de engenharia social
    No final das contas, o ser humano continua sendo a maior vulnerabilidade
  • Já houve várias tentativas nesse sentido. O Verve OS da Microsoft é um exemplo representativo
    Até o assembly foi verificado, e o Dafny também surgiu daí
    Mas no mercado, “entregar rápido” vem antes de “boa qualidade”, então levará décadas até que esse tipo de ideia vire algo dominante
  • Na maioria dos casos, os recursos de isolamento comprometidos por bugs de segurança na prática são usados só por conveniência administrativa
    Para isolamento de verdade, é preciso virtualização ou separação física
    Por isso é difícil reunir muitos contribuidores em torno de um “SO 100% seguro”
    Ainda assim, se você se interessa por esse tema, existem vários projetos de desenvolvimento de SOs
  • Então a saída é usar Qubes OS
  • O que foi feito por humanos pode ser quebrado por humanos
    Segurança é uma corrida sem fim

• Enquanto isso, mesmo já sendo 2026, o site pessoal do Greg ainda não oferece suporte a TLS

  • Sinceramente, acho que não vale muito a pena até que Encrypted Client Hello tenha suporte amplo
    É fácil configurar isso com Caddy, mas para um site estático como um blog pessoal, o ganho prático da criptografia é quase nulo
    De qualquer forma, domínio e IP continuam expostos em texto puro, então a diferença não é tão grande

• Se eles realmente pensam assim, então não deveriam ter removido o CNA?

  • Isso acabaria significando que “qualquer pesquisador de segurança pode definir arbitrariamente vulnerabilidades do kernel”
    Mas alguns pesquisadores tendem a querer apenas aumentar a contagem de CVEs, então tentam dar prioridade alta até para bugs inofensivos

• “Se para reportar problemas de segurança você exige criptografia, então reavalie essa política (estou falando do governo do Reino Unido)”
  Essa parte é simplesmente engraçada

• Dizer que “bug é só bug” é simplificar demais
  Um DoS que exige privilégio de root e uma tomada de controle do sistema por um usuário sem privilégios são coisas completamente diferentes
  Alguns bugs claramente causam violação da fronteira de segurança, e esses devem ser classificados como bugs de segurança
  Isso já foi explicado ao Greg por décadas
  Em resumo, se você não estiver rodando a versão mais recente, o kernel está completamente sem todos os patches
  CVEs são evitados, as correções de vulnerabilidades ficam escondidas nos logs de commit, e os atacantes percebem isso

  • “Isso de que só a versão mais recente recebe patches não vale para a maioria dos softwares também?”
    Não entendo por que isso precisaria ser enfatizado

• Clientes pedem patches relacionados ao kernel em imagens Docker
  Só que o Docker nem inclui o kernel
  Deveria existir alguma forma de distribuir imagens sem kernel

  • Dá para o kernel Linux acabar incluído por engano em uma imagem de contêiner?
    Imagens base normais não incluem o kernel
  • Como projeto relacionado, vale olhar o wolfi-dev