Antecedentes de los módulos de seguridad de Linux y SELinux
Security Enhanced Linux es un conjunto de reglas y un mecanismo de acceso basado en modelos de acceso obligatorios y basados en roles para proteger los sistemas Linux de posibles amenazas y corregir las fallas del control de acceso discrecional (DAC), el sistema de seguridad tradicional de Unix. El proyecto se originó en las entrañas de la Agencia de Seguridad Nacional de EE. UU., Principalmente los contratistas Secure Computing Corporation y MITRE, así como varios laboratorios de investigación, participaron directamente en el desarrollo.

Módulos de seguridad de Linux
Linus Torvalds ha hecho varios comentarios sobre los nuevos desarrollos de la NSA para que puedan incluirse en el kernel de Linux ascendente. Describió un entorno general, con un conjunto de interceptores para gestionar operaciones con objetos y un conjunto de algunos campos de protección en las estructuras de datos del kernel para almacenar los atributos correspondientes. Este entorno puede luego ser utilizado por módulos de kernel cargables para implementar cualquier modelo de seguridad deseado. LSM se incorporó por completo al kernel de Linux v2.6 en 2003.
El marco LSM incluye campos de protección en estructuras de datos y llamadas para interceptar funciones en puntos críticos del código del kernel para administrarlos y realizar control de acceso. También agrega funcionalidad para registrar módulos de seguridad. La interfaz / sys / kernel / security / lsm contiene una lista de módulos activos en el sistema. Los ganchos LSM se almacenan en listas, que se llaman en el orden especificado en CONFIG_LSM. La documentación detallada del gancho se incluye en el archivo de encabezado include / linux / lsm_hooks.h.
El subsistema LSM permitió la integración completa de SELinux del mismo kernel estable de Linux v2.6. Casi de inmediato, SELinux se convirtió en el estándar de facto para entornos Linux seguros y se convirtió en parte de las distribuciones más populares: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.
Glosario de SELinux
- — SELinux , Unix/Linux user id, , . Linux SELinux. SELinux , , — .
- — SELinux , . . . , . — , . : sysadm_t , user_t, . init init_t, named named_t.
- — , SELinux. , . . Role Based Access Control (RBAC), SELinux.
- — Type Enforcement, , . , , , , , , . .
- — , . : , , ., , , — .
- SELinux — SELinux . SELinux , — — . , . .
LSM SELinux
A pesar del nombre, los LSM generalmente no son módulos cargables de Linux. Sin embargo, al igual que SELinux, está directamente integrado en el kernel. Cualquier cambio en el 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 kernel; de lo contrario, el código LSM no se activará después del arranque. Aun así, se puede habilitar con la opción de cargador de arranque del sistema operativo.

Pila de cheques LSM
LSM está equipado con ganchos en las funciones básicas que pueden ser relevantes para los cheques. Una de las principales características de los LSM es que están apilados. Por lo tanto, se siguen realizando las comprobaciones estándar y cada capa de LSM solo agrega controles y controles adicionales. Esto significa que la prohibición no se puede revertir. Esto se muestra en la figura, si el resultado de las comprobaciones de rutina del DAC es un error, ni siquiera llegará a los ganchos LSM.
SELinux ha adoptado la arquitectura de seguridad Flask del sistema operativo de investigación de Fluke, en particular el principio de privilegio mínimo. La esencia de este concepto, como su nombre lo indica, es otorgar a un usuario o procesar solo aquellos derechos que son necesarios para llevar a cabo las acciones previstas. Este principio se implementa mediante la escritura forzada de acceso, por lo que el control de admisión de SELinux se basa en el modelo de dominio => tipo.
Debido a la escritura forzada de acceso, SELinux tiene capacidades de control de acceso mucho más significativas que el modelo DAC tradicional usado en el sistema operativo Unix / Linux. Por ejemplo, puede restringir el número de puerto de red que le pasará al servidor ftp, permitir escribir y cambiar archivos en una carpeta específica, pero no borrarlos.
Los principales componentes de SELinux son:
- Servidor de aplicación de políticas : el mecanismo principal para organizar el control de acceso.
- Base de datos de políticas de seguridad del sistema.
- Interacción con el interceptor de eventos LSM.
- Selinuxfs : Pseudo-FS, igual que / proc y montado en / sys / fs / selinux. Se llena dinámicamente por el kernel de Linux en tiempo de ejecución y contiene archivos que contienen información de estado de SELinux.
- Access Vector Cache - Ayudante de rendimiento.
Cómo funciona SELinux
Todo esto funciona de la siguiente manera.
- Un sujeto determinado, en términos de SELinux, realiza una acción permitida en un objeto después de una verificación DAC, como se muestra en la imagen superior. Esta solicitud para realizar la operación va al interceptor de eventos LSM.
- Desde allí, la solicitud, junto con el contexto de seguridad del sujeto y el objeto, se pasa al módulo SELinux Abstraction and Hook Logic, que es responsable de interactuar con el LSM.
- El Policy Enforcement Server es la instancia para tomar una decisión sobre el acceso del sujeto al objeto, y los datos de SELinux AnHL llegan a él.
- Para tomar una decisión sobre el acceso o la denegación, Policy Enforcement Server consulta el subsistema de almacenamiento en caché de las reglas de caché de vector de acceso (AVC) más utilizadas.
- Si no se encuentra una solución para la regla correspondiente en el caché, la solicitud se pasa a la base de datos de políticas de seguridad.
- El resultado de la búsqueda de DB y AVC se devuelve al servidor de cumplimiento de políticas.
- Si la política encontrada es coherente con la acción solicitada, se permite la operación. De lo contrario, la operación está prohibida.
Administrar la configuración de SELinux
SELinux opera en uno de tres modos:
- Cumplimiento: estricto cumplimiento de las políticas de seguridad.
- Permisivo: se permite la violación de las restricciones, la marca correspondiente se realiza en el registro.
- Deshabilitado: las políticas de seguridad no están en vigor.
Puede ver en qué modo se encuentra SELinux con el siguiente comando.
[admin@server ~]$ getenforce
Permissive
Cambiando el modo antes de reiniciar, por ejemplo, configúrelo en forzado, o 1. El parámetro permisivo corresponde al código numérico 0.
[admin@server ~]$ setenfoce enforcing
[admin@server ~]$ setenfoce 1 #
También 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 = targette
La diferencia con setenfoce es que cuando se inicia el sistema operativo, el modo SELinux se configurará de acuerdo con el valor del parámetro SELINUX del archivo de configuración. Además, los cambios para hacer cumplir <=> disabled tienen efecto solo mediante la edición del archivo / etc / selinux / config y después de un reinicio.
Ver un breve informe de estado:
[admin@server ~]$ sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 31
Algunas de las utilidades nativas usan el parámetro -Z para ver los atributos de SELinux.
[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 habitual de ls -l, hay varios campos adicionales en el siguiente formato:
<user>:<role>:<type>:<level>
El último campo denota algo así como un sello de secreto y consta de una combinación de dos elementos:
- s0 - importancia, también escrito como intervalo de nivel bajo-alto
- c0, c1… c1023 - categoría.
Cambio de configuración de acceso
Utilice semodule para cargar módulos SELinux, agregarlos y eliminarlos.
[admin@server ~]$ semodule -l |wc -l #
408
[admin@server ~]$ semodule -e abrt #enable -
[admin@server ~]$ semodule -d accountsd #disable -
[admin@server ~]$ semodule -r avahi #remove -
El primer comando, semanage login, vincula al 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 asignación de los usuarios de SELinux a las cuentas del sistema operativo. En la sección anterior se encuentra una explicación de la sintaxis de los valores de rango MLS / MCS.
[admin@server ~]$ semanage login -a -s user_u karol
[admin@server ~]$ semanage login -l
Login Name SELinux User MLS/MCS Range Service
__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
El comando de usuario semanage se usa para administrar las asignaciones entre los usuarios y roles de SELinux.
[admin@server ~]$ semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
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 de comando:
- -a agregar una entrada de asignación de roles personalizada;
- -l lista de correspondencia entre usuarios y roles;
- -d eliminar la entrada de asignación de roles definida por el usuario;
- -R lista de roles asignados al usuario;
Archivos, puertos y valores booleanos
Cada módulo SELinux proporciona un conjunto de reglas para marcar archivos, pero también puede agregar sus propias reglas si es necesario. Por ejemplo, queremos que el servidor web tenga derechos de acceso 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 las nuevas reglas de marcado y el segundo restablece, o más bien establece, los tipos de archivos de acuerdo con las reglas actuales.
Asimismo, los puertos TCP / UDP están marcados de tal manera que solo los servicios correspondientes puedan escucharlos. Por ejemplo, para que el servidor web escuche en el puerto 8080, debe ejecutar el comando.
[admin@server ~]$ semanage port -m -t http_port_t -p tcp 8080
Un número significativo de módulos SELinux tienen parámetros que pueden tomar valores booleanos. La lista completa de dichos parámetros se puede ver con getsebool -a. Puede cambiar los valores booleanos 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_cgi
httpd_enable_homedirs --> off
Workshop, Acceda a la interfaz web de Pgadmin
Considere un ejemplo de la práctica, instalamos en RHEL 7.6 pgadmin4-web para la administración de bases de datos PostgreSQL. Pasamos por una pequeña búsqueda con la configuración de pg_hba.conf, postgresql.conf y config_local.py, establecimos los derechos de las carpetas e instalamos los módulos de Python faltantes de pip. Todo está listo, ejecútelo y obtendrá el error 500 Internal Server .
Comenzando con los sospechosos típicos, revisando / var / log / httpd / error_log. Allí hay algunas entradas interesantes. En este punto, la mayoría de los administradores de Linux se verán tentados a ejecutar setencorce 0, y eso es todo. Francamente, la primera vez que lo hice. Esto, por supuesto, también es una salida, pero está lejos de ser la mejor.
[timestamp] [core:notice] [pid 23689] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
...
[timestamp] [wsgi:error] [pid 23690] [Errno 13] Permission denied: '/var/lib/pgadmin'
[timestamp] [wsgi:error] [pid 23690]
[timestamp] [wsgi:error] [pid 23690] HINT : You may need to manually set the permissions on
[timestamp] [wsgi:error] [pid 23690] /var/lib/pgadmin to allow apache to write to it.
A pesar de su diseño engorroso, SELinux puede ser fácil de usar. Basta con instalar el paquete setroubleshoot y ver el registro del sistema. Tenga en cuenta que el servicio auditd debe reiniciarse de esta manera, y sin usar systemctl, a pesar de la presencia de systemd en el sistema operativo. El registro del sistema indicará no solo el hecho del bloqueo, sino también el motivo y la forma de superar la prohibición . Ejecutamos estos comandos: Comprobamos el acceso a la página web pgadmin4-web, todo funciona.
[admin@server ~]$ yum install setroubleshoot
[admin@server ~]$ journalctl -b -0
[admin@server ~]$ service restart auditd
[admin@server ~]$ setsebool -P httpd_can_network_connect 1
[admin@server ~]$ setsebool -P httpd_can_network_connect_db 1
