{"id":170830,"date":"2026-05-16T18:24:39","date_gmt":"2026-05-16T16:24:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux"},"modified":"2026-05-16T18:24:39","modified_gmt":"2026-05-16T16:24:39","slug":"model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","title":{"rendered":"Modelo de amea\u00e7as e caracter\u00edsticas da avalia\u00e7\u00e3o de vulnerabilidades no kernel Linux","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds aceitou um documento que regula o processo de tratamento de erros relacionados \u00e0 seguran\u00e7a no n\u00facleo, que define o modelo de amea\u00e7as, esclarecendo quais erros no n\u00facleo s\u00e3o considerados vulnerabilidades, e discute as a\u00e7\u00f5es a serem tomadas em rela\u00e7\u00e3o aos erros identificados com a ajuda da IA. O documento foi preparado por Willy Tarreau, autor do HAProxy e desenvolvedor veterano do n\u00facleo Linux, respons\u00e1vel pela manuten\u00e7\u00e3o de v\u00e1rios ramos est\u00e1veis do n\u00facleo. As bases foram estabelecidas a partir de acordos alcan\u00e7ados durante a discuss\u00e3o de vulnerabilidades cr\u00edticas recentemente identificadas no n\u00facleo (1, 2, 3, 4), reveladas antes da publica\u00e7\u00e3o das corre\u00e7\u00f5es e para as quais, gra\u00e7as \u00e0 IA, foi poss\u00edvel criar exploits funcionais imediatamente. <\/p>\n
A maioria dos erros relacionados \u00e0 seguran\u00e7a deve ser tratada publicamente, a fim de atrair a maior audi\u00eancia poss\u00edvel e encontrar a solu\u00e7\u00e3o otimizada. Apenas mensagens de urg\u00eancia sobre vulnerabilidades facilmente explor\u00e1veis, que representam uma amea\u00e7a para muitos usu\u00e1rios e permitem a obten\u00e7\u00e3o de privil\u00e9gios ou capacidades expandidas, s\u00e3o sugeridas para serem enviadas a uma lista de distribui\u00e7\u00e3o privada. <\/p>\n
As vulnerabilidades identificadas por assistentes de IA devem ser discutidas publicamente, uma vez que tais problemas frequentemente s\u00e3o descobertos simultaneamente por v\u00e1rios pesquisadores. No entanto, n\u00e3o se deve revelar o exploit no relat\u00f3rio \u2014 basta mencionar que ele est\u00e1 dispon\u00edvel e entreg\u00e1-lo em particular em resposta a um pedido do respons\u00e1vel. <\/p>\n
Regras para a transmiss\u00e3o de relat\u00f3rios gerados com a ajuda de assistentes de IA s\u00e3o descritas separadamente. Muitos relat\u00f3rios desse tipo s\u00e3o enviados e, gra\u00e7as a eles, \u00e9 poss\u00edvel identificar erros em partes do c\u00f3digo que n\u00e3o foram bem revisadas, mas os respons\u00e1veis frequentemente os ignoram devido \u00e0 baixa qualidade e imprecis\u00f5es. Os principais requisitos para os relat\u00f3rios gerados com assistentes de IA s\u00e3o: <\/p>\n
\n
Breviedade, sem rodeios e com \u00eanfase na ess\u00eancia e detalhes importantes logo no in\u00edcio.\n
Apenas texto puro sem tags Markdown ou decora\u00e7\u00e3o.\n
Compreender o modelo de amea\u00e7as e indicar fatos verific\u00e1veis (por exemplo, \"o erro permite que qualquer usu\u00e1rio obtenha CAP_NET_ADMIN\"), e n\u00e3o especula\u00e7\u00f5es te\u00f3ricas sobre as consequ\u00eancias da vulnerabilidade.\n
Antes de enviar o relat\u00f3rio, \u00e9 essencial testar cuidadosamente a funcionalidade do exploit gerado pelo AI e garantir que o problema possa ser reproduzido.\n
Utilizando AI para desenvolver e testar corre\u00e7\u00f5es para o problema identificado. <\/ul>\n
Estat\u00edsticas de acompanhamentos indicam que a maioria dos relat\u00f3rios de erros enviados como se fossem corre\u00e7\u00f5es de vulnerabilidades n\u00e3o s\u00e3o, e devem ser tratados como erros comuns. Para diferenciar vulnerabilidades de erros comuns, um modelo de amea\u00e7a foi descrito no n\u00facleo do Linux. Entre as possibilidades e garantias cuja viola\u00e7\u00e3o pode ser considerada uma vulnerabilidade: <\/p>\n
\n
Isolamento em n\u00edvel de usu\u00e1rio: acesso a arquivos restrito ao propriet\u00e1rio, a mem\u00f3ria do processo n\u00e3o acess\u00edvel a outros usu\u00e1rios, ptrace proibido para processos de outros, e isolamento IPC e comunica\u00e7\u00f5es de rede.\n
Prote\u00e7\u00e3o baseada em capacidades: sem CAP_SYS_ADMIN n\u00e3o \u00e9 poss\u00edvel alterar a configura\u00e7\u00e3o do n\u00facleo, a mem\u00f3ria, ou o estado do sistema; sem CAP_NET_ADMIN n\u00e3o \u00e9 permitido alterar configura\u00e7\u00f5es de rede ou interceptar tr\u00e1fego; sem CAP_SYS_PTRACE n\u00e3o \u00e9 poss\u00edvel monitorar processos de outros usu\u00e1rios.\n
O namespace de identificadores de usu\u00e1rios (CONFIG_USER_NS) permite que usu\u00e1rios n\u00e3o privilegiados criem seus pr\u00f3prios ambientes isolados, que n\u00e3o podem impactar o espa\u00e7o de nome global, por exemplo, mudando a hora, carregando m\u00f3dulos ou montando dispositivos blocos.\n
Interfaces de depura\u00e7\u00e3o (\/proc\/kmsg, perf, debugfs), atrav\u00e9s das quais \u00e9 poss\u00edvel acessar informa\u00e7\u00f5es confidenciais, est\u00e3o dispon\u00edveis apenas ap\u00f3s a concess\u00e3o expl\u00edcita de acesso pelo administrador. <\/ul>\n
Capacidades que n\u00e3o s\u00e3o consideradas vulnerabilidades: <\/p>\n
\n
Uso de vers\u00f5es desatualizadas do n\u00facleo.\n
Compila\u00e7\u00e3o com op\u00e7\u00f5es para desenvolvedores ou que diminuem a seguran\u00e7a (por exemplo, CONFIG_NOMMU).\n
Defini\u00e7\u00e3o de configura\u00e7\u00f5es sysctl inseguras, op\u00e7\u00f5es de linha de comando, permiss\u00f5es no sistema de arquivos, capacidades ou fornecimento de acesso a interfaces privilegiadas para usu\u00e1rios n\u00e3o privilegiados (por exemplo, acesso de grava\u00e7\u00e3o ao procfs e debugfs).\n
Problemas em fun\u00e7\u00f5es destinadas apenas para desenvolvimento e depura\u00e7\u00e3o do n\u00facleo, como LOCKDEP, KASAN e FAULT_INJECTION, que n\u00e3o devem ser inclu\u00eddas em configura\u00e7\u00f5es de produ\u00e7\u00e3o.\n
Problemas em drivers, m\u00f3dulos e subsystems que est\u00e3o na se\u00e7\u00e3o STAGING ou marcados como experimentais, inseguros ou n\u00e3o funcionais.\n
Uso de m\u00f3dulos de kernel de terceiros ou forks n\u00e3o oficiais do kernel.\n
Exig\u00eancia de privil\u00e9gios excessivos, como a necessidade de executar a\u00e7\u00f5es com direitos de root ou de um usu\u00e1rio com direitos de CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO e CAP_SYS_MODULE.\n
Ataques te\u00f3ricos que requerem condi\u00e7\u00f5es de laborat\u00f3rio, bilh\u00f5es de tentativas, emula\u00e7\u00e3o ou modifica\u00e7\u00e3o de hardware, custos desproporcionais e configura\u00e7\u00f5es irreais (por exemplo, sistemas com dezenas de milhares de n\u00facleos de CPU).\n
Contornar mecanismos de prote\u00e7\u00e3o (por exemplo, ASLR) sem demonstra\u00e7\u00e3o de exploit. Aus\u00eancia de verifica\u00e7\u00f5es de argumentos e c\u00f3digos de erro retornados que n\u00e3o t\u00eam consequ\u00eancias claras.\n
Vazamentos de informa\u00e7\u00f5es acidentais, fora do controle dos atacantes, como dados remanescentes em mensagens de erro e vazamentos de endere\u00e7os\/pontadores para a mem\u00f3ria do kernel sem uma possibilidade direta de explora\u00e7\u00e3o.\n
Erros na montagem de imagens de disco corrompidas, se o driver n\u00e3o for declarado como apropriado para uso com m\u00eddias n\u00e3o confi\u00e1veis. Problemas com imagens de disco que s\u00e3o detectados e resolvidos atrav\u00e9s da execu\u00e7\u00e3o da ferramenta fsck.\n
Ataques que requerem acesso f\u00edsico ao hardware, modifica\u00e7\u00e3o de hardware ou conex\u00e3o de dispositivos de hardware, como placas para ataque por DMA e analisadores l\u00f3gicos, se o sistema n\u00e3o estiver especificamente configurado para prote\u00e7\u00e3o contra tais ataques (IOMMU).\n
Regress\u00f5es de funcionalidade e desempenho que podem ser corrigidas ajustando permiss\u00f5es e limites. <\/ul>\n