Revise las etiquetas antes de culpar a SELinux

Cuando una aplicación se rompe en un host con SELinux en enforcing, el reflejo en muchos equipos es pasar SELinux a permissive y seguir adelante. Nosotros lo mantenemos en enforcing en todos los hosts que operamos, y en nuestra experiencia la causa suele ser mucho más pequeña de lo que sugiere el reflejo: un fichero con la etiqueta equivocada. Este artículo muestra cómo encontrarlo rápido, corregirlo de la manera correcta y evitar quedarse fuera mientras lo hace.

Qué es una etiqueta, y cómo se estropea

SELinux toma decisiones a partir de etiquetas. Cada fichero y cada proceso lleva un contexto de seguridad, y la política dice qué tipos de proceso pueden hacer qué a qué tipos de fichero. La política también dice qué etiqueta debería tener cada ruta: el contenido de /var/www debería ser httpd_sys_content_t, un ejecutable bajo /usr/bin debería ser bin_t, y así sucesivamente. Esas etiquetas esperadas son las reglas de contexto de fichero.

Un fichero recibe su etiqueta al crearse, normalmente heredada de su directorio padre o fijada por una regla de la política. Eso funciona bien hasta que los ficheros llegan por una ruta inusual:

• mv conserva la etiqueta original, así que un fichero creado en un directorio personal y movido a una raíz web sigue diciendo que pertenece a un directorio personal.
• Los archivos desempaquetados sin atributos de SELinux, o restaurados desde un backup que no los conservó, reciben lo que reparta el directorio de destino.
• El contenido colocado en una ubicación personalizada, como /srv/app, recibe una etiqueta genérica porque la política aún no tiene una regla para esa ruta.

En todos esos casos la política está bien. El fichero simplemente lleva la etiqueta equivocada, y al proceso que lo necesita se le niega.

Lea primero la denegación

Antes de cambiar nada, lea qué rechazó SELinux realmente:

ausearch -m AVC -ts recent

Cada denegación nombra el tipo del proceso (scontext), el tipo del objetivo (tcontext), la clase del objeto y el permiso. Si el tipo del objetivo parece incorrecto para ese fichero (un servidor web al que se le niega leer algo etiquetado como user_home_t, por ejemplo), casi con toda seguridad está ante un problema de etiquetado, no ante un hueco en la política.

Compare lo que hay con lo que debería haber

Tres comandos responden la pregunta directamente:

ls -Z /path/to/file            # the label it has
matchpathcon /path/to/file     # the label the policy expects
restorecon -nv /path/to/file   # dry run: what restorecon would change

restorecon -n no cambia nada. Solo informa de la diferencia entre la etiqueta actual y la esperada, lo que lo convierte en la herramienta de auditoría perfecta. Ejecútelo sobre un árbol entero después de una instalación, una restauración o una migración:

restorecon -Rnv /etc /usr /var /srv 2>/dev/null

Un resultado vacío significa que cada fichero bajo esas rutas lleva la etiqueta que la política espera. Cualquier línea en la salida es un fichero que no la lleva, y esa lista suele ser corta y muy reveladora. Nosotros ejecutamos este tipo de comprobación en las construcciones nuevas como rutina, y nuestras plantillas de instalación reetiquetan las rutas críticas en su paso de postinstalación, de modo que un host nuevo empieza su vida con etiquetas correctas antes de que nadie inicie sesión.

Corríjalo de la manera correcta

Para un fichero que simplemente tiene la etiqueta equivocada, reetiquételo a lo que la política espera:

restorecon -Rv /path

Para una ubicación personalizada que la política no conoce, enséñele primero la regla a la política y después reetiquete, para que la corrección sobreviva al siguiente reetiquetado completo:

semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?"
restorecon -Rv /srv/app

chcon también cambia etiquetas, pero solo hasta el siguiente reetiquetado, tras el cual el problema vuelve. Úselo para experimentos, no para correcciones.

Si las etiquetas son correctas y la denegación es sobre comportamiento, revise los booleanos antes de escribir política. Muchas necesidades comunes, como que un servidor web abra conexiones de red salientes, son un único interruptor:

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

Desconfíe de audit2allow

audit2allow lee denegaciones y escribe un módulo de política que las permite. Siempre producirá algo que funciona, que es exactamente el peligro. Si la causa real es un fichero mal etiquetado, el módulo generado concede un permiso amplio para que el síntoma desaparezca, y todos los demás ficheros y procesos de ese tipo heredan la política debilitada. Lea lo que propone. Una regla que permite a un dominio transicionar a otro muy privilegiado, o leer todo lo de un tipo común, es una pista fuerte de que la etiqueta está mal y el módulo es la corrección equivocada. Los módulos personalizados a veces son correctos, para software propio sin política, pero deberían ser el último paso, no el primero.

Pase a enforcing con seguridad en un host remoto

Cambiar una máquina remota de permissive a enforcing es uno de esos cambios que pueden cortar su propia sesión si algo sigue mal etiquetado. Arme primero una red de seguridad, para que el host se devuelva a sí mismo al estado anterior si pierde el acceso:

systemd-run --on-active=240 --unit=selinux-net /usr/sbin/setenforce 0
setenforce 1
# open a NEW ssh session and confirm it works
systemctl stop selinux-net.timer

systemd dispara el temporizador sobreviva o no su sesión. Cancélelo solo después de que un inicio de sesión completamente nuevo haya tenido éxito. El mismo patrón sirve para cambios de firewall, SSH y enrutamiento en una máquina a la que no puede acercarse andando.

Una lista breve

• Ejecute restorecon -Rnv sobre las rutas del sistema después de cada instalación, restauración o migración.
• Lea la denegación AVC y compare ls -Z con matchpathcon antes de cambiar la política.
• Use semanage fcontext más restorecon para rutas personalizadas, no chcon.
• Revise los booleanos antes de escribir un módulo.
• Trate la salida de audit2allow como una pregunta, no como una respuesta.
• Nunca pase un host remoto a enforcing sin una vuelta atrás temporizada.

Si el fabricante de una aplicación le ha dicho que desactive SELinux y preferiría no hacerlo, estaremos encantados de ayudar a encontrar la corrección precisa. Hable con un ingeniero

Related

Relacionado: La línea base de bastionado en cada host · Respuesta de emergencia a vulnerabilidades el mismo día