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

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

Un proyecto de endurecimiento de Linux orientado a bloquear ataques de fuerza bruta contra cuentas y a reforzar los controles del kernel ha reavivado el debate sobre hasta qué punto los sistemas deberían restringir el acceso de root y funciones como kexec o los módulos del kernel sin firmar. Sus defensores ven estas medidas, junto con políticas SELinux y la firma de módulos, como defensa en profundidad esencial en máquinas modernas, mientras que los críticos temen que se esté “cociendo la rana” hacia bloqueos similares al DRM que debilitan el control del usuario y la usabilidad. Entre las preocupaciones relacionadas están la mejor manera de aislar navegadores y aplicaciones, lo prácticos que son las configuraciones seguras en el uso diario y si algunos de los ajustes recomendados están desfasados o aportan beneficios marginales.

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.