29 – SELinux 02

Te doy la bienvenida al episodio 29 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 29 de mayo de 2018.
Si recuerdas, en el episodio anterior conversamos sobre Secure Enhanced Linux (SELinux) y vimos que despliega de una capa de seguridad basada en políticas que se aplican mandatoriamente a todos los usuarios del sistema, ya sean aplicaciones, usuarios o el propio root.
Quedamos en ver cómo hace SELinux para aplicar estas políticas, es decir, cómo permite o niega una determinada acción. Y también en cómo podemos hacer nosotros para administrar nuestras configuraciones de políticas o aquello que te comentaba de cómo sobrevivir con SELinux activado.

La decisiones de SELinux para autorizar o denegar una determinada acción se basan en el contexto entre el sujeto (quién inicia la acción) y el objeto (que será el destino de la acción). Este contexto es un componente de las reglas que mantiene SELinux en sus políticas.
¿Cómo se define, entonces, un contexto?
SELinux lo que hace es manejar etiquetas o labels que representarán estos sujetos y objetos.
Fíjate que con un manejo de etiquetas, SELinux se abstrae de conocer cosas como el propietario de un proceso, los permisos de un archivo y, a la vez, se puede empezar a etiquetar cosas que hasta ahora no tenían referencia explícita, como puertos o sockets.
Los archivos guardan las etiquetas en atributos extendidos del filesystem; los procesos, puertos y otros será el kernel Linux quién maneje directamente las etiquetas en runtime.
Claro, te preguntas ¿cómo son estas etiquetas?
Las etiquetas tienen un formato de cuatro campos separados por dos puntos: el primer campo es el usuario (que atención!, no tiene una correlación con el usuario de sistema), el segundo campo es el rol, el tercer campo es el tipo (que también se le llama contexto) y un cuarto campo opcional para definir niveles.
Si hiciéramos una equivalencia con un sistema de gafete para una empresa que reparte identificaciones para las personas que están dentro de su predio, podríamos decir que el usuario puede ser “visitante” (¿ves que no tiene nada que ver con la persona en si misma?), el rol puede ser “auditor”, tipo podría ser “hornos” o “línea ensamblado” y el nivel podría ser uno “técnico”, “supervisor”, “procesos” etc. De esta forma etiquetas a una persona como visitante:auditor:línea_ensamblado:seguridad y te permite definir si va a tener acceso, por ejemplo, detener la linea de ensamblado. ¿lo entiendes?
Para lo que te estoy contando que es cómo ser amigos de SELinux, solo el tercer campo, el campo tipo, nos es relevante. Los otros campos de la etiqueta, como usuario o el rol, se utilizan cuando tienes requisitos de seguridad de que se enmarcan en controles de acceso de Multi-Level Security (MLS), utilizado generalmente en el ámbito militar, o Multi-Categories Security (MCS), utilizado en el ámbito financiero, por lo que esta será la única referencia que haré a estos tres campos y nos concentraremos de aquí en más en el campo del tipo.
Ahora veamos cómo esas etiquetas de tipo permiten vincular los sujetos con los objetos, y creo que lo mejor es verlo con un ejemplo: y vamos a usar el servidor web Apache, que ya por sí es un estándar maduro para servicios web.
Pero antes debes saber que para las etiquetas se ha definido la opción -Z (generalmente mayúscula) para que los distintos comandos desplieguen las etiquetas de lo que ellos muestran. Por ejemplo, el comando id -Z mostrará la etiqueta que llevas tu ahora, como usuario del sistema (por supuesto, solo si estás en un sistema con SELinux).
En el ejemplo de Apache, el binario que ejecutamos es httpd que si consultas con ls -Z verás que tiene un tipo (o contexto) definido como httpd_exec_t.
Si lo lanzas verás la etiqueta del demonio con el comando ps axZ, que que tiene un tipo o contexto httpd_t
Con el comando ss -z (en este caso minúscula) podemos listar los sockets abiertos, ver que que el puerto 80 está vinculado al proceso etiquetado como httpd_t. O usar el comando semanage port -l | grep httpd para ver que existe una etiqueta httpd_port_t que contiene, entre otros, el puerto 80.
También si hacemos un ls -Z al directorio donde Apache puede leer los archivos web, en mi caso /var/www/html podremos ver que su contexto es httpd_sys_content_t.
Y con esto ya tenemos los ingredientes para armar un sistema de políticas de acceso y asociar la etiqueta de un sujeto con la etiqueta de un objeto y decirle si se aceptan o deniegan las acciones.
Ah, ¿creías que era más complicado? Tranquilo, es como todo, cuestión de agarrarle la mano.
El comando para manejo de las etiquetas es semanage. Que nos va a permitir cosas como:
asignar etiquetas a usuarios del sistema
manejar los puertos o sockets vinculados a una etiqueta
definir los contextos de los archivos
Entre otro montón de otras opciones de configuración.
La sintaxis de semanage no es simple, hay que referirse a la documentación, casi que en todos los casos.
La otra característica es que todo lo que instalo por el sistema de paquetes, si lo utilizo como viene por defecto, queda configurado con políticas de SELinux adecuadas y no debo tomar ninguna acción.

Aparte de las etiquetas para sujetos y objetos, SELinux maneja permisos que afectan las funciones de las aplicaciones o deamons mediante los llamados booleans ya que se prenden (valor on o 1) o se apagan (valor off o 0).
En particular, los booleans son políticas (o conjuntos de políticas) de SELinux que definen un funcionamiento aceptable para los procesos del sistema.
Siguiendo con el ejemplo de Apache, podemos apagar el booleano que permite acceder a un filesystem montado por red, o a conectarse a una base de datos LDAP, o servir los home de los usuarios. ¿Qué quiere decir esto? Que el la configuración de Apache pude muy prolijamente tener configurada y activada una de estas funcionalidades, pero la política de SELinux le puede negar hacer uso de esa funcionalidad.
Y son cientos los boleados que vienen per-configurados para muchos tipos de daemons y aplicaciones.
Los comandos que se usan para el manejo de boleados son getsebool y setsebool según si se quiere consultar o configurar el estado de un booleano.
Y podemos decir que esto es todo, aunque para ser amigos de SELinux podemos hacer algo más y eso es conocer los modos de SELinux.
Los modos es cómo SELinux aplica las políticas y tenemos tres posibilidades: puede ser de modo Enforced permitiendo o denegando; de modo Permissive permitiendo todo, pero guardando en el log de auditoría (audit.log) los incumplimientos de las políticas, o, la tercer opción, puede ser Disabled que es cuando SELinux está apagado.
Dependiendo de la distribución, tendrás SELinux pre-configurado en alguno de estos modos.
Para manejo de los modos se dispone de los comandos getenforce y setenforce que que permiten pasar entre Enforced y Permissive en cualquier momento. Esto es muy útil para cuando algo no funciona como uno espera, pasar SELinux a Permissive y si ahora comienza a funcionar, seguro se debe a alguna política y deberemos ajustar las etiquetas o cambiar el booleano.

Y si, hay mucho más de SELinux pero creo que con estos puntos que te he comentado puedes hacerte una idea de por donde viene la cosa.
Si lo vas a activar, cosa que obviamente te sugiero, es conveniente dejarlo funcionando desde la instalación inicial, pues cada cambio lo hagas será siguiendo las políticas. Si no lo has activado y tienes tu servidor en funcionamiento desde hace tiempo, al activarlo, posiblemente sean muchas cosas las que incumplan políticas y la adecuación se te hará difícil.
En todos los casos SELinux requiere que de RTFM por lo que espero que esta presentación de SELinux en dos ediciones de deployandome te permita decidir si sirve para tus necesidades de seguridad.
Soy Rodolfo Pilas, en twitter me puedes seguir por @pilasguru y te dejo un saludo. Confío que este podcast te haya aportado para mejorar y, como siempre, espero tus inquietudes y sugerencias comentando en deployando.me
Hasta la próxima edición.