1.. SPDX-License-Identifier: GPL-2.0 2 3Falhas de segurança 4=================== 5 6Os desenvolvedores do kernel Linux levam a segurança muito a sério. Como tal, 7gostaríamos de saber quando uma falha de segurança é encontrada para que ela 8possa ser corrigida e divulgada o mais rápido possível. 9 10Preparando seu relatório 11------------------------ 12 13Como em qualquer relatório de bug, um relatório de falha de segurança exige 14muito trabalho de análise por parte dos desenvolvedores, portanto, quanto mais 15informações você puder compartilhar sobre o problema, melhor. Por favor, revise 16o procedimento descrito em Documentation/admin-guide/reporting-issues.rst se 17você não tiver certeza sobre quais informações são úteis. As seguintes 18informações são absolutamente necessárias em **qualquer** relatório de falha de 19segurança: 20 21 * **versão do kernel afetada**: sem indicação de versão, seu relatório não 22 será processado. Uma parte significativa dos relatórios é de bugs que já 23 foram corrigidos, portanto, é extremamente importante que as 24 vulnerabilidades sejam verificadas em versões recentes (árvore de 25 desenvolvimento ou a versão estável mais recente), pelo menos verificando 26 se o código não mudou desde a versão onde foi detectado. 27 28 * **descrição do problema**: uma descrição detalhada do problema, com rastros 29 mostrando sua manifestação, e por que você considera o comportamento 30 observado como um problema no Kernel, é necessária. 31 32 * **reproduzir**: os desenvolvedores precisarão ser capazes de reproduzir o 33 problema para considerar uma correção como eficaz. Isso inclui tanto uma 34 maneira de acionar o problema quanto uma maneira de confirmar que ele 35 ocorre. Será necessário um reprodutor com dependências de baixa 36 complexidade (código-fonte, script de shell, sequência de instruções, 37 imagem de sistema de arquivos, etc). Executáveis apenas binários não são 38 aceitos. Exploits funcionais são extremamente úteis e não serão divulgados 39 sem o consentimento do relator, a menos que já sejam públicos. Por 40 definição, se um problema não pode ser reproduzido, ele não é explorável, 41 portanto, não é um bug de segurança. 42 43 * **condições**: se o bug depender de certas opções de configuração, sysctls, 44 permissões, temporização, modificações de código, etc., estas devem ser 45 indicadas. 46 47Além disso, as seguintes informações são altamente desejáveis: 48 49 * **localização suspeita do bug**: os nomes dos arquivos e funções onde 50 se suspeita que o bug esteja presente são muito importantes, pelo menos 51 para ajudar a encaminhar o relatório aos mantenedores apropriados. Quando 52 não for possível (por exemplo, "o sistema trava toda vez que executo este 53 comando"), a equipe de segurança ajudará a identificar a origem do bug. 54 55 * **uma proposta de correção**: os relatores de bugs que analisaram a causa 56 de uma falha no código-fonte quase sempre têm uma ideia precisa de como 57 corrigi-lo, porque passaram muito tempo estudando o problema e suas 58 implicações. Propor uma correção testada poupará muito tempo dos 59 mantenedores, mesmo que a correção acabe não sendo a correta, pois ajuda a 60 entender o bug. Ao propor uma correção testada, por favor, formate-a 61 sempre de uma maneira que possa ser mesclada imediatamente (consulte 62 Documentation/process/submitting-patches.rst). Isso evitará algumas trocas 63 de mensagens caso ela seja aceita, e você receberá o crédito por 64 encontrar e corrigir o problema. Observe que, neste caso, apenas uma tag 65 ``Signed-off-by:`` é necessária, sem ``Reported-by:`` quando o relator e 66 o autor forem a mesma pessoa. 67 68 * **mitigações**: com muita frequência, durante a análise de um bug, 69 surgem algumas maneiras de mitigar o problema. É útil compartilhá-las, 70 pois podem ser úteis para manter os usuários finais protegidos durante o 71 tempo que levam para aplicar a correção. 72 73O que se qualifica como um bug de segurança 74------------------------------------------- 75 76É importante que a maioria dos bugs seja tratada publicamente, de modo a 77envolver o maior público possível e encontrar a melhor solução. Por natureza, 78bugs que são tratados em discussões fechadas entre um pequeno conjunto de 79participantes têm menos probabilidade de produzir a melhor correção possível 80(por exemplo, risco de perder casos de uso válidos, capacidades de testes 81limitadas). 82 83Acontece que a maioria dos bugs relatados por meio da equipe de segurança são 84apenas bugs comuns que foram qualificados incorretamente como bugs de segurança 85devido à falta de conhecimento do modelo de ameaças do kernel Linux, conforme 86descrito em Documentation/process/threat-model.rst, e deveriam ter sido 87enviados através dos canais normais descritos em 88Documentation/admin-guide/reporting-issues.rst 89 90A lista de segurança existe para bugs urgentes que concedem a um atacante uma 91capacidade que ele não deveria ter em um sistema de produção corretamente 92configurado, e que podem ser facilmente explorados, representando uma ameaça 93iminente para muitos usuários. Antes de relatar, considere se o problema 94realmente ultrapassa um limite de confiança em tal sistema. 95 96**Se você recorreu a assistência de IA para identificar um bug, você deve 97tratá-lo como público**. Embora você possa ter motivos válidos para acreditar 98que não seja, a experiência da equipe de segurança mostra que os bugs 99descobertos desta forma surgem sistematicamente e de forma simultânea entre 100múltiplos pesquisadores, frequentemente no mesmo dia. Neste caso, não 101compartilhe publicamente um reprodutor, pois isso poderia causar danos não 102intencionais; apenas mencione que um está disponível e os mantenedores poderão 103solicitá-lo privadamente se precisarem. 104 105Se você não tiver certeza se um problema se qualifica, opte por relatar de 106forma privada: a equipe de segurança prefere triar um relatório limítrofe 107a perder uma vulnerabilidade real. Relatar bugs comuns na lista de segurança, 108no entanto, não faz com que eles andem mais rápido e consome a capacidade de 109triagem de que outros relatórios precisam. 110 111Identificando contatos 112---------------------- 113 114A maneira mais eficaz de relatar um bug de segurança é enviá-lo diretamente 115aos mantenedores do subsistema afetado e Cc: para a equipe de segurança do 116kernel Linux. Não o envie para uma lista pública nesta fase, a menos que você 117tenha bons motivos para considerar o problema como público ou trivial de ser 118descoberto (por exemplo, resultado de uma ferramenta automatizada de varredura 119de vulnerabilidades amplamente disponível que possa ser repetida por qualquer 120pessoa, ou o uso de ferramentas baseadas em IA). 121 122Se você estiver enviando um relatório de problemas que afetam várias partes no 123kernel, mesmo que sejam problemas bastante semelhantes, envie mensagens 124individuais (pense que os mantenedores não trabalharão todos nos problemas ao 125mesmo tempo). A única exceção é quando um problema diz respeito a partes 126intimamente relacionadas, mantidas pelo exato mesmo subconjunto de 127mantenedores, e espera-se que essas partes sejam todas corrigidas de uma só vez 128pelo mesmo commit; então pode ser aceitável relatá-las de uma vez. 129 130Uma dificuldade para a maioria dos relatores de primeira viagem é descobrir a 131lista certa de destinatários para enviar um relatório. No kernel Linux, todos 132os mantenedores oficiais são confiáveis, portanto as consequências de incluir 133acidentalmente o mantenedor errado são apenas um pequeno ruído para essa 134pessoa, ou seja, nada dramático. Sendo assim, um método adequado para descobrir 135a lista de mantenedores (o qual os oficiais de segurança do kernel usam) é 136contar com o script get_maintainer.pl, ajustado para relatar apenas 137mantenedores. Este script, quando recebe um nome de arquivo, procurará por seu 138caminho no arquivo MAINTAINERS para deduzir uma lista hierárquica de 139mantenedores relevantes. Chamá-lo pela primeira vez com o nível mais refinado 140de filtragem retornará, na maioria das vezes, uma lista curta de mantenedores 141deste arquivo específico:: 142 143 $ ./scripts/get_maintainer.pl --no-l --no-r --pattern-depth 1 \ 144 drivers/example.c 145 Developer One <dev1@example.com> (maintainer:example driver) 146 Developer Two <dev2@example.org> (maintainer:example driver) 147 148Estes dois mantenedores devem então receber a mensagem. Se o comando não 149retornar nada, isso significa que o arquivo afetado faz parte de um subsistema 150mais amplo, portanto devemos ser menos específicos:: 151 152 $ ./scripts/get_maintainer.pl --no-l --no-r drivers/example.c 153 Developer One <dev1@example.com> (maintainer:example subsystem) 154 Developer Two <dev2@example.org> (maintainer:example subsystem) 155 Developer Three <dev3@example.com> (maintainer:example subsystem [GENERAL]) 156 Developer Four <dev4@example.org> (maintainer:example subsystem [GENERAL]) 157 158Aqui, escolher os primeiros, mais específicos, é suficiente. Quando a lista for 159longa, é possível produzir uma lista de endereços de e-mail delimitada por 160vírgulas em uma única linha adequada para o uso no campo TO: de um cliente de 161e-mail como este:: 162 163 $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \ 164 --no-git-fallback --no-substatus --no-rolestats --no-multiline \ 165 --pattern-depth 1 drivers/example.c 166 dev1@example.com, dev2@example.org 167 168ou este para a lista mais ampla:: 169 170 $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \ 171 --no-git-fallback --no-substatus --no-rolestats --no-multiline \ 172 drivers/example.c 173 dev1@example.com, dev2@example.org, dev3@example.com, dev4@example.org 174 175Se a esta altura você ainda estiver enfrentando dificuldades para identificar 176os mantenedores corretos, e apenas neste caso, é possível enviar seu 177relatório apenas para a equipe de segurança do kernel Linux. Sua mensagem 178será triada e você receberá instruções sobre quem contatar, se necessário. 179Sua mensagem poderá igualmente ser encaminhada como está para os mantenedores 180relevantes. 181 182Uso responsável de IA para encontrar bugs 183----------------------------------------- 184 185Uma fração significativa dos relatórios de bugs enviados à equipe de segurança 186é, na verdade, o resultado de revisões de código assistidas por ferramentas de 187IA. Embora isso possa ser um meio eficiente de encontrar bugs em áreas 188raramente exploradas, causa uma sobrecarga nos mantenedores, que às vezes são 189forçados a ignorar tais relatórios devido à sua má qualidade ou precisão. Sendo 190assim, os relatores devem ter um cuidado especial com vários pontos que tendem 191a tornar esses relatórios desnecessariamente difíceis de lidar: 192 193 * **Comprimento**: Os relatórios gerados por IA tendem a ser excessivamente 194 longos, contendo várias seções e detalhes em excesso. Isso dificulta a 195 identificação de informações importantes, como arquivos afetados, versões e 196 impacto. Por favor, certifique-se de que um resumo claro do problema e 197 todos os detalhes críticos sejam apresentados primeiro. Não exija que os 198 engenheiros de triagem analisem várias páginas de texto. Configure suas 199 ferramentas para produzir relatórios concisos e em estilo humano. 200 201 * **Formatação**: A maioria dos relatórios gerados por IA está repleta de 202 tags Markdown. Essas decorações complicam a busca por informações 203 importantes e não sobrevivem aos processos de citação envolvidos no 204 encaminhamento ou nas respostas. Por favor, sempre converta seu relatório 205 para texto simples sem quaisquer decorações de formatação antes de 206 enviá-lo. 207 208 * **Avaliação de Impacto**: Muitos relatórios gerados por IA carecem de uma 209 compreensão do modelo de ameaças do kernel (consulte 210 Documentation/process/threat-model.rst) e fazem de tudo para inventar 211 consequências teóricas. Isso adiciona ruído e complica a triagem. Por 212 favor, limite-se a fatos verificáveis (por exemplo, "este bug permite que 213 qualquer usuário obtenha CAP_NET_ADMIN") sem enumerar implicações 214 especulativas. Faça com que sua ferramenta leia esta documentação como 215 parte do processo de avaliação. 216 217 * **Reproduzidor**: As ferramentas baseadas em IA são frequentemente capazes 218 de gerar reproduzidores. Por favor, certifique-se sempre de que sua 219 ferramenta forneça um e teste-o exaustivamente. Se o reproduzidor não 220 funcionar, ou se a ferramenta não puder produzir um, a validade do 221 relatório deve ser seriamente questionada. Observe que, como o relatório 222 será postado em uma lista pública, o reproduzidor só deve ser compartilhado 223 mediante solicitação dos mantenedores. 224 225 * **Propor uma Correção:** muitas ferramentas de IA são na verdade melhores 226 em escrever código do que em avaliá-lo. Por favor, peça à sua ferramenta 227 para propor uma correção e teste-a antes de relatar o problema. 228 Se a correção não puder ser testada porque depende de hardware raro ou de 229 protocolos de rede quase extintos, é provável que o problema não seja um 230 bug de segurança. Em qualquer caso, se uma correção for proposta, ela deve 231 aderir a Documentation/process/submitting-patches.rst e incluir uma tag 232 'Fixes:' designando o commit que introduziu o bug. 233 234A falha em considerar estes pontos expõe seu relatório ao risco de ser 235ignorado. 236 237Use o bom senso ao avaliar o relatório. Se o arquivo afetado não tiver sido 238alterado por mais de um ano e for mantido por um único indivíduo, é provável 239que o uso tenha diminuído e os usuários expostos sejam virtualmente 240inexistentes (por exemplo, drivers para hardware muito antigo, sistemas de 241arquivos obsoletos). Nesses casos, não há necessidade de consumir o tempo de 242um mantenedor com um relatório sem importância. Se o problema for claramente 243trivial e publicamente detectável, você deve relatá-lo diretamente às listas 244de discussão públicas. 245 246Enviando o relatório 247-------------------- 248 249Os relatórios devem ser enviados exclusivamente por e-mail. Por favor, use um 250endereço de e-mail funcional, de preferência o mesmo que você deseja que 251apareça nas tags ``Reported-by``, se houver. Se não tiver certeza, envie o seu 252relatório para você mesmo primeiro. 253 254A equipe de segurança e os mantenedores quase sempre exigem informações 255adicionais além das fornecidas inicialmente em um relatório e dependem de uma 256colaboração ativa e eficiente com o relator para realizar testes adicionais 257(por exemplo, verificar versões, opções de configuração, mitigações ou 258patches). Antes de entrar em contato com a equipe de segurança, o relator deve 259certificar-se de que está disponível para explicar suas descobertas, participar 260de discussões e executar testes adicionais. Relatórios nos quais o relator não 261responde prontamente ou não consegue discutir suas descobertas de forma eficaz 262podem ser abandonados se a comunicação não melhorar rapidamente. 263 264O relatório deve ser enviado aos mantenedores. Se houver dois ou menos 265destinatários em sua mensagem, você também deve sempre colocar em Cc: a equipe 266de segurança do kernel Linux, que garantirá que a mensagem seja entregue às 267pessoas corretas e poderá auxiliar pequenas equipes de mantenedores com 268processos com os quais eles possam não estar familiarizados. Para equipes 269maiores, coloque em Cc: a equipe de segurança do kernel Linux em seus primeiros 270relatórios ou ao buscar ajuda específica, como ao reenviar uma mensagem que não 271obteve resposta dentro de uma semana. Assim que você se sentir confortável com 272o processo após alguns relatórios, não será mais necessário colocar a lista de 273segurança em Cc: ao enviar para equipes grandes. A equipe de segurança do 274kernel Linux pode ser contatada por e-mail em security@kernel.org. Esta é uma 275lista privada de oficiais de segurança que ajudarão a verificar o relatório de 276bug e auxiliarão os desenvolvedores que trabalham em uma correção. É possível 277que a equipe de segurança traga ajuda extra de mantenedores da área para 278entender e corrigir a vulnerabilidade de segurança. 279 280Por favor, envie e-mails em **texto simples** sem anexos, sempre que possível. 281É muito mais difícil ter uma discussão com citações de contexto sobre um 282problema complexo se todos os detalhes estiverem ocultos em anexos. Pense nisso 283como uma :doc:`regular path submission </../../../process/submitting-patches>` 284(mesmo que você ainda não tenha um patch): descreva o problema e o impacto, 285liste as etapas de reprodução e siga com uma proposta de correção, tudo em 286texto simples. Relatórios formatados em Markdown, HTML e RST são 287particularmente malvistos, pois são bastante difíceis de ler por humanos e 288incentivam o uso de visualizadores dedicados, às vezes online, o que por 289definição não é aceitável para um relatório de segurança confidencial. Note 290que alguns clientes de e-mail tendem a corromper a formatação de texto simples 291por padrão; por favor, consulte Documentation/process/email-clients.rst para 292mais informações. 293 294Divulgação e informações sob embargo 295------------------------------------ 296 297A lista de segurança não é um canal de divulgação. Para isso, veja Coordenação 298abaixo. 299 300Assim que uma correção robusta for desenvolvida, o processo de lançamento é 301iniciado. Correções para bugs publicamente conhecidos são lançadas 302imediatamente. 303 304Embora nossa preferência seja lançar correções para bugs publicamente não 305divulgados assim que estiverem disponíveis, isso pode ser adiado a pedido do 306relator ou de uma parte afetada por até 7 dias corridos a partir do início do 307processo de lançamento, com uma extensão excepcional para 14 dias corridos se 308for acordado que a criticidade do bug exige mais tempo. O único motivo válido 309para adiar a publicação de uma correção é acomodar a logística de QA e as 310implantações em larga escala que exigem coordenação de lançamento. 311 312Embora as informações sob embargo possam ser compartilhadas com indivíduos de 313confiança para o desenvolvimento de uma correção, tais informações não serão 314publicadas juntamente com a correção ou em qualquer outro canal de divulgação 315sem a permissão do relator. Isso inclui, mas não se limita ao relatório de bug 316original e discussões de acompanhamento (se houver), exploits, informações de 317CVE ou a identidade do relator. 318 319Em outras palavras, nosso único interesse é fazer com que os bugs sejam 320corrigidos. Todas as outras informações enviadas à lista de segurança e 321quaisquer discussões de acompanhamento do relatório são tratadas de forma 322confidencial, mesmo após o término do embargo, perpetuamente. 323 324Coordenação com outros grupos 325----------------------------- 326 327Embora a equipe de segurança do kernel se concentre exclusivamente em corrigir 328bugs, outros grupos se concentram em corrigir problemas em distribuições e em 329coordenar a divulgação entre fornecedores de sistemas operacionais. A 330coordenação é geralmente tratada pela lista de discussão "linux-distros" e a 331divulgação pela lista pública "oss-security", ambas intimamente relacionadas 332e apresentadas na wiki da linux-distros: 333https://oss-security.openwall.org/wiki/mailing-lists/distros 334 335Por favor, note que as respectivas políticas e regras são diferentes, já que as 3363 listas buscam objetivos distintos. A coordenação entre a equipe de segurança 337do kernel e outras equipes é difícil porque para a equipe de segurança do 338kernel os embargos ocasionais (sujeitos a um número máximo de dias permitido) 339começam a partir da disponibilidade de uma correção, enquanto para a 340"linux-distros" eles começam a partir da postagem inicial na lista, 341independentemente da disponibilidade de uma correção. 342 343Como tal, a equipe de segurança do kernel recomenda fortemente que, como 344relator de um potencial problema de segurança, você NÃO contate a lista de 345discussão "linux-distros" ATÉ que uma correção seja aceita pelos mantenedores 346do código afetado e você tenha lido a página wiki das distribuições acima e 347compreendido totalmente os requisitos que o contato com a "linux-distros" 348imporá a você e à comunidade do kernel. Isso também significa que, em geral, 349não faz sentido colocar ambas as listas em Cc: ao mesmo tempo, exceto talvez 350para coordenação se e enquanto uma correção aceita ainda não tiver sido 351mesclada. Em outras palavras, até que uma correção seja aceita, não coloque 352em Cc: "linux-distros", e após ela ser mesclada, não coloque em Cc: a equipe 353de segurança do kernel. 354 355Atribuição de CVE 356----------------- 357 358A equipe de segurança não atribui CVEs, nem os exigimos para relatórios ou 359correções, pois isso pode complicar desnecessariamente o processo e adiar o 360tratamento do bug. Se um relator desejar que um identificador CVE seja 361atribuído para um problema confirmado, ele pode entrar em contato com a 362:doc:`kernel CVE assignment team<../../../process/cve>` para obter um. 363 364Acordo de não divulgação 365------------------------ 366 367A equipe de segurança do kernel Linux não é um órgão formal e, portanto, é 368incapaz de celebrar quaisquer acordos de não divulgação. 369