28 – SELinux 01

Te doy la bienvenida al episodio 28 de deployandome, el podcast de tecnología para sysadmins y devops. Soy Rodolfo Pilas y estoy grabando el 24 de abril de 2018.
No creo sorprender al afirmar que la seguridad significa un compromiso con la usabilidad. Esto lo podemos ver en nuestras propias casas: si tenemos una reja permitetral en el jardin, una reja delante de la puerta, una puerta y una alarma; para entrar y salir nos llevará un cierto tiempo dedicado solo pasar por los elementos de seguridad que hemos colocado y además deberemos cargar o recordar llaves o mandos para cada uno de esos elementos de seguridad.
No es la primera vez, ni será la última, que en deployandome abordaré temas vinculados a la seguridad, la seguridad es parte de nuestras tareas. Si recuerdas, en la edición 1 ya hablamos de certificados SSL con Let’s Encrypt. En la edición 7 vimos con solo poner un archivo en una carpeta ya quedaba cifrado. En las ediciones 16 y 17 repasamos algunas prácticas generales para fortalecer nuestros servidores.
Pero en esta edición 28 voy a traer un elemento de seguridad que en la mayoría de los manuales sugieren “desactivarlo” y te confieso la mayoría de los colegas con los suelo hablar lo tienen, efectivamente, desactivado.
“Desactívalo y vas a ver que todo te funciona” es la frase más común que solemos escuchar vinculada a Security Enhanced Linux, que todos conocemos como SELinux, y que hoy lo voy a deployar contigo.

Pues, como te digo, percibo que SELinux está en la mente de la mayoría de mis colegas como una molestia, como una traba de seguridad que complica más de lo que soluciona y te confieso que tuve esa misma sensación hasta que lo conocí o hasta que nos hicimos amigos.
Por eso, para ser justos con SELinux, tenemos que entender qué hace, para qué está y qué soluciona, luego recién podremos decidir si es bueno aplicarlo o no.
En GNU/Linux tenemos un solido sistema de permisos basados en privilegios de usuarios.
Por un lado tenemos usuarios que tienen permiso de acceso a ciertas partes del filesystem, a abrir cierto rango de puertos para conexiones TCP y a editar ciertos archivos. Cambiando estos permisos de acceso, principalmente en los archivos, podemos lograr independizar el accionar de un usuario con otro y ya el kernel Linux se encargará de separar los espacios de memoria, los procesos, las conexiones. En esta nube de usuarios independientes entre si, conviven las aplicaciones y los usuarios humanos, que los llamamos system users y users respectivamente.
Un tercer jugador es el usuario administrador: root. Adecuadamente comparado con Dios. Ya que sus permisos son globales, inclusive puede actuar contra el propio sistema, borrando espacios de disco, interceptando memoria, gestionando procesos ajenos… en fin, puede hacer todo.
Para llevar la gestión diaria de un sistema GNU/Linux hay tareas que son iniciadas como administrador y luego decrece privilegios para ejecutar como usuario y, hay otras, que un usuario puede pedir que sean realizadas como administrador, cuando él no tiene suficientes permisos.
A este sistema de permisos se le conoce como un sistema “discrecional”, es decir, depende quién seas será lo que puedas hacer, siendo que la mayor jerarquía puede incluso deshacer lo que se ha hecho por debajo de ella.
Llevemos este sistema de permisos al mundo real: imaginemos una organización que llamaremos ENTIDAD-A que está basada en una jerarquía discrecional: supongamos tiene un tesorero que se encargara de la gestión financiera y un secretario que lleva la gestión administrativa. De esta forma, el tesorero no podrá establecer contratos y el secretario no puede hacer pagos. Pero existe el Presidente de la ENTIDAD-A que puede venir y cesar un funcionario o puede pedir se pague algún gasto, y solamente por ser el presidente, puede hacer esto y mucho más.
Las organizaciones con jerarquías “discresionales” están por todos lados: ¿cuántos de nosotros le decimos a un compañero que abra un ticket por su reclamo, pero salimos volados de nuestro escritorio si llama un gerente por un reclamo equivalente? Si te pasa esto entonces trabajas en una organización con jerarquía “discresional”.
Suelo explicarles a mis alumnos que un acceso discrecional es aquel que se contesta con “dime quién eres y te diré que puedes hacer“.
Esto es lo que tenemos normalmente en nuestros sistemas GNU/Linux. Tratamos de trabajar como usuario y anteponemos sudo para tareas puntuales que requieren privilegios superiores, justamente para que el sistema nos de la protección del acceso discrecional. ¿o nunca escuchaste la frase “no conviene trabajar como root“? Pues es precisamente por esto: por el control discrecional.
¿Y sabes qué? El acceso discrecional no se adapta a las necesidades de una organización moderna.
A ver si entendemos el problema del control discrecional:
Los administradores y los encargados de seguridad sabemos que es necesario manejar un cierto nivel de “confianza” en las personas que operan el sistema para mantenerlo seguro. Esto se debe a que, en el GNU/Linux discrecional, gran parte de la confianza en el sistema depende de la voluntad de los usuarios que lo operan y que escalan privilegios para hacer sus tareas y entonces “confiamos” que no harán cosas no autorizadas y apelamos la ética profesional para mantener la seguridad.
Una organización basa su seguridad en “políticas” que no pueden estar basadas en la “confianza” ni en la “ética, sino que se deben aplicar en forma mandatoria, siempre, sin importar quién seas, o si te desempeñas éticamente o no. Y es precisamente lo que llamamos “acceso mandatorio”.
Imaginemos nuevamente la ENTIDAD-A, pero ahora con acceso mandatorio, con políticas definidas e impuestas por igual a todos: en este entorno, si viene el presidente y pide que se cese un funcionario, se le responde que el único que puede hacer esa tarea es el secretario y que deberá seguir un procedimiento.
En un ambiente de políticas, cuanto recibes un reclamo del gerente le respondes que tu procesas los reclamos recibidos mediante tickets y que debes recibir uno para que puedas ayudarlo. Así estarás aplicando políticas; y claro que no impide que tu mismo le escribas el ticket por el gerente para ayudarlo a tener una solución más rápida, pero también podrías hacerlo para cualquier otro compañero.
Las políticas mandatorias que se aplican por encima de las personalidades, de los cargos y a nivel informático son impuestas por el kernel y nadie escapa de ellas. Esto es lo que hace SELinux, implementa políticas que estarán por encima de los usuarios y del administrador.
EL proyecto Security Enhanced Linux fue iniciado y desarrollado por la Agencia de Seguridad Nacional de los Estados Unidos de América, la famosa NSA, allá por diciembre del año 2000. Es la implementación de una arquitectura del sistema de seguridad de GNU/Linux con una configuración basada en políticas que se conoce como Flux Advanced Security Kernel o FLASK.
A SELinux se lo puede entender como una capa adicional de seguridad que nos permite imponer políticas por encima del simple rwx o el sudo.
SELinux es parte del kernel Linux y utiliza la interfaz Linux Security Module (LSM) para colocarse entre la interacción de los procesos (en espacio de usuario) y los recursos. Administra varios accesos, como ser leer archivos, obtener atributos de un directorio, conectarse a unix sockets, abrir o conectarse a TCP sockets y hasta la ejecución de ciertas capacidades de una aplicación, todo mediante un proceso de imposición de políticas.
Veamos como funciona:
Cuando tenemos una aplicación (por ejemplo, el servidor nginx) que está corriendo como un determinado usuario (en este ejemplo sería www-data), y quiere realizar una determinada acción sobre un recurso (por ejemplo, leer la carpeta /tmp) esta acción será primero revisada por el sistema de acceso discrecional y, todos sabemos, que la carpeta /tmp tiene acceso de lectura para todos los usuarios, por lo cual se concede el acceso y ahi la implementación de LSM llama a SELinux para que revise la política y retorne si el acceso es permitido o no y, ya te adelanto que este acceso no es permitido en las políticas por defecto, por lo que nginx no podrá leer el /tmp a menos que se hagan configuraciones específicas.
Lo mismo pasa si configuras el servidor OpenSSH para que escuche en el puerto 2222, cuando lo re-inicies SELinux en la configuración por defecto, se encargará de negarle el acceso a ese puerto, pues el puerto 2222 no es el que determinan las políticas para el servicio OpenSSH.
Y las políticas de SELinux llegan hasta opciones propias de las aplicaciones. Por ejemplo, si configuras tu servidor FTP para que acepte usuarios anónimos, algo que se hace habilitando algunas opciones en el archivo de configuración, SELinux por defecto no dejará que los usuarios anónimos ingresen; y no importa cuán root tu seas, ni cuán prolijamente lo habilitaste en el archivo de configuración, la política que los usuarios anónimos no ingresan será lo que se aplicará.
Esas políticas se aplican a todos los usuarios, a todos los procesos y a todos los recursos
Ahora que mas o menos tenemos una idea de por donde viene SELinux tenemos que entender cómo lo hace y como nosotros podemos actuar para adecuar estas políticas a nuestra realidad, es decir, re-pactar esas políticas.
Pero esto tenemos tiempo de verlo en futuras ediciones de deployándome.
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.