Red Hat Training

A Red Hat training course is available for RHEL 8

Capítulo 16. Uso de SELinux

16.1. Introducción a SELinux

16.1.1. Introducción a SELinux

Security Enhanced Linux (SELinux) proporciona una capa adicional de seguridad del sistema. SELinux responde fundamentalmente a la pregunta: May <subject> do <action> to <object>?, por ejemplo May a web server access files in users' home directories?

La política de acceso estándar basada en el usuario, el grupo y otros permisos, conocida como Control de Acceso Discrecional (DAC), no permite a los administradores del sistema crear políticas de seguridad completas y de grano fino, como restringir aplicaciones específicas para que sólo vean los archivos de registro, mientras que se permite a otras aplicaciones añadir nuevos datos a los archivos de registro.

SELinux implementa el Control de Acceso Obligatorio (MAC). Cada proceso y recurso del sistema tiene una etiqueta de seguridad especial llamada SELinux context. Un contexto de SELinux, a veces denominado SELinux label, es un identificador que abstrae los detalles a nivel de sistema y se centra en las propiedades de seguridad de la entidad. Esto no sólo proporciona una forma consistente de referenciar objetos en la política de SELinux, sino que también elimina cualquier ambigüedad que pueda encontrarse en otros métodos de identificación. Por ejemplo, un archivo puede tener múltiples nombres de ruta válidos en un sistema que hace uso de montajes bind.

La política de SELinux utiliza estos contextos en una serie de reglas que definen cómo los procesos pueden interactuar entre sí y con los distintos recursos del sistema. Por defecto, la política no permite ninguna interacción a menos que una regla conceda explícitamente el acceso.

Nota

Recuerda que las reglas de política de SELinux se comprueban después de las reglas DAC. Las reglas de política de SELinux no se utilizan si las reglas DAC deniegan el acceso primero, lo que significa que no se registra ninguna denegación de SELinux si las reglas DAC tradicionales impiden el acceso.

Los contextos de SELinux tienen varios campos: usuario, rol, tipo y nivel de seguridad. La información del tipo de SELinux es quizás la más importante cuando se trata de la política de SELinux, ya que la regla de política más común que define las interacciones permitidas entre los procesos y los recursos del sistema utiliza los tipos de SELinux y no el contexto completo de SELinux. Los tipos de SELinux terminan con _t. Por ejemplo, el nombre del tipo para el servidor web es httpd_t. El contexto de tipo para los archivos y directorios que normalmente se encuentran en /var/www/html/ es httpd_sys_content_t. El contexto de tipo para los archivos y directorios que normalmente se encuentran en /tmp y /var/tmp/ es tmp_t. El contexto de tipo para los puertos del servidor web es http_port_t.

Hay una regla de política que permite a Apache (el proceso del servidor web que se ejecuta como httpd_t) acceder a los archivos y directorios con un contexto que normalmente se encuentra en /var/www/html/ y otros directorios del servidor web (httpd_sys_content_t). No hay ninguna regla de permiso en la política para los archivos que normalmente se encuentran en /tmp y /var/tmp/, por lo que el acceso no está permitido. Con SELinux, incluso si Apache está comprometido, y un script malicioso obtiene acceso, todavía no es capaz de acceder al directorio /tmp.

Figura 16.1. Un ejemplo de cómo SELinux puede ayudar a ejecutar Apache y MariaDB de forma segura.

SELinux_Apache_MariaDB_example

Como muestra el esquema anterior, SELinux permite que el proceso de Apache que se ejecuta como httpd_t acceda al directorio /var/www/html/ y le niega al mismo proceso el acceso al directorio /data/mysql/ porque no existe una regla de permiso para los contextos de tipo httpd_t y mysqld_db_t. Por otro lado, el proceso de MariaDB que se ejecuta como mysqld_t puede acceder al directorio /data/mysql/ y SELinux también deniega correctamente al proceso con el tipo mysqld_t el acceso al directorio /var/www/html/ etiquetado como httpd_sys_content_t.

Recursos adicionales

Para más información, consulte la siguiente documentación:

16.1.2. Ventajas de ejecutar SELinux

SELinux proporciona los siguientes beneficios:

  • Todos los procesos y archivos están etiquetados. Las reglas de política de SELinux definen cómo los procesos interactúan con los archivos, así como cómo los procesos interactúan entre sí. Sólo se permite el acceso si existe una regla de política de SELinux que lo permita específicamente.
  • Control de acceso detallado. Más allá de los permisos tradicionales de UNIX, que se controlan a discreción del usuario y se basan en los ID de usuario y grupo de Linux, las decisiones de acceso de SELinux se basan en toda la información disponible, como un usuario, un rol, un tipo y, opcionalmente, un nivel de seguridad de SELinux.
  • La política de SELinux se define administrativamente y se aplica en todo el sistema.
  • Mejora de la mitigación de los ataques de escalada de privilegios. Los procesos se ejecutan en dominios y, por tanto, están separados unos de otros. Las reglas de política de SELinux definen cómo los procesos acceden a los archivos y a otros procesos. Si un proceso se ve comprometido, el atacante sólo tiene acceso a las funciones normales de ese proceso, y a los archivos a los que el proceso ha sido configurado para tener acceso. Por ejemplo, si el Servidor HTTP Apache está comprometido, un atacante no puede usar ese proceso para leer archivos en los directorios personales de los usuarios, a menos que una regla de política SELinux específica haya sido agregada o configurada para permitir ese acceso.
  • SELinux puede utilizarse para reforzar la confidencialidad e integridad de los datos, así como para proteger los procesos de las entradas no fiables.

Sin embargo, SELinux no lo es:

  • software antivirus,
  • reemplazo de contraseñas, cortafuegos y otros sistemas de seguridad,
  • solución de seguridad todo en uno.

SELinux está diseñado para mejorar las soluciones de seguridad existentes, no para sustituirlas. Incluso cuando se ejecuta SELinux, es importante seguir las buenas prácticas de seguridad, como mantener el software actualizado, utilizar contraseñas difíciles de adivinar y cortafuegos.

16.1.3. Ejemplos de SELinux

Los siguientes ejemplos demuestran cómo SELinux aumenta la seguridad:

  • La acción por defecto es denegar. Si no existe una regla de política de SELinux que permita el acceso, como por ejemplo para un proceso que abre un archivo, el acceso se deniega.
  • SELinux puede confinar a los usuarios de Linux. Existen varios usuarios confinados de SELinux en la política de SELinux. Los usuarios de Linux pueden ser asignados a usuarios confinados de SELinux para aprovechar las reglas y mecanismos de seguridad aplicados a ellos. Por ejemplo, mapear un usuario de Linux al usuario de SELinux user_u, da como resultado un usuario de Linux que no es capaz de ejecutar, a menos que se configure de otra manera, aplicaciones con ID de usuario (setuid), como sudo y su, además de evitar que ejecuten archivos y aplicaciones potencialmente maliciosas en su directorio raíz.
  • Mayor separación de procesos y datos. El concepto de SELinux domains permite definir qué procesos pueden acceder a determinados archivos y directorios. Por ejemplo, cuando se ejecuta SELinux, a menos que se configure de otra manera, un atacante no puede comprometer un servidor Samba, y luego utilizar ese servidor Samba como un vector de ataque para leer y escribir en archivos utilizados por otros procesos, como las bases de datos MariaDB.
  • SELinux ayuda a mitigar los daños causados por los errores de configuración. Los servidores del Sistema de Nombres de Dominio (DNS) suelen replicar la información entre ellos en lo que se conoce como transferencia de zona. Los atacantes pueden utilizar las transferencias de zona para actualizar los servidores DNS con información falsa. Cuando se ejecuta el Berkeley Internet Name Domain (BIND) como un servidor DNS en Red Hat Enterprise Linux, incluso si un administrador se olvida de limitar qué servidores pueden realizar una transferencia de zona, la política SELinux por defecto evita que los archivos de zona [2] sean actualizados mediante transferencias de zona, por el propio demonio BIND named y por otros procesos.

16.1.4. Arquitectura y paquetes SELinux

SELinux es un módulo de seguridad de Linux (LSM) que está integrado en el núcleo de Linux. El subsistema de SELinux en el kernel está dirigido por una política de seguridad que es controlada por el administrador y cargada en el arranque. Todas las operaciones de acceso a nivel de kernel relevantes para la seguridad en el sistema son interceptadas por SELinux y examinadas en el contexto de la política de seguridad cargada. Si la política cargada permite la operación, ésta continúa. En caso contrario, la operación se bloquea y el proceso recibe un error.

Las decisiones de SELinux, como permitir o no el acceso, se almacenan en la caché. Esta caché se conoce como Access Vector Cache (AVC). Cuando se utilizan estas decisiones en caché, las reglas de política de SELinux necesitan ser comprobadas menos, lo que aumenta el rendimiento. Recuerda que las reglas de política de SELinux no tienen efecto si las reglas DAC deniegan el acceso primero. Los mensajes de auditoría sin procesar se registran en /var/log/audit/audit.log y comienzan con la cadena type=AVC.

En Red Hat Enterprise Linux 8, los servicios del sistema son controlados por el demonio systemd; systemd inicia y detiene todos los servicios, y los usuarios y procesos se comunican con systemd usando la utilidad systemctl. El demonio systemd puede consultar la política de SELinux y comprobar la etiqueta del proceso que llama y la etiqueta del archivo de la unidad que la persona que llama intenta gestionar, y luego preguntar a SELinux si la persona que llama tiene o no permiso de acceso. Este enfoque refuerza el control de acceso a las capacidades críticas del sistema, que incluyen el inicio y la detención de los servicios del sistema.

El demonio systemd también funciona como un gestor de acceso de SELinux. Recupera la etiqueta del proceso que ejecuta systemctl o el proceso que envió un mensaje D-Bus a systemd. El demonio busca entonces la etiqueta del archivo de unidad que el proceso quería configurar. Finalmente, systemd puede recuperar información del kernel si la política SELinux permite el acceso específico entre la etiqueta del proceso y la etiqueta del archivo de unidad. Esto significa que una aplicación comprometida que necesita interactuar con systemd para un servicio específico puede ahora ser confinada por SELinux. Los escritores de políticas también pueden utilizar estos controles de grano fino para confinar a los administradores.

Importante

Para evitar un etiquetado incorrecto de SELinux y los problemas subsiguientes, asegúrese de iniciar los servicios utilizando un comando systemctl start.

Red Hat Enterprise Linux 8 proporciona los siguientes paquetes para trabajar con SELinux:

  • políticas: selinux-policy-targeted, selinux-policy-mls
  • herramientas: policycoreutils, policycoreutils-gui, libselinux-utils, policycoreutils-python-utils, setools-console, checkpolicy

16.1.5. Estados y modos de SELinux

SELinux puede ejecutarse en uno de los tres modos: reforzado, permisivo o deshabilitado.

  • El modo de aplicación es el modo de operación por defecto, y el recomendado; en el modo de aplicación SELinux opera normalmente, aplicando la política de seguridad cargada en todo el sistema.
  • En el modo permisivo, el sistema actúa como si SELinux estuviera aplicando la política de seguridad cargada, incluyendo el etiquetado de objetos y la emisión de entradas de denegación de acceso en los registros, pero en realidad no deniega ninguna operación. Aunque no se recomienda para sistemas de producción, el modo permisivo puede ser útil para el desarrollo y depuración de políticas de SELinux.
  • Se desaconseja encarecidamente el modo deshabilitado; el sistema no sólo evita aplicar la política de SELinux, sino que también evita etiquetar cualquier objeto persistente, como los archivos, lo que dificulta la habilitación de SELinux en el futuro.

Utilice la utilidad setenforce para cambiar entre el modo de aplicación y el modo permisivo. Los cambios realizados con setenforce no persisten a través de los reinicios. Para cambiar al modo obligatorio, introduzca el comando setenforce 1 como usuario root de Linux. Para cambiar al modo permisivo, introduzca el comando setenforce 0. Utilice la utilidad getenforce para ver el modo SELinux actual:

# getenforce
Enforcing
# setenforce 0
# getenforce
Permissive
# setenforce 1
# getenforce
Enforcing

En Red Hat Enterprise Linux, puede poner dominios individuales en modo permisivo mientras el sistema se ejecuta en modo forzoso. Por ejemplo, para hacer que el dominio httpd_t sea permisivo:

# semanage permissive -a httpd_t

Tenga en cuenta que los dominios permisivos son una herramienta poderosa que puede comprometer la seguridad de su sistema. Red Hat recomienda utilizar los dominios permisivos con precaución, por ejemplo, al depurar un escenario específico.



[2] Archivos de texto que incluyen información, como mapeos de nombres de host a direcciones IP, que son utilizados por los servidores DNS.