Seguridad Linux Kernel Lockdown LSMs 2025

La seguridad del kernel de Linux ha evolucionado de forma drástica en los últimos años. Ya no basta con endurecer servicios o aplicar cortafuegos; el núcleo mismo del sistema operativo debe estar protegido contra accesos no autorizados, modificaciones en caliente y exploits que busquen escalar privilegios. Dos de las tecnologías más relevantes en este ámbito son Kernel Lockdown y los Linux Security Modules (LSMs) como SELinux y AppArmor. En este artículo exploraremos en profundidad cómo funcionan, cómo se complementan y cómo implementarlas para lograr un hardening Linux de nivel experto.

¿Qué es Kernel Lockdown y por qué es crítico?

Kernel Lockdown es un mecanismo de seguridad introducido en el kernel Linux 5.4 que restringe ciertas operaciones privilegiadas incluso para el usuario root. Su objetivo principal es evitar que un atacante con acceso root pueda:

Modificar la memoria del kernel en caliente (kprobes, ftrace).
Acceder a /dev/mem o /dev/kmem.
Cargar módulos del kernel sin firmar.
Alterar tablas de interrupciones o la tabla de descriptores globales.

En esencia, Lockdown convierte al kernel en un “objeto de confianza” que no puede ser manipulado ni siquiera por el administrador del sistema. Esto es fundamental cuando se trabaja con Trusted Platform Module (TPM) y arranque verificado (UEFI Secure Boot).

[INFO] Kernel Lockdown no es un LSM, sino una capa de restricción adicional que puede funcionar junto con SELinux o AppArmor. Se activa mediante el parámetro de arranque lockdown=confidentiality o lockdown=integrity.

Modos de Lockdown

integrity: Impide la modificación del kernel en ejecución y la carga de módulos sin firmar. Permite la mayoría de operaciones de lectura.
confidentiality: Modo más estricto. Además de lo anterior, bloquea el acceso a información confidencial del kernel (como claves criptográficas almacenadas en memoria).

Para activarlo, añade al gestor de arranque (GRUB):

GRUB_CMDLINE_LINUX="lockdown=confidentiality"

Y luego actualiza:

sudo update-grub

Verifica el estado con:

cat /sys/kernel/security/lockdown

Linux Security Modules (LSMs): El corazón del control de acceso

Los LSMs son un framework que permite implementar políticas de seguridad sin modificar el kernel principal. Los más conocidos son SELinux (Security-Enhanced Linux) y AppArmor. Ambos ofrecen control de acceso obligatorio (MAC), pero difieren en su filosofía y complejidad.

SELinux: Control granular y etiquetado

SELinux asocia a cada proceso, archivo, socket y dispositivo un contexto de seguridad compuesto por usuario, rol, tipo y nivel. Las políticas definen qué transiciones están permitidas entre contextos.

Ventajas: Altamente granular, ideal para entornos multinivel (MLS) y certificaciones gubernamentales.
Desventajas: Curva de aprendizaje pronunciada, puede romper aplicaciones si no se configura correctamente.

Ejemplo de contexto SELinux:

ls -Z /etc/shadow
system_u:object_r:shadow_t:s0

Para cambiar el modo de SELinux (enforcing, permissive, disabled):

sudo setenforce 1   # Enforcing
sudo setenforce 0   # Permissive

Para hacerlo permanente, edita /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

[WARNING] Nunca pases de enforcing a disabled sin reiniciar. Puedes dejarlo en permissive primero para auditar.

AppArmor: Perfiles por aplicación y facilidad de uso

AppArmor utiliza perfiles que definen qué recursos puede acceder un programa (archivos, redes, capacidades). Es más simple de entender y gestionar.

Ventajas: Sintaxis legible, menos propenso a errores de configuración, ideal para servidores web y contenedores.
Desventajas: Menos granular que SELinux, no soporta etiquetado multinivel.

Perfil típico para Apache (/etc/apparmor.d/usr.sbin.apache2):

#include <tunables/global>

/usr/sbin/apache2 {
  #include <abstractions/base>
  #include <abstractions/apache2-common>

  /var/www/** r,
  /var/log/apache2/* w,
  /etc/apache2/** r,
  /usr/sbin/apache2 mr,
}

Para ver el estado:

sudo aa-status

Para cargar un perfil:

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.apache2

Combinando Kernel Lockdown + LSMs para un hardening completo

La verdadera potencia aparece cuando se integran Kernel Lockdown con SELinux o AppArmor. Lockdown protege el kernel contra manipulaciones directas, mientras que los LSMs controlan el acceso a recursos desde el espacio de usuario.

Escenario práctico: Servidor web con AppArmor + Lockdown

Activar Lockdown en modo integrity.
Configurar AppArmor con perfiles para Apache, PHP-FPM y MySQL.
Firmar todos los módulos del kernel con una clave privada y cargar la pública en MOK (Machine Owner Key) para UEFI Secure Boot.

# Generar clave
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=MiClave/"
# Inscribir en MOK
sudo mokutil --import MOK.der
# Firmar módulos
sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 MOK.priv MOK.der /lib/modules/$(uname -r)/kernel/drivers/...

Configurar AppArmor en modo enforce para los servicios críticos.

sudo aa-enforce /etc/apparmor.d/usr.sbin.apache2

Monitorear logs para detectar violaciones:

sudo journalctl -u apparmor | grep DENIED
sudo dmesg | grep lockdown

Escenario con SELinux y Lockdown en modo confidentiality

Para entornos de alta seguridad (bancos, defensa):

Activar Lockdown=confidentiality.
SELinux en modo enforcing con política MLS.
Configurar etiquetas para clasificar datos (Top Secret, Secret, etc.).
Usar audit2allow para generar políticas personalizadas.

# Generar política a partir de logs
sudo audit2allow -a -M mi_politica
sudo semodule -i mi_politica.pp

[TIP] Usa sestatus para ver el contexto actual y seinfo para explorar la política.

Buenas prácticas y errores comunes

Lo que SÍ debes hacer

Probar en un entorno de staging antes de aplicar a producción.
Usar modo permissive inicialmente en SELinux/AppArmor para auditar.
Firmar módulos del kernel si activas Lockdown (especialmente drivers propietarios como NVIDIA).
Actualizar políticas cuando actualices aplicaciones o el kernel.

Lo que NO debes hacer

Desactivar Lockdown por comodidad. Si bloquea algo, ajusta la configuración, no lo desactives.
Ignorar los logs de denegación. Son tu mejor fuente de información.
Mezclar SELinux y AppArmor en el mismo sistema. Elige uno y mantenlo.
Usar Lockdown=confidentiality sin necesidad real, ya que puede romper herramientas de debugging como perf o systemtap.

Herramientas complementarias para hardening

Además de Lockdown y LSMs, considera:

auditd: Para registrar eventos de seguridad.
aide/tripwire: Para integridad de archivos.
sysctl hardening: Parámetros como kernel.kptr_restrict=2, kernel.dmesg_restrict=1.
GRUB password: Para evitar modificaciones en el arranque.
UEFI Secure Boot: Garantiza que solo se cargue software firmado.

Ejemplo de /etc/sysctl.d/99-hardening.conf:

kernel.kptr_restrict=2
kernel.dmesg_restrict=1
kernel.unprivileged_bpf_disabled=1
net.core.bpf_jit_harden=2

Conclusión

La seguridad del kernel de Linux ya no es opcional. Con Kernel Lockdown y LSMs como SELinux o AppArmor, disponemos de herramientas maduras y eficaces para proteger el núcleo del sistema operativo frente a amenazas avanzadas. La clave está en entender que no son excluyentes, sino complementarias: Lockdown protege el kernel desde dentro, mientras que los LSMs controlan el acceso desde fuera.

Implementar un hardening Linux completo requiere planificación, pruebas y monitorización continua. Pero una vez configurado correctamente, el nivel de seguridad que se alcanza es comparable al de sistemas certificados como Common Criteria EAL4+. Empieza por un modo permissive, audita, ajusta y luego activa enforcing. Tu servidor (y tus datos) te lo agradecerán.