Fortalecimento do Kernel: Proteja contas de usuários Linux contra ataques de força bruta

Escopo do Projeto e Relação com Qubes/Kicksecure

• Os comentaristas observam que o título é enganosamente restrito; o projeto oferece um fortalecimento mais amplo além da proteção contra força bruta.
• No Qubes OS, muitos usuários usam o Kicksecure indiretamente por meio do Whonix, mas alguns argumentam que a principal proteção do Qubes é a virtualização por hardware, com o Kicksecure sendo secundário.

Kexec, Root e Defesa em Profundidade

• Alguns argumentam que desativar kexec é inútil porque apenas root pode usá-lo, e limitar root é semelhante a uma DRM por infiltração.
• Outros veem valor em desativar kexec como uma camada em defesa em profundidade, especialmente em combinação com SELinux, /dev/mem//dev/kmem limitados, /proc/kcore desativado e restrições a módulos.
• Contra-argumento: impedir de fato que root reative kexec ou aplique patches ao kernel exige políticas MAC extensas e escolhas em tempo de compilação; caso contrário, root ainda pode modificar a memória do kernel.

Secure Boot, Módulos Assinados e Liberdade do Usuário

• Um lado apoia permitir apenas módulos do kernel assinados (opcionalmente, via secure boot) para maior integridade.
• Críticos temem que isso evolua para um bloqueio não opcional (exemplos de Android, TPM, anti-cheat de jogos) e prejudique o controle do usuário sobre seu próprio hardware.
• Alguns observam que configurações fortalecidas desativam o carregamento de módulos após a inicialização; outros objetam que impedir os usuários de carregar seu próprio código em ring 0 é inaceitável.

Papel do Root, sudo e suid

• Uma minoria forte argumenta que a existência e o amplo poder do root é “má segurança” e deveria ser minimizada ou dividida em papéis mais restritos (administração de rede, instalação de software etc.).
• Modelo proposto: remover ou enfraquecer o root, evitar binários suid e usar serviços privilegiados ou binários baseados em capabilities em vez disso.
• Reação contrária: administradores devem poder controlar totalmente seus sistemas; transformar Linux em sistemas bloqueados, estilo iOS, é amplamente rejeitado.
• Alguns sugerem que sudo cuidadosamente configurado mais SELinux já alcança controle granular sem remover o root.

SELinux: Poder vs Usabilidade

• SELinux é citado como uma forma madura de restringir até mesmo o root (por exemplo, bloqueando carregamento de módulos, kexec).
• As opiniões divergem: alguns dizem que funciona bem na prática; outros o veem como complexo, mal documentado e algo que as pessoas principalmente tentam “tirar do caminho”.

Sandboxing de Navegadores e Isolamento de Aplicações

• Várias abordagens são discutidas: contas de usuário separadas, AppArmor, Firejail, flatpak/bubblewrap, contêineres (docker/podman), VMs no estilo Qubes ou navegadores remotos.
• Consenso: existem muitas ferramentas para proteger o sistema contra o navegador; proteger totalmente os dados do navegador contra outros processos de usuário é mais difícil sem sandboxing em todo o sistema.