🥇Sistemas de Seguridad Linux

Una de las razones del tremendo éxito del sistema operativo Linux en servidores y dispositivos móviles integrados es el grado relativamente alto de seguridad del kernel, los servicios relacionados y las aplicaciones. Pero si mira más de cerca a la arquitectura del kernel de Linux, entonces es imposible encontrar en él un cuadrado responsable de la seguridad, como tal. ¿Dónde se esconde el subsistema de seguridad de Linux y en qué consiste?

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 los modelos de acceso obligatorio y basado en roles para proteger los sistemas Linux de amenazas potenciales y corregir las debilidades 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., y los contratistas Secure Computing Corporation y MITRE, así como varios laboratorios de investigación, estuvieron directamente involucrados en el desarrollo.

Módulos de seguridad de Linux

Linus Torvalds contribuyó con una serie de notas sobre los nuevos desarrollos de la NSA para que pudieran incluirse en la rama principal del kernel de Linux. Describió un entorno común, con un conjunto de interceptores para administrar operaciones en 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 ser utilizado por módulos de kernel cargables para implementar cualquier modelo de seguridad deseado. LSM ingresó por completo al kernel de Linux v2.6 en 2003.

El marco LSM incluye campos de protección en estructuras de datos y llamadas a funciones de intercepción en puntos críticos del código del kernel para administrarlos y realizar el 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 de ganchos se incluye en el archivo de encabezado include/linux/lsm_hooks.h.

El subsistema LSM hizo posible completar la integración completa de SELinux de la misma versión del kernel estable de Linux v2.6. Literalmente de inmediato, SELinux se convirtió en el estándar de facto para un entorno Linux seguro y se convirtió en parte de las distribuciones más populares: RedHat Enterprise Linux, Fedora, Debian, Ubuntu.

Glosario

Identidad - El usuario de SELinux no es el mismo que el usuario habitual de Unix/Linux, pueden coexistir en el mismo sistema, pero son completamente diferentes en esencia. Cada cuenta estándar de Linux puede corresponder a una o más en SELinux. La identidad de SELinux es parte del contexto de seguridad general que determina a qué dominios puede y no puede unirse.
dominios - En SELinux, el dominio es el contexto de ejecución del sujeto, es decir, el proceso. El dominio define directamente el acceso que tiene un proceso. Un dominio es básicamente una lista de qué procesos pueden hacer o qué acciones puede hacer un proceso con diferentes tipos. Algunos ejemplos de dominios son sysadm_t para la administración del sistema y user_t, que es un dominio de usuario regular sin privilegios. El sistema init se ejecuta en el dominio init_t y el proceso named se ejecuta en el dominio named_t.
Roles - Algo que sirva de intermediario entre los dominios y los usuarios de SELinux. Los roles definen a qué dominios puede pertenecer un usuario y a qué tipos de objetos puede acceder el usuario. Tal mecanismo de control de acceso previene la amenaza de un ataque de escalada de privilegios. Los roles se escriben en el modelo de seguridad de control de acceso basado en roles (RBAC) que se usa en SELinux.
tipos — Escriba el atributo de la lista Cumplimiento que se asigna a un objeto y determina quién tendrá acceso a él. Similar a definir un dominio, excepto que el dominio se aplica al proceso, mientras que el tipo se aplica a objetos como directorios, archivos, sockets, etc.
Sujetos y objetos - Los procesos son sujetos y se ejecutan en un contexto particular, o dominio de seguridad. Los recursos del sistema operativo: archivos, directorios, sockets, etc., son objetos a los que se les asigna un tipo determinado, es decir, un nivel de secreto.
Políticas de SELinux - SELinux utiliza una variedad de políticas para proteger el sistema. La política de SELinux define el acceso de los usuarios a los roles, los roles a los dominios y los dominios a los tipos. Primero, el usuario está autorizado para obtener un rol, luego el rol está autorizado para acceder a los dominios. Finalmente, un dominio solo puede tener acceso a ciertos tipos de objetos.

Arquitectura LSM y SELinux

A pesar del nombre, los LSM generalmente no son módulos de Linux cargables. 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. Pero incluso en este caso, puede habilitarse mediante la opción del cargador de arranque del sistema operativo.

Pila de cheques LSM

LSM está equipado con ganchos en las funciones centrales del núcleo que pueden ser relevantes para las comprobaciones. Una de las características principales de LSM es que están basados en pilas. Por lo tanto, las comprobaciones estándar aún se realizan y cada capa 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 DAC de rutina es un error, ni siquiera llegará a los enlaces LSM.

SELinux adoptó la arquitectura de seguridad Flask del sistema operativo de investigación de Fluke, específicamente el principio de privilegio mínimo. La esencia de este concepto, como su nombre indica, es otorgar al usuario o al proceso solo aquellos derechos que sean necesarios para la implementación de las acciones previstas. Este principio se implementa mediante escritura de acceso forzado, por lo que el control de acceso de SELinux se basa en el modelo de dominio => tipo.

A través de la tipificación de acceso forzada, SELinux tiene capacidades de control de acceso mucho mayores que el modelo DAC tradicional utilizado en los sistemas operativos Unix/Linux. Por ejemplo, puede limitar el número de puerto de red que pasará con el servidor ftp, permitir escribir y cambiar archivos en una determinada carpeta, pero no eliminarlos.

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 detector de eventos LSM.
Selinuxfs - Pseudo-FS, igual que /proc y montado en /sys/fs/selinux. Completado dinámicamente por el kernel de Linux en tiempo de ejecución y contiene archivos que contienen información de estado de SELinux.
Acceder a la caché de vectores - Mecanismo auxiliar para mejorar el rendimiento.

Cómo funciona SELinux

Todo esto funciona de la siguiente manera.

Un sujeto, 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 de operación va al detector 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 responsable de interactuar con el LSM.
El Policy Enforcement Server es la autoridad en la toma de decisiones sobre el acceso del sujeto al objeto y recibe datos de SELinux AnHL.
Para tomar una decisión sobre el acceso o la prohibición, Policy Enforcement Server se refiere al subsistema de almacenamiento en caché de las reglas de Caché de vector de acceso (AVC) más utilizadas.
Si la solución para la regla correspondiente no se encuentra en la memoria caché, la solicitud se pasa a la base de datos de políticas de seguridad.
El resultado de la búsqueda de la base de datos y AVC se devuelve al Policy Enforcement Server.
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 - Cumplimiento estricto de las políticas de seguridad.
Permisivo: se permite una violación de las restricciones, se realiza la marca correspondiente en el registro.
Deshabilitado: las políticas de seguridad no están vigentes.

Puede ver en qué modo está SELinux con el siguiente comando.

[admin@server ~]$ getenforce
Permissive

Cambiando el modo antes de reiniciar, por ejemplo, configúrelo para que se cumpla, 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=objetivo

La diferencia con setenfoce es que cuando se inicia el sistema operativo, el modo SELinux se establecerá de acuerdo con el valor del parámetro SELINUX en el archivo de configuración. Además, la aplicación de <=> cambios deshabilitados solo surtirá efecto al editar el archivo /etc/selinux/config y después de reiniciar.

Ver informe de estado resumido:

[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
Para ver los atributos de SELinux, algunas utilidades de stock usan la opción -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, hay varios campos adicionales en el siguiente formato:

<user>:<role>:<type>:<level>

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

s0 - significado, también registrado en el intervalo de nivel bajo-nivel alto
c0, c1… c1023 es la categoría.

Cambiar la configuración de acceso

Use 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 - удалить модуль

Primer equipo Inicio de sesión semanal asocia un usuario de SELinux con un usuario del sistema operativo, el segundo lo enumera. Finalmente, el último comando con el modificador -r elimina la asignación de usuarios de SELinux a cuentas de SO. Una explicación de la sintaxis de los valores MLS/MCS Range se encuentra en la sección anterior.

[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
Equipo usuario semanal se utiliza para administrar asignaciones entre 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

Opciones de comando:

-a agregar una entrada de asignación de roles personalizada;
-l lista de usuarios y roles coincidentes;
-d elimina la entrada de asignación de funciones personalizada;
-R lista de roles adjuntos al usuario;

Archivos, puertos y booleanos

Cada módulo de SELinux proporciona un conjunto de reglas de marcado de 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 nuevas reglas de marcado y el segundo restablece, o más bien expone, 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 apropiados pueden escuchar en ellos. Por ejemplo, para que un servidor web escuche en el puerto 8080, debe ejecutar un 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 tales opciones se puede ver con getsebool -a. Los valores booleanos se pueden cambiar usando 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

Practicum, acceda a la interfaz web de Pgadmin

Considere un ejemplo de la práctica, instalamos pgadmin7.6-web en RHEL 4 para administrar la base de datos de PostgreSQL. Pasamos un pequeño Búsqueda con la configuración de pg_hba.conf, postgresql.conf y config_local.py, establezca los derechos de las carpetas, instaló los módulos de Python que faltan desde pip. Todo está listo, corre y ponte Error interno de servidor 500.

Comenzamos con los sospechosos típicos, verifique /var/log/httpd/error_log. Hay algunas entradas interesantes allí.

[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.

En este punto, la mayoría de los administradores de Linux se verán fuertemente tentados a ejecutar setencorce 0 y terminar con él. Para ser honesto, esta es la primera vez que lo hago. Esto, por supuesto, también es una salida, pero está lejos de ser la mejor.

A pesar de los diseños engorrosos, SELinux puede ser fácil de usar. Simplemente instale el paquete setroubleshoot y vea 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 con systemctl, a pesar de la presencia de systemd en el sistema operativo. En el registro del sistema será indicado no sólo el hecho de bloquear, sino también la razón y manera de superar la prohibición.

Ejecutamos estos comandos:

[admin@server ~]$ setsebool -P httpd_can_network_connect 1 [admin@server ~]$ setsebool -P httpd_can_network_connect_db 1

Comprobamos el acceso a la página web pgadmin4-web, todo funciona.

Fuente: habr.com

sistemas de seguridad linux