Aunque seas root

Por qué SELinux

SELinux (Security-Enhanced Linux) es una extensión del kernel de Linux que implementa control de acceso mandatorio (MAC). La desarrollaron la NSA y DARPA de Estados Unidos; se publicó en el año 2000 y entró al kernel en la versión 2.6, en 2003.

Antes, Linux solo tenía el modelo discrecional (DAC): permisos según la identidad del usuario, que el dueño de cada recurso decide. Es simple, pero confía en que cada usuario administre bien sus permisos, y si alguien obtiene una cuenta con privilegios suficientes, puede cambiarlos a su favor. En el modelo mandatorio, las políticas las impone un sistema central, no la discreción del usuario ni del dueño del recurso, y se aplican igual a todos.

El ejemplo clásico es el servidor web Apache: es un blanco frecuente y suele correr con privilegios altos, como root, porque solo root puede abrir los puertos menores de 1024 (el 80 y el 443). Si alguien lo vulnera, tiene acceso a todo el sistema. Con SELinux, cada proceso queda restringido al conjunto de recursos (archivos, puertos…) que tiene asignado: aunque lo comprometan, el atacante no puede ir más allá del servicio.

Contextos de seguridad

SELinux pone etiquetas de seguridad a los sujetos (usuarios y procesos) y a los objetos (archivos, directorios, puertos de red). Esa etiqueta es el contexto de seguridad, y tiene típicamente tres componentes, como en system_u:object_r:lib_t:

1. Usuario de SELinux: identifica al usuario o rol que inicia el proceso o posee el objeto.
2. Rol: si es administrativo o no; ayuda a definir los permisos sobre los objetos.
3. Tipo: la etiqueta que clasifica el objeto o el proceso, y es la que usan casi todas las reglas.

Las políticas dicen qué acciones permite cada tipo de sujeto sobre cada tipo de objeto. Cuando un proceso intenta acceder a un archivo, SELinux compara sus contextos con la política: si ninguna regla lo permite, se niega, aunque los permisos rwx lo dejen. Por eso etiquetar bien es esencial: un contexto equivocado produce accesos denegados que parecen inexplicables.

Etiquetado, aislamiento y modos

• Cada proceso y cada archivo está marcado con un contexto (labeling).
• Los archivos nuevos heredan el contexto del directorio donde se crean.
• La política asigna los contextos a los procesos; el login y la shell pueden, si la política lo permite, asignar el contexto de los procesos que inician.
• Así, dos servicios importantes como Apache y la base de datos MariaDB, aunque corran como root, quedan aislados cada uno en sus recursos: si vulneran uno, no puede dañar los archivos del otro.

Formas de operar:

• Strict: todo se niega por omisión; hay que escribir una regla para cada cosa permitida.
• Targeted: todo se permite, excepto lo que marca la política; lo que no está confinado corre como unconfined_t.
• Permissive: solo se reporta, y se conceden todas las peticiones. Se usa para crear las políticas.

ampliación En una instalación actual, targeted y strict son nombres de políticas, y el modo se elige aparte: Enforcing (aplica), Permissive (solo registra) o Disabled. getenforce muestra el modo, setenforce 0 o 1 lo cambia, ls -Z y ps -Z muestran los contextos, restorecon devuelve a un archivo su contexto correcto y los rechazos quedan en la bitácora de auditoría (ausearch -m avc).

A favor: refuerza la seguridad con control más fino y menos superficie de ataque, permite políticas a la medida, mitiga ataques de día cero al limitar lo que un proceso puede hacer y mejora la auditoría. En contra: es complejo de configurar, puede costar algo de rendimiento con mucha carga y algunas aplicaciones necesitan ajustes para funcionar con él. Aun así, la recomendación es no deshabilitarlo.

Antes de leer la respuesta