Endurecimiento del kernel: proteger las cuentas de usuario de Linux contra ataques de fuerza bruta

Artículo original ↗ Discusión en Hacker News ↗

Alcance del proyecto y relación con Qubes/Kicksecure

  • Los comentaristas señalan que el título es engañosamente limitado; el proyecto ofrece un endurecimiento más amplio que la protección contra fuerza bruta.
  • En Qubes OS, muchos usuarios usan indirectamente Kicksecure a través de Whonix, pero algunos sostienen que la principal protección de Qubes es la virtualización por hardware, y que Kicksecure es secundario.

Kexec, root y defensa en profundidad

  • Algunos argumentan que desactivar kexec no sirve de nada porque solo root puede usarlo, y limitar a root es algo parecido a un DRM que se cuela poco a poco.
  • Otros ven valor en desactivar kexec como una capa dentro de la defensa en profundidad, especialmente en combinación con SELinux, /dev/mem//dev/kmem limitados, /proc/kcore desactivado y restricciones de módulos.
  • Punto de contraargumento: impedir de verdad que root reactive kexec o parchee el kernel requiere políticas MAC extensas y decisiones en tiempo de compilación; de lo contrario, root aún puede modificar la memoria del kernel.

Secure Boot, módulos firmados y libertad del usuario

  • Un bando apoya permitir solo módulos del kernel firmados (opcionalmente, mediante secure boot) para una integridad más sólida.
  • Los críticos temen que esto evolucione hacia un bloqueo no opcional (ejemplos de Android, TPM y anti-cheat para juegos) y socave el control del usuario sobre su propio hardware.
  • Algunos señalan que las configuraciones endurecidas desactivan la carga de módulos después del arranque; otros objetan que impedir a los usuarios cargar su propio código en ring 0 es inaceptable.

Rol de root, sudo y SUID

  • Una minoría contundente sostiene que la existencia y el poder amplio de root es “mala seguridad” y debería minimizarse o dividirse en roles más estrechos (administración de red, instalación de software, etc.).
  • Modelo propuesto: eliminar o neutralizar root, evitar binarios SUID y usar en su lugar servicios privilegiados o binarios basados en capacidades.
  • Réplica: los administradores deben poder controlar completamente sus sistemas; convertir Linux en sistemas bloqueados al estilo iOS es algo ampliamente rechazado.
  • Algunos sugieren que un sudo cuidadosamente configurado junto con SELinux ya logra un control granular sin eliminar root.

SELinux: poder vs usabilidad

  • SELinux se cita como una forma madura de restringir incluso a root (por ejemplo, bloqueando la carga de módulos y kexec).
  • Las opiniones están divididas: algunos dicen que funciona bien en la práctica; otros lo ven complejo, mal documentado y como algo que la gente intenta principalmente “quitarse de encima”.

Sandboxing del navegador y aislamiento de aplicaciones

  • Se discuten múltiples enfoques: cuentas de usuario separadas, AppArmor, Firejail, flatpak/bubblewrap, contenedores (docker/podman), VMs al estilo Qubes o navegadores remotos.
  • Consenso: existen muchas herramientas para proteger el sistema del navegador; proteger por completo los datos del navegador frente a otros procesos de usuario es más difícil sin sandboxing a nivel de sistema.