O Projeto Fedora está propondo uma série de mudanças para o Fedora 44 que visam tornar a segurança “de fábrica” mais robusta — o tipo de ajuste que dificulta a vida de malwares e exploits mesmo quando o usuário instala um driver antigo, ativa um repositório de terceiros ou executa um script duvidoso. Em bom português: trata-se de “defesa em profundidade” como padrão. A proposta está em análise pela FESCo e faz parte do processo oficial de Changes; se aprovada, alinha o Fedora às melhores práticas já vistas em outras distros. E, sim, isso conversa diretamente com o que muitos procuram como “Fedora 44 security”.
kernel.yama.ptrace_scope: paredes mais grossas entre os “apartamentos”
Pense nos processos do seu sistema como apartamentos de um prédio. O kernel.yama.ptrace_scope reforça as paredes entre esses apartamentos para que um vizinho mal-intencionado não consiga “espiar” ou injetar código no seu navegador, editor de textos ou gerenciador de senhas. Tecnicamente, ele restringe quem pode anexar depuradores (como gdb/strace) a processos alheios — uma proteção simples, mas eficaz, contra uma classe de ataques reais. Isso já é o padrão do kernel e de distros como Ubuntu e Arch; o Fedora, porém, vinha na contramão por um detalhe histórico curioso.
Qual detalhe? Um pacote chamado elfutils-default-yama-scope acabou se tornando dependência “acidental” de instalações padrão e desabilitava essa proteção a cada boot. A proposta corrige o rumo: obsoletar o pacote para restaurar o comportamento seguro e documentar para desenvolvedores como desativar a restrição somente quando necessário (por exemplo, durante uma sessão de depuração). É a diferença entre deixar a porta do prédio sempre destrancada “por conveniência” e manter a chave com o porteiro — quem realmente precisa entra, mas com controle.
kernel.kptr_restrict: tirando o “mapa do tesouro” das mãos do pirata
Exploradores de vulnerabilidades adoram mapas — no kernel, esses “mapas” são os endereços de memória. O kernel.kptr_restrict dificulta que esses endereços apareçam em interfaces como /proc, reduzindo a chance de um exploit saber exatamente onde mirar. Para você, usuário, o efeito é invisível; para quem tenta atacar, é como varrer a praia sem pista alguma de onde o baú foi enterrado. É uma camada a mais que, combinada a outras defesas (KASLR, políticas de logs etc.), eleva o custo do ataque e compra tempo até que correções cheguem.
net.core.bpf_jit_harden: blindagem extra no “canivete suíço” do kernel
O BPF é um canivete suíço poderoso dentro do Linux — fantástico para observabilidade e redes, mas também interessante para atacantes quando mal configurado. A opção net.core.bpf_jit_harden acrescenta blindagem ao compilador JIT do BPF, “ofuscando” valores imediatos e reduzindo a superfície para técnicas como JIT spraying. Pode haver um pequeno custo de desempenho em cenários específicos, mas para o uso comum ele tende a ser imperceptível. A proposta do Fedora é ligar essa proteção por padrão, buscando o nível mais alto que não sacrifique a usabilidade. Para o usuário final, a analogia é simples: é colocar um colete à prova de balas no canivete — ele continua útil, só fica mais difícil de ser usado contra você.
Na prática, o que muda para você? Quase nada no dia a dia — e isso é ótimo. O sistema ganha barreiras adicionais contra classes de ataques que exploram ptrace, exposição de kptr e o JIT do BPF, sem pedir que o usuário vire especialista em hardening. Quem desenvolve softwares de baixo nível ainda poderá depurar processos, mas fará isso de maneira consciente (desativando temporariamente uma proteção específica, com documentação clara). O quadro geral é de um Fedora mais resiliente por padrão, em linha com a experiência de outras distros e com a expectativa moderna de sistemas que “previnem antes de remediar”. A proposta está oficialmente registrada e em discussão na comunidade — etapa previsível do processo de Changes — e, se aprovada pela FESCo, aterrissa no ciclo do Fedora 44 como parte do esforço contínuo de fortalecer a segurança desde a instalação.
