🥇Sistemas de protección Linux

Una de las razones del gran éxito de los sistemas operativos Linux en dispositivos embebidos, móviles y servidores es el alto nivel de seguridad del núcleo, servicios y aplicaciones asociadas. Pero si se observa de cerca la arquitectura del núcleo de Linux, no se puede encontrar un cuadrado dedicado a la seguridad en sí. ¿Dónde se esconde el subsistema de seguridad de Linux y de qué se compone?

Antecedentes de los Módulos de Seguridad de Linux y SELinux

Security Enhanced Linux es un conjunto de reglas y mecanismos de acceso, basado en modelos de acceso mandatorio y por roles, para proteger los sistemas Linux de amenazas potenciales y corregir las deficiencias del Control de Acceso Discrecional (DAC) — el sistema de seguridad tradicional de Unix. El proyecto nació en el seno de la Agencia de Seguridad Nacional de EE. UU., siendo principalmente desarrollado por contratistas de Secure Computing Corporation y MITRE, así como por varios laboratorios de investigación.

Módulos de Seguridad de Linux

Linus Torvalds hizo una serie de comentarios sobre los nuevos desarrollos de la NSA, para que pudieran ser incluidos en la rama principal del núcleo de Linux. Describió un entorno general, con un conjunto de interceptores para gestionar operaciones con objetos y un conjunto de ciertos campos de protección en las estructuras de datos del núcleo para almacenar los atributos correspondientes. Luego, este entorno puede ser utilizado por módulos cargables del núcleo para implementar cualquier modelo de seguridad deseado. LSM se integró completamente en el núcleo de Linux v2.6 en 2003.

El framework LSM incluye campos de protección en las estructuras de datos y llamadas de funciones de intercepción en puntos críticos del código del núcleo para gestionarlos y ejecutar control de acceso. También añade funciones para registrar módulos de seguridad. La interfaz /sys/kernel/security/lsm contiene una lista de módulos activos en el sistema. Los hooks de LSM se almacenan en listas que son llamadas en el orden especificado en CONFIG_LSM. La documentación detallada sobre los hooks se incluye en el archivo de cabecera include/linux/lsm_hooks.h.

El subsistema LSM permitió completar la integración completa de SELinux de la misma versión estable del núcleo de Linux v2.6. Prácticamente de inmediato, SELinux se convirtió en el estándar de facto de entornos seguros en Linux y se incluyó en la mayoría de los distribuciones más populares: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glosario de SELinux

Identidad El usuario SELinux no es lo mismo que un id de usuario típico de Unix/Linux; pueden coexistir en el mismo sistema, pero son completamente diferentes en esencia. Cada cuenta estándar de Linux puede corresponder a uno o varios en SELinux. La identidad de SELinux es una parte integral del contexto de seguridad general que define a qué dominios se puede acceder y a cuáles no.
Dominios En SELinux, un dominio es el contexto de ejecución de un sujeto, es decir, un proceso. El dominio determina directamente el acceso que tiene el proceso. Un dominio es principalmente una lista de lo que pueden hacer los procesos o qué acciones puede ejecutar un proceso con diferentes tipos. Algunos ejemplos de dominios son: sysadm_t para la administración del sistema, y user_t, que es el dominio normal no privilegiado del usuario. El sistema de inicialización init se ejecuta en el dominio init_t, y el proceso named se ejecuta en el dominio named_t.
Roles Lo que actúa como intermediario entre los dominios y los usuarios de SELinux. Los roles definen en qué dominios puede estar un usuario y qué tipos de objetos podrá acceder. Este mecanismo de control de acceso previene la amenaza de un ataque de elevación de privilegios. Los roles están inscritos en el modelo de seguridad de Control de Acceso Basado en Roles (RBAC), utilizado en SELinux.
Tipos Un atributo de la lista de Type Enforcement que se asigna a un objeto y define quién tendrá acceso a él. Es similar a la definición de un dominio, con la excepción de que el dominio se aplica al proceso y el tipo se aplica a objetos como directorios, archivos, sockets, etc.
Sujetos y objetos Los procesos son sujetos y se ejecutan en un contexto determinado, o dominio de seguridad. Los recursos del sistema operativo: archivos, directorios, sockets, etc., son objetos a los que se asigna un tipo determinado, o, en otras palabras, un nivel de confidencialidad.
Políticas SELinux Para proteger el sistema, SELinux utiliza diversas políticas. La política SELinux define el acceso de los usuarios a roles, de roles a dominios y de dominios a tipos. Al principio, el usuario se autoriza para obtener un rol, luego el rol se autoriza para acceder a los dominios. Finalmente, un dominio puede tener acceso solo a ciertos tipos de objetos.

LSM y arquitectura SELinux

A pesar de su nombre, LSM no es en realidad un módulo cargable de Linux. Sin embargo, al igual que SELinux, está integrado directamente en el núcleo. Cualquier modificación del código fuente de LSM requiere una nueva compilación del núcleo. La opción correspondiente debe estar habilitada en la configuración del núcleo; de lo contrario, el código LSM no se activará después del arranque. Pero incluso en este caso, se puede habilitar mediante una opción en el cargador del sistema operativo.

Stack de Comprobaciones LSM

LSM está equipado con ganchos en funciones clave del núcleo que pueden ser relevantes para las comprobaciones. Una de las principales características de LSM es que están estructurados en forma de pila. De este modo, se siguen realizando las comprobaciones estándar, y cada capa de LSM simplemente agrega controles adicionales. Esto significa que la denegación no se puede revertir. Como se muestra en la imagen, si el resultado de las comprobaciones DAC rutinarias resulta en una denegación, ni siquiera llegará a los ganchos LSM.

SELinux adoptó la arquitectura de seguridad Flask del sistema operativo de investigación Fluke, en particular el principio de privilegios mínimos. La esencia de este concepto, como indica su nombre, es otorgar al usuario o proceso solo los derechos necesarios para llevar a cabo las acciones pretendidas. Este principio se implementa mediante la tipificación obligatoria de acceso, por lo que el control de accesos en SELinux se basa en el modelo dominio => tipo.

Gracias a la tipificación obligatoria de acceso, SELinux tiene capacidades mucho más significativas para restringir el acceso que el modelo DAC tradicional utilizado en los sistemas operativos Unix/Linux. Por ejemplo, se puede restringir el número de puerto de red que puede usar un servidor FTP, permitir la escritura y modificación de archivos en una carpeta específica, pero no su eliminación.

Los componentes principales de SELinux son:

Servidor de Aplicación de Políticas — Mecanismo principal para la organización del control de acceso.
Base de Datos de políticas de seguridad del sistema.
Interacción con el interceptor de eventos LSM.
Selinuxfs — Sistema de archivos pseudo, similar a /proc y montado en /sys/fs/selinux. Se llena dinámicamente por el núcleo de Linux durante la ejecución y contiene archivos que contienen información sobre el estado de SELinux.
Caché de Vector de Acceso — Mecanismo auxiliar para aumentar el rendimiento.

Esquema de funcionamiento de SELinux

Todo esto funciona de la siguiente manera.

Un sujeto, en los términos de SELinux, realiza una acción permitida sobre un objeto tras la verificación DAC, como se muestra en la imagen superior. Esta solicitud de ejecución de operación se envía al interceptor de eventos LSM.
Desde allí, la solicitud junto con el contexto de seguridad del sujeto y el objeto se envía al módulo de Abstracción y Lógica de Gancho de SELinux, responsable de la interacción con LSM.
La instancia de toma de decisiones sobre el acceso del sujeto al objeto es el Servidor de Aplicación de Políticas y a él se envían datos desde SELinux AnHL.
Para tomar una decisión sobre el acceso o la denegación, el Servidor de Aplicación de Políticas consulta el subsistema de caché de las reglas más utilizadas, Cache de Vector de Acceso (AVC).
Si la decisión para la regla correspondiente no se encuentra en la caché, la solicitud se envía a la base de datos de políticas de seguridad.
El resultado de la búsqueda en la base de datos y en el AVC se devuelve al Servidor de Aplicación de Políticas.
Si la política encontrada coincide con la acción solicitada, la operación se permite. De lo contrario, la operación se niega.

Gestión de configuraciones de SELinux

SELinux opera en uno de tres modos:

Enforcing — Estricto cumplimiento de las políticas de seguridad.
Permissive — Se permite la violación de restricciones, se registra el hecho en el diario.
Disabled — Las políticas de seguridad no están activas.

Para ver en qué modo se encuentra SELinux, se puede utilizar el siguiente comando.

[admin@server ~]$ getenforce
Permissive

Cambio de modo hasta el reinicio, por ejemplo, para establecer en enforcing, o 1. Al parámetro permissive le corresponde el código numérico 0.

[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 # lo mismo

También se puede cambiar el modo editando el archivo:

[admin@server ~]$ cat /etc/selinux/config

# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of three values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection.
SELINUXTYPE=targete

La diferencia con setenfoce es que al iniciar el sistema operativo, el modo SELinux se establecerá de acuerdo con el valor del parámetro SELINUX del archivo de configuración. Además, los cambios de enforcing disabled solo entrarán en vigor a través de la modificación del archivo /etc/selinux/config y tras el reinicio.

Ver un breve informe de estado:

[admin@server ~]$ sestatus

Estado de SELinux: habilitado Montaje de SELinuxfs: /sys/fs/selinux Directorio raíz de SELinux: /etc/selinux Nombre de la política cargada: dirigido Modo actual: permisivo Modo del archivo de configuración: obligatorio Estado de la política MLS: habilitado Estado de denegación de la política desconocida: permitido Versión máxima de la política del núcleo: 31
Para ver los atributos de SELinux, algunas utilidades estándar utilizan el parámetro -Z.

[admin@server ~]$ ls -lZ /var/log/httpd/
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200920
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20200927
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201004
-rw-r--r--. root root system_u:object_r:httpd_log_t:s0 access_log-20201011
[admin@server ~]$ ps -u apache -Z
LABEL                             PID TTY          TIME CMD
system_u:system_r:httpd_t:s0     2914 ?        00:00:04 httpd
system_u:system_r:httpd_t:s0     2915 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2916 ?        00:00:00 httpd
system_u:system_r:httpd_t:s0     2917 ?        00:00:00 httpd
...
system_u:system_r:httpd_t:s0     2918 ?        00:00:00 httpd

En comparación con la salida normal de ls -l, aquí hay algunos campos adicionales en el siguiente formato:

:::

El último campo indica algo así como un nivel de clasificación de seguridad y consiste en una combinación de dos elementos:

s0 — importancia, también se anota como intervalo lowlevel-highlevel
c0, c1… c1023 — categoría.

Cambio en la configuración de accesos

Utilice semodule para cargar módulos de SELinux, añadirlos y eliminarlos.

[admin@server ~]$ semodule -l |wc -l #lista de todos los módulos
408
[admin@server ~]$ semodule -e abrt #habilitar - activar módulo
[admin@server ~]$ semodule -d accountsd #deshabilitar - desactivar módulo
[admin@server ~]$ semodule -r avahi #eliminar - borrar módulo

El primer comando semanage login vincula el usuario de SELinux con el usuario del sistema operativo, el segundo muestra la lista. Finalmente, el último comando con la opción -r elimina la vinculación entre los usuarios de SELinux y las cuentas del sistema operativo. La explicación de la sintaxis de los rangos MLS/MCS se encuentra en la sección anterior.

[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l

Nombre de inicio de sesión SELinux Usuario Rango MLS/MCS Servicio __default__ unconfined_u s0-s0:c0.c1023 * root unconfined_u s0-s0:c0.c1023 * system_u system_u s0-s0:c0.c1023 * [admin@server ~]$ semanage login -d karol
Comando semanage user se utiliza para gestionar las vinculaciones entre usuarios y roles de SELinux.

[admin@server ~]$ semanage user -l
                Etiquetado   MLS/       MLS/                          
Usuario SELinux    Prefijo     Nivel MCS  Rango MCS             Roles SELinux
guest_u         user       s0         s0                    guest_r
staff_u         staff      s0         s0-s0:c0.c1023        staff_r sysadm_r
...
user_u          user       s0         s0                    user_r
xguest_u        user       s0         s0                    xguest_r
[admin@server ~]$ semanage user -a -R 'staff_r user_r'
[admin@server ~]$ semanage user -d test_u

Parámetros del comando:

-a agregar un registro de usuario de correspondencia de roles;
-l listar la correspondencia de usuarios y roles;
-d eliminar un registro de usuario de correspondencia de roles;
-R listar los roles asociados al usuario;

Archivos, puertos y valores booleanos

Cada módulo de SELinux proporciona un conjunto de reglas de etiquetado de archivos, pero también se pueden agregar reglas personalizadas si es necesario. Por ejemplo, queremos dar al servidor web permisos para acceder a la carpeta /srv/www.

[admin@server ~]$ semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?
[admin@server ~]$ restorecon -R /srv/www/

El primer comando registra nuevas reglas de etiquetado, y el segundo restablece, o mejor dicho, establece, los tipos de archivos de acuerdo con las reglas actuales.

De manera similar, los puertos TCP/UDP están marcados de tal forma que solo los servicios correspondientes pueden escucharlos. Por ejemplo, para que el servidor web pueda escuchar el puerto 8080, es necesario ejecutar el comando.

[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080

Un número significativo de módulos de SELinux tienen parámetros que pueden tomar valores booleanos. Se puede ver toda la lista de estos parámetros utilizando getsebool -a. Los valores booleanos se pueden cambiar con setsebool.

[admin@server ~]$ getsebool httpd_enable_cgi
httpd_enable_cgi --> on
[admin@server ~]$ setsebool -P httpd_enable_cgi off
[admin@server ~]$ getsebool httpd_enable_homedirs --> off

Práctica, acceso a la interfaz Pgadmin-web.

Consideremos un ejemplo práctico, hemos instalado en RHEL 7.6 pgadmin4-web para la administración de bases de datos PostgreSQL. Hemos pasado por una pequeña búsqueda con la configuración de pg_hba.conf, postgresql.conf y config_local.py, establecimos permisos en las carpetas, instalamos los módulos de Python faltantes desde pip. Todo listo, iniciamos y obtenemos 500 Internal Server error.

Comenzamos con los sospechosos habituales, revisamos /var/log/httpd/error_log. Hay algunas entradas interesantes.

[timestamp] [core:notice] [pid 23689] Política SELinux habilitada; httpd ejecutándose como contexto system_u:system_r:httpd_t:s0 ... [timestamp] [wsgi:error] [pid 23690] [Errno 13] Permiso denegado: '\/var\/lib\/pgadmin' [timestamp] [wsgi:error] [pid 23690] [timestamp] [wsgi:error] [pid 23690] SUGERENCIA: Puede que necesite establecer manualmente los permisos en [timestamp] [wsgi:error] [pid 23690] \/var\/lib\/pgadmin para permitir que apache escriba en él.

En este punto, la mayoría de los administradores de Linux sentirán la tentación de ejecutar setenforce 0 y dejarlo así. Debo confesar que la primera vez lo hice. Esta es una salida, pero no la mejor.

A pesar de la complejidad de las construcciones, SELinux puede ser amigable para el usuario. Solo hay que instalar el paquete setroubleshoot y revisar el registro del sistema.

[admin@server ~]$ yum install setroubleshoot [admin@server ~]$ journalctl -b -0 [admin@server ~]$ service restart auditd

Tenga en cuenta que el servicio auditd debe reiniciarse de esta manera, y no usando systemctl, a pesar de tener systemd en el sistema operativo. En el registro del sistema se indicará no solo el hecho de la prohibición, sino también la razón y la forma de superar la restricción..

Ejecutamos estos comandos: