Linux: O trade-off do kernel hardening

Tem uma fase inevitável na vida de quem usa Linux: em algum momento você descobre que existe um kernel “hardened”, lê meia dúzia de README falando sobre mitigação, superfície de ataque, lockdown, memória protegida e pronto. O kernel padrão começa a parecer irresponsável. Quase vulgar. Coisa de quem não se importa com segurança.

Só que segurança em Linux tem uma característica irritante: ela raramente melhora só porque você instalou algo com um nome mais sério.

Kernel hardening é um assunto real. Importante. Técnico. Em alguns cenários, necessário. Mas também é um daqueles temas que viram rapidamente uma espécie de “rice de segurança”: bonito no uname -a, triste no dia a dia quando o driver da NVIDIA para de carregar, o VirtualBox quebra, o BPF some, o debug fica esquisito e a pessoa descobre que “proteger o kernel” também pode custar a própria paciência.

A pergunta boa não é “kernel hardened é mais seguro?”. A pergunta boa é: mais seguro contra o quê, em qual máquina, com qual ameaça, pagando qual custo?

Eu uso kernel customizado no meu desktop. No meu caso, uso o linux-zen. E isso já é um bom ponto de partida para separar as coisas: o Zen não é um kernel de hardening. Ele existe muito mais no mundo de responsividade, desktop, baixa latência percebida e experiência interativa do que no mundo de defesa agressiva. Ou seja: kernel customizado não significa automaticamente “kernel mais seguro”. Às vezes significa só “quero meu desktop mais esperto”. E tudo bem. O problema começa quando a gente confunde ajuste de performance, filosofia de empacotamento, liberdade de software, tempo real e hardening como se tudo fosse a mesma categoria.

Não é.

Hardening é reduzir dano, não eliminar bug

Hardening, em sistemas operacionais, é o conjunto de práticas e mecanismos usados para reduzir superfície de ataque, dificultar exploração e limitar impacto quando alguma coisa dá errado. Isso pode envolver remover serviços desnecessários, restringir permissões, ativar políticas de acesso, compilar software com proteções extras ou configurar o kernel para vazar menos informação e aceitar menos comportamento perigoso por padrão.

No kernel Linux, hardening normalmente significa uma mistura de quatro coisas: proteções em tempo de compilação, parâmetros de boot, configurações em runtime via sysctl e políticas de segurança aplicadas por LSMs como SELinux, AppArmor, Yama e Landlock.

A parte importante é entender o que hardening não é. Hardening não corrige magicamente uma vulnerabilidade. Ele pode impedir que uma vulnerabilidade vire execução de código. Pode transformar uma exploração silenciosa em crash. Pode esconder endereços internos do kernel. Pode bloquear carregamento de módulo malicioso. Pode limitar quais syscalls um processo consegue usar. Mas o bug continua sendo bug.

Essa diferença parece detalhe acadêmico, mas não é. Uma vulnerabilidade é a falha. Um exploit é o uso prático dessa falha. Uma mitigação é uma barreira para atrapalhar o exploit. Redução de superfície de ataque é evitar que o caminho vulnerável esteja exposto em primeiro lugar.

Atualização de segurança corrige causa. Hardening reduz chance de desastre quando a causa ainda existe, ainda não foi corrigida, ainda não foi descoberta ou ainda está em algum driver esquecido que você carrega porque precisa que a placa de captura funcione.

Por que bug no kernel é pior

O kernel roda no espaço privilegiado do sistema. O user space é onde ficam seus processos comuns: navegador, terminal, editor, servidor web, banco de dados, container runtime. O kernel space é onde mora a parte que arbitra memória, processos, syscalls, drivers, rede, filesystems e acesso ao hardware.

O problema não é a chamada de sistema existir. O problema é quando uma falha nesse caminho deixa um processo comum atravessar a fronteira de privilégio.

Quando um processo comum falha, o estrago pode ser limitado ao usuário, ao serviço ou ao container. Quando o kernel falha do jeito errado, a conversa muda. Um bug explorável no kernel pode permitir escalonamento de privilégio, fuga de container, bypass de isolamento, leitura de memória sensível ou execução de código em ring 0.

Esse é o motivo pelo qual kernel hardening existe. Não é paranoia inventada por gente que compila Gentoo no porão. O kernel é a última fronteira entre um processo comprometido e o sistema inteiro. Se o atacante já está rodando código no user space, uma falha no kernel pode ser o caminho para virar dono da máquina.

Ao mesmo tempo, esse também é o motivo pelo qual hardening precisa ser tratado com cuidado. O kernel é uma peça central demais para ser trocada por superstição. Se você faz hardening sem entender, pode quebrar exatamente as partes que tornam o sistema administrável: observabilidade, debug, virtualização, módulos externos, hibernação, ferramentas de tracing e integração com hardware.

Segurança que ninguém consegue operar vira enfeite. Ou pior: vira motivo para desativar tudo depois, no susto, geralmente do jeito mais errado possível.

O Linux não começou “hardened”

O Linux nasceu como kernel generalista. O objetivo sempre foi rodar em muita coisa, suportar muito hardware, aceitar muitos casos de uso e manter um ecossistema enorme de drivers e arquiteturas. Segurança sempre importou, mas o kernel não começou com o mesmo conjunto de mitigations que hoje a gente considera normal.

Muita coisa que hoje parece óbvia foi amadurecendo ao longo de décadas. Projetos como PaX e grsecurity tiveram papel enorme em popularizar proteções de memória, randomização, restrições mais agressivas e uma visão mais defensiva do kernel. O grsecurity se define como uma extensão de segurança ao kernel Linux voltada a controle de acesso, prevenção de exploração baseada em corrupção de memória e hardening do sistema. O ponto histórico é: muitas ideias que hoje aparecem no debate mainstream de hardening foram testadas, defendidas ou pressionadas por esse ecossistema antes de chegarem ao kernel principal, quando chegaram.

Depois veio o Kernel Self Protection Project, que tenta levar proteções de autoproteção para o kernel upstream de forma incremental. Essa palavra, incremental, é importante. Kernel upstream não costuma aceitar um caminhão de patch agressivo só porque ele promete segurança. Precisa fazer sentido para manutenção, arquitetura, performance, compatibilidade e revisão por mantenedores. A segurança precisa sobreviver ao mundo real do Linux, que inclui desde servidor exposto na internet até notebook com GPU híbrida e usuário tentando rodar Steam, Docker e uma VPN duvidosa ao mesmo tempo (autodescrição).

LSMs também mudaram o jogo. SELinux, AppArmor, Yama e Landlock existem para permitir políticas de segurança além do modelo clássico de permissões Unix. Em vez de depender só de dono, grupo e modo do arquivo, você consegue impor regras mais específicas sobre o que um processo pode acessar, executar ou inspecionar.

E então vieram Spectre e Meltdown.

As vulnerabilidades de execução especulativa mudaram a conversa porque mostraram que a fronteira entre hardware, kernel e processo não era tão limpa quanto parecia. A mitigação contra Meltdown trouxe o Kernel Page Table Isolation, que separa tabelas de página do kernel e do user space para dificultar leitura indevida de memória privilegiada. Isso teve custo. Em alguns workloads, custo relevante. E serviu como lembrete: mitigação de segurança não é grátis só porque veio em update.

As proteções modernas são camadas, não uma muralha

Quando alguém fala “kernel hardened”, normalmente imagina uma entidade única, como se existisse um botão chamado security=true. Na prática, hardening é uma colcha de retalhos de mecanismos diferentes, cada um atacando uma classe de problema.

O KASLR randomiza o endereço base do kernel na memória a cada boot. Isso dificulta exploits que dependem de endereços previsíveis. Não torna exploração impossível, especialmente se houver vazamento de ponteiros, mas aumenta o trabalho do atacante.

O stack protector adiciona canários de pilha para detectar corrupção antes de uma função retornar. Se alguém tenta sobrescrever o endereço de retorno por meio de overflow, a alteração pode ser detectada e o kernel pode abortar em vez de continuar em um estado comprometido. O KSPP recomenda configurações como CONFIG_STACKPROTECTOR_STRONG justamente para ampliar essa cobertura.

SMEP e SMAP são recursos de CPU que impedem o kernel de executar ou acessar memória de user space de formas indevidas. Eles ajudam a bloquear técnicas clássicas em que o atacante tenta fazer o kernel pular para código controlado pelo usuário ou ler dados de uma região que não deveria ser confiável.

O KPTI, já citado, isola tabelas de página para mitigar Meltdown. É uma proteção importante, mas também é um bom exemplo de custo contextual: sistemas com muitas syscalls, muito I/O ou hardware antigo podem sentir mais.

Hardened usercopy “protege” as cópias entre kernel e user space. A ideia é evitar que falhas em operações como copy_to_user() e copy_from_user() virem leitura ou escrita fora dos limites esperados. Slab freelist randomization dificulta exploração de use-after-free ao tornar menos previsível a reutilização de objetos no alocador. init_on_alloc e init_on_free ajudam a reduzir exposição de dados residuais em memória, zerando memória em alocação ou liberação, com custos variáveis.

Lockdown mode tenta proteger a imagem do kernel em execução contra acesso direto ou indireto, especialmente em conjunto com Secure Boot. A man page do kernel lockdown deixa claro que a ideia é impedir modificações não autorizadas e acesso a dados sensíveis em memória do kernel. Só que isso vem com efeitos colaterais: interfaces de baixo nível, carregamento de certos módulos, acesso a memória física, kexec e algumas ferramentas de debug podem ser restringidos.

Assinatura de módulos é outra peça. A documentação oficial de module signing explica que o kernel pode verificar assinaturas criptográficas ao carregar módulos, recusando módulos não assinados ou assinados por chave inválida. Isso é ótimo para dificultar rootkits via módulo de kernel. Também é ótimo para fazer você lembrar que aquele módulo DKMS do VirtualBox, VMware, ZFS ou driver proprietário não vive no mundo ideal da documentação.

seccomp reduz a superfície de syscalls exposta a um processo. A documentação do kernel é bem direta: muitos processos têm acesso a syscalls que nunca usam; filtrar esse conjunto reduz a superfície do kernel disponível para aquela aplicação. Mas a própria documentação avisa que seccomp não é sandbox completo. Ele é uma ferramenta para construtores de sandbox. A política de comportamento, fluxo de informação e isolamento precisa vir junto com outras camadas.

Landlock é outro caso interessante porque permite que processos não privilegiados imponham restrições de acesso a si mesmos. A documentação do Landlock fala em scoped access control, ou seja, controle de acesso limitado por escopo. Isso é útil para aplicações que querem se confinar sem depender de privilégio administrativo. Mas, de novo, é camada. Não é varinha.

E tem o mundo dos sysctl: kernel.dmesg_restrict, kernel.kptr_restrict, kernel.yama.ptrace_scope, kernel.unprivileged_bpf_disabled, kernel.modules_disabled. Algumas dessas opções são relativamente tranquilas para muitos ambientes. Outras podem quebrar debug, observabilidade, tracing, eBPF, desenvolvimento, carregamento de driver e até fluxos normais de administração.

O detalhe que muita gente ignora é que hardening pode acontecer em lugares diferentes. Uma coisa é compilar o kernel com CONFIG_STRICT_KERNEL_RWX. Outra é passar parâmetro de boot. Outra é ajustar sysctl. Outra é ativar SELinux enforcing. Outra é usar perfil seccomp em container. Outra é assinar módulos. Outra é configurar systemd para restringir serviço. Tratar tudo isso como “instalar kernel hardened” é simplificar demais.

Hardening não é uma muralha única. É uma pilha de mecanismos que dificultam exploração, reduzem superfície ou limitam impacto.

O kernel da sua distro provavelmente não é tão pelado quanto você imagina

Existe uma ideia meio torta de que o kernel padrão da distribuição é um kernel “sem segurança”, e o kernel hardened é o único adulto na sala. Isso era mais defensável anos atrás. Hoje, muitas distribuições já carregam um conjunto decente de mitigations.

O Ubuntu, por exemplo, documenta proteções como restrição de dmesg, kptr_restrict, KASLR, lockdown com Secure Boot, stack protector, seções read-only e Module RO/NX na sua página de kernel protections. Fedora e RHEL historicamente apostam forte em SELinux. openSUSE e Ubuntu usam AppArmor como parte importante da política de confinamento. Debian costuma ser mais conservador, mas também herda muitas proteções upstream e oferece AppArmor. Alpine tende a ser minimalista, e Gentoo permite um nível enorme de customização, embora o antigo caminho baseado em grsecurity público tenha mudado depois da restrição de acesso aos patches.

Isso não significa que todas as distros são igualmente protegidas. Não são. Arch, por exemplo, tende a entregar mais responsabilidade para o usuário. É uma das coisas boas e ruins do Arch ao mesmo tempo. Você ganha controle, mas também ganha o direito sagrado de se cortar com a própria faca.

O ponto é que trocar para um kernel hardened sem olhar o restante do sistema pode ser uma solução cosmética. Se o seu SSH aceita senha fraca, se o painel administrativo está exposto sem autenticação decente, se o Docker está rodando container privilegiado com volume do host montado em /, se você instala qualquer coisa do AUR sem ler PKGBUILD, o problema talvez não seja falta de KASLR espiritual.

Inclusive, depois de escrever sobre pacotes comprometidos no AUR, fica difícil não olhar para esse tema com certo ceticismo. Muita gente quer fazer hardening no kernel, mas continua tratando script de build aleatório como se fosse pacote oficial assinado por uma entidade benevolente. Segurança não funciona por estética. Não adianta colocar fechadura biométrica na porta e deixar a janela aberta com uma placa “entre, por favor”.

Variantes de kernel não resolvem o mesmo problema

O kernel mainline, ou vanilla, é o kernel oficial vindo do upstream. Ele é a base. O kernel da distribuição é essa base com escolhas de configuração, backports, patches, suporte e política própria. O kernel LTS prioriza estabilidade e manutenção prolongada. Para produção, isso costuma ser mais interessante do que correr atrás do kernel mais novo só porque saiu ontem e alguém no fórum disse que ficou “mais fluido”.

O linux-hardened é outra categoria. O projeto linux-hardened se apresenta como um suplemento mínimo às mudanças do Kernel Self Protection Project, sem tentar substituir SELinux ou Yama. Ele busca adicionar ou ajustar hardenings que ainda não estão no upstream do jeito desejado. É mais restritivo, e isso é justamente a proposta. Para alguns cenários, faz sentido. Para outros, é só a forma mais elegante de descobrir que hibernação, módulo externo ou ferramenta de tracing não gostou da sua nova personalidade.

grsecurity/PaX é o elefante histórico na sala. Foi uma das iniciativas mais influentes em hardening de kernel Linux, com proteções agressivas e uma postura técnica que pressionou o ecossistema por anos. Também é um projeto envolto em controvérsias, especialmente por causa de disponibilidade, licenciamento, relação com upstream e a mudança para acesso mais restrito. Ele não é simplesmente “o kernel mais seguro que você instala no domingo”. É uma escolha de nicho, com implicações de suporte, custo e manutenção.

Zen, Liquorix e XanMod estão em outra conversa. O Liquorix se descreve como um kernel voltado a responsividade em sistemas interativos, baixa latência em produção audiovisual e redução de variação em jogos. O XanMod se apresenta como um kernel de uso geral com configurações customizadas para uma experiência estável, suave e responsiva. O Zen segue essa linha de desktop e interatividade. Eu uso Zen porque, no meu caso, faz sentido para desktop. Não porque eu ache que ele transforma meu sistema em bunker.

PREEMPT_RT também não é “kernel seguro”. É kernel para tempo real. O objetivo é latência previsível, não hardening contra exploit. Ele importa em áudio profissional, automação, indústria, sistemas embarcados e cenários em que previsibilidade temporal é requisito. Usar RT achando que é hardening é o equivalente técnico de instalar pneu de corrida para melhorar a fechadura da garagem.

Linux-libre também é outra discussão. Ele remove blobs e firmware não livre. Isso é uma posição de liberdade de software, não uma garantia automática de segurança. Pode até reduzir dependência de código opaco em alguns contextos, mas também pode deixar hardware sem funcionar ou empurrar o usuário para gambiarras piores. De novo: trade-off.

Kernels de cloud providers são ainda outra categoria. Eles costumam ser otimizados para o ambiente do provedor, com drivers, integração e escolhas adequadas à infraestrutura daquela nuvem. Em VPS, muitas vezes você nem controla o kernel real do jeito que imagina. Em bare metal, controla mais, mas também assume mais responsabilidade. Em Android, a comparação é útil para lembrar que “Linux kernel” pode significar um mundo bem diferente quando entra vendor tree, SELinux obrigatório, drivers específicos e ciclo de atualização de fabricante.

O nome do kernel não é a política de segurança. É só uma parte dela.

Algumas variantes compram suporte previsível, outras responsividade, outras restrição, outras uma posição filosófica. Misturar tudo como “mais seguro” atrapalha a decisão.

O custo aparece onde dói

Hardening quase sempre cobra alguma coisa. Às vezes cobra pouco. Às vezes cobra muito. Às vezes cobra só quando você mais precisa que algo funcione.

KASLR tem custo baixo, mas pode ser enfraquecido por vazamento de ponteiros. Stack protector tem overhead geralmente aceitável, mas ainda é trabalho extra. KPTI pode pesar mais em workloads com muita transição user/kernel. Mitigações de Spectre variam muito conforme CPU, microcódigo e workload. LSMs fazem checagens adicionais. seccomp executa filtro. Inicialização e limpeza de memória reduzem risco de dado residual, mas não são de graça. Auditoria demais pode virar gargalo. Lockdown pode bloquear ferramentas legítimas.

E benchmark de kernel é um campo minado. O resultado depende de CPU, scheduler, filesystem, I/O, versão do compilador, flags, mitigations ativas, microcódigo, firmware, workload e distribuição. Dizer “kernel hardened é sempre mais lento” é preguiça. Dizer “não muda nada” também é.

O jeito correto de pensar é: qual é o workload e qual é o risco?

Um servidor público com serviço exposto, dados sensíveis e pouca necessidade de módulo externo tem um perfil. Um notebook com GPU híbrida, hibernação, Docker, OBS, Wine, Steam, VirtualBox e vontade de viver tem outro. Uma máquina de desenvolvimento precisa de debug, tracing, perf, bpftrace, ptrace e liberdade para quebrar coisa localmente. Um cluster Kubernetes precisa se preocupar com host kernel, container runtime, seccomp profile, capabilities, AppArmor/SELinux, user namespaces e políticas de pod. Um homelab exposto por Cloudflare Tunnel com senha fraca no painel web precisa talvez menos de kernel custom e mais de vergonha na cara operacional.

Segurança é sempre contexto. Quem vende resposta universal normalmente está vendendo ansiedade.

Containers não salvam você do kernel

Containers são um ponto delicado porque muita gente fala deles como se fossem VMs leves. Não são. Containers compartilham o kernel do host. Namespaces, cgroups, capabilities e seccomp ajudam a construir isolamento, mas a fronteira final continua sendo o kernel.

O container reduz e organiza isolamento, mas não troca o kernel por máquina. Por isso uma falha explorável no kernel do host continua sendo assunto sério.

Isso significa que hardening no host importa muito em ambientes com containers. Também significa que features que reduzem privilégio podem aumentar superfície de ataque em outro lugar. User namespaces, por exemplo, são úteis para isolamento sem privilégio real no host, mas também expõem caminhos de kernel que historicamente renderam vulnerabilidades. Não é argumento para “desativar tudo sempre”. É argumento para parar de fingir que uma feature é puramente boa só porque aparece em palestra de segurança.

No Kubernetes, a conversa fica mais séria. Não basta trocar kernel. É preciso olhar capabilities, containers privilegiados, mounts do host, perfis seccomp, AppArmor/SELinux, runtime, atualização do node, política de admissão, imagens e segredos. Um kernel mais protegido ajuda, mas não conserta cluster mal configurado.

Aliás, quase nada conserta cluster mal configurado. Talvez terapia.

O que eu recomendaria sem vender milagre

Para desktop comum, eu não começaria por kernel hardened. Começaria por manter o sistema atualizado, usar navegador atualizado, evitar instalar qualquer pacote aleatório, revisar permissões, ter backup, usar full disk encryption quando fizer sentido, não rodar serviço desnecessário e entender o que está exposto. Um kernel padrão bem mantido da distro, com mitigations modernas, costuma ser uma escolha mais equilibrada do que um kernel restritivo que você vai abandonar na primeira quebra.

Para desktop técnico, como o meu, um kernel customizado pode fazer sentido por performance, responsividade ou curiosidade. Por isso uso Zen. Mas eu não finjo que isso é uma política de segurança. É uma escolha de experiência. Se eu quisesse hardening real, teria que olhar para sysctl, LSM, Secure Boot, módulos, BPF, serviços, sandboxing e fluxo de atualização. Só trocar o pacote do kernel seria teatro.

Para servidor público, a conversa muda. Aí faz sentido considerar SELinux ou AppArmor bem configurado, dmesg_restrict, kptr_restrict, restrição de BPF não privilegiado, seccomp em serviços, redução de capabilities, firewall decente, atualizações rápidas, menos módulos, menos serviços, menos superfície exposta. Um kernel LTS da distro pode ser melhor do que um kernel alternativo se ele recebe backport de segurança e suporte previsível. Em alguns casos, linux-hardened ou grsecurity comercial podem fazer sentido, mas isso precisa vir com teste, monitoramento e plano de manutenção.

Para máquina de desenvolvimento, agressividade demais atrapalha. ptrace_scope restritivo pode interferir em debug. Lockdown pode atrapalhar tracing. BPF restrito pode quebrar observabilidade. SELinux enforcing sem entender política pode virar caça-fantasma. Ambiente de desenvolvimento precisa ser seguro, mas também precisa deixar o desenvolvedor trabalhar. Parece óbvio. Muita política interna consegue errar isso com convicção.

Para homelab, o risco geralmente está menos no kernel e mais no entusiasmo. A pessoa sobe vinte serviços, expõe cinco, usa compose copiado do GitHub, não atualiza imagem, deixa painel sem autenticação forte e depois quer discutir slab allocator. Calma. Primeiro fecha porta, atualiza serviço, separa rede, usa backup e para de montar /var/run/docker.sock em container que você baixou porque o README era bonito.

Para ambiente corporativo, kernel hardening é decisão de governança. Precisa de inventário, homologação, matriz de compatibilidade, suporte de vendor, observabilidade, resposta a incidente, política de atualização e exceções documentadas. Segurança corporativa que só manda “ativem tudo” sem entender o impacto vira fábrica de bypass.

Alguns ajustes simples fazem sentido, mas ainda precisam de contexto

Existem configurações que, em muitos sistemas, são boas candidatas a baseline. Restringir dmesg para usuários sem privilégio reduz vazamento de informação útil para exploração. Restringir ponteiros de kernel em interfaces como /proc também. Bloquear BPF não privilegiado pode fazer sentido em servidor. Usar seccomp em serviços e containers é uma prática bem razoável. Reduzir capabilities em containers deveria ser rotina, não diferencial.

Um exemplo de checagem simples é olhar as mitigações de CPU expostas pelo próprio kernel:

grep . /sys/devices/system/cpu/vulnerabilities/*

Isso não “mede segurança”, mas mostra o estado de algumas mitigações relevantes para falhas de CPU conhecidas. Também é útil verificar alguns sysctls básicos:

sysctl kernel.dmesg_restrict
sysctl kernel.kptr_restrict
sysctl kernel.yama.ptrace_scope
sysctl kernel.unprivileged_bpf_disabled

O problema é transformar isso em checklist cego. kernel.yama.ptrace_scope=1 pode ser ótimo para restringir inspeção entre processos, mas pode incomodar debug. kernel.unprivileged_bpf_disabled=1 pode reduzir superfície de ataque, mas pode afetar ferramentas que dependem de eBPF. kernel.modules_disabled=1 é forte, mas depois disso você não carrega mais módulo nenhum até reboot. Isso pode ser excelente em appliance fechado. Pode ser péssimo em desktop.

Não existe configuração “segura para todo mundo” sem a frase seguinte: segura para qual uso?

A polêmica grsecurity vs upstream não é só fofoca de kernel

A história do grsecurity é importante porque expõe uma tensão real no Linux: segurança agressiva fora da árvore versus segurança incremental no upstream.

Do lado de quem defende patches externos, o argumento é que upstream costuma ser lento, conservador e preocupado demais com compatibilidade. Em segurança, esperar consenso perfeito pode significar deixar classes inteiras de exploração viáveis por anos. PaX/grsecurity mostraram que dava para ir além do padrão.

Do lado upstream, o argumento é que patch massivo, difícil de revisar e manter, pode virar dívida técnica séria. Uma mitigação precisa funcionar em arquiteturas diferentes, com drivers diferentes, sem quebrar subsistemas obscuros e sem criar comportamento impossível de suportar. Segurança que não entra no fluxo normal de manutenção pode ficar presa ao mantenedor externo. Quando esse mantenedor muda acesso, licença ou disponibilidade, a distro fica sem chão. O caso do antigo hardened-sources no Gentoo é um exemplo clássico dessa fragilidade.

A conclusão chata é que os dois lados têm pontos válidos. Patches externos pressionam inovação. Upstream dá escala, manutenção e revisão. O ideal é que boas ideias sejam incorporadas ao kernel principal de forma sustentável. Só que esse caminho costuma ser lento, político e cheio de bikeshed técnico. Bem-vindo ao software livre em infraestrutura crítica: lindo, caótico e com thread de mailing list que parece julgamento medieval.

Hardening real começa antes do kernel

A parte menos glamourosa é a mais importante: muitas vezes o problema real não está no kernel.

Está no serviço exposto sem necessidade. Na senha fraca. No painel administrativo aberto para a internet. No container privilegiado. No bucket público. No token em .env commitado. No pacote do AUR instalado sem leitura. No script curl | bash. No servidor que não atualiza porque “se mexer, quebra”. No Docker socket montado em container de dashboard. No Redis ouvindo em interface pública. No WordPress abandonado. No SSH liberado com senha porque “é só temporário”, e todo mundo sabe que temporário em infraestrutura significa “até o incidente”.

Kernel hardening é camada de defesa. Camada boa, às vezes essencial. Mas camada. Se o resto do sistema é uma peneira, fazer hardening pode até ajudar quando tudo der errado, mas não transforma peneira em cofre.

Isso não diminui a importância do tema. Pelo contrário. Coloca no lugar certo.

Então vale usar kernel hardened?

Depende. E “depende” aqui não é fuga. É a única resposta tecnicamente honesta.

Faz sentido considerar um kernel hardened quando você tem ameaça realista envolvendo execução de código não confiável, multiusuário, containers, serviços expostos, ambiente sensível, requisito de compliance, risco de escalonamento local ou necessidade de reduzir ao máximo a superfície do kernel. Faz ainda mais sentido quando você consegue testar, monitorar e manter esse kernel sem depender de improviso.

Também faz sentido proteger partes do sistema sem trocar o kernel inteiro: ativar e configurar LSM, restringir sysctl, usar Secure Boot com módulo assinado, aplicar seccomp, reduzir capabilities, remover módulos desnecessários, usar kernel LTS bem mantido e manter atualização em dia. Em muitos casos, isso entrega mais segurança prática do que trocar para um kernel alternativo e não entender o que mudou.

É melhor evitar kernel hardened quando você depende de drivers proprietários sensíveis, DKMS, VirtualBox, VMware, ZFS fora da árvore, ferramentas pesadas de observabilidade, desenvolvimento com debug frequente, hibernação, hardware exótico ou simplesmente não tem tempo para diagnosticar quebra pós-update. Nesses casos, o kernel padrão da distribuição pode ser a escolha mais segura no sentido operacional da palavra. Segurança também é conseguir atualizar sem medo.

Para desktop comum, eu tenderia a ser conservador. Para servidor exposto, eu tenderia a proteger mais, mas começando pela configuração do sistema e dos serviços. Para homelab, eu olharia primeiro para o que está exposto. Para ambiente corporativo, eu exigiria teste e política. Para máquina de desenvolvimento, eu não sacrificaria debug em nome de uma ameaça abstrata que talvez nem esteja no modelo.

Kernel hardening é decisão séria de segurança quando nasce de ameaça, contexto e operação. Quando nasce só de estética, vira só mais uma forma elegante de quebrar driver, debug e virtualização.

E Linux já dá trabalho suficiente sem a gente transformar ansiedade em parâmetro de boot.