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.

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 1.1. Un ejemplo de cómo SELinux puede ayudar a ejecutar Apache y MariaDB de forma segura.

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.

SELinux proporciona los siguientes beneficios:

Sin embargo, SELinux no lo es:

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.

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

SELinux es un módulo de seguridad de Linux (LSM) que está integrado en el núcleo de Linux. El subsistema 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.

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

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

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.

Como se discute en Estados y modos de SELinux, SELinux puede estar habilitado o deshabilitado. Cuando está habilitado, SELinux tiene dos modos: enforcing y permissive.

Utilice los comandos getenforce o sestatus para comprobar en qué modo se está ejecutando SELinux. El comando getenforce devuelve Enforcing, Permissive, o Disabled.

El comando sestatus devuelve el estado de SELinux y la política de SELinux que se está utilizando:

$ sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      31

Utilice el siguiente procedimiento para cambiar permanentemente el modo de SELinux a permisivo. Cuando SELinux se ejecuta en modo permisivo, la política de SELinux no se aplica. El sistema permanece operativo y SELinux no deniega ninguna operación, sino que sólo registra los mensajes de CVA, que pueden utilizarse para la resolución de problemas, la depuración y la mejora de la política de SELinux. Cada CVA se registra sólo una vez en este caso.

Utilice el siguiente procedimiento para cambiar SELinux al modo de aplicación. Cuando SELinux se ejecuta en modo de aplicación, aplica la política de SELinux y deniega el acceso basándose en las reglas de la política de SELinux. En RHEL, el modo de aplicación está activado por defecto cuando el sistema se instaló inicialmente con SELinux.

# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today

# grep "SELinux is preventing" /var/log/messages

# dmesg | grep -i -e type=1300 -e type=1400

Cuando habilite SELinux en sistemas que lo tenían previamente deshabilitado, para evitar problemas, como que los sistemas no puedan arrancar o que se produzcan fallos en los procesos, siga este procedimiento:

Utilice el siguiente procedimiento para desactivar SELinux de forma permanente.

En el arranque, puedes establecer varios parámetros del kernel para cambiar la forma en que SELinux se ejecuta:

Cada usuario de Linux se asigna a un usuario de SELinux utilizando la política de SELinux. Esto permite que los usuarios de Linux hereden las restricciones de los usuarios de SELinux.

Para ver la asignación de usuarios de SELinux en su sistema, utilice el comando semanage login -l como root:

# 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       *

En Red Hat Enterprise Linux, los usuarios de Linux son asignados al login SELinux default por defecto, el cual está mapeado al usuario de SELinux unconfined_u. La siguiente línea define el mapeo por defecto:

__default__          unconfined_u         s0-s0:c0.c1023       *

Los usuarios confinados y no confinados de Linux están sujetos a comprobaciones de memoria ejecutable y escribible, y también están restringidos por MCS o MLS.

Para listar los usuarios de SELinux disponibles, introduzca el siguiente comando:

$ seinfo -u
Users: 8
   guest_u
   root
   staff_u
   sysadm_u
   system_u
   unconfined_u
   user_u
   xguest_u

Tenga en cuenta que el comando seinfo lo proporciona el paquete setools-console, que no está instalado por defecto.

Si un usuario de Linux no confinado ejecuta una aplicación que la política de SELinux define como una que puede pasar del dominio unconfined_t a su propio dominio confinado, el usuario de Linux no confinado sigue estando sujeto a las restricciones de ese dominio confinado. El beneficio de seguridad de esto es que, aunque un usuario de Linux esté ejecutando sin confinar, la aplicación permanece confinada. Por lo tanto, la explotación de una falla en la aplicación puede ser limitada por la política.

Del mismo modo, podemos aplicar estas comprobaciones a los usuarios confinados. Cada usuario confinado está restringido por un dominio de usuario confinado. La política de SELinux también puede definir una transición de un dominio de usuario confinado a su propio dominio confinado de destino. En tal caso, los usuarios confinados están sujetos a las restricciones de ese dominio confinado de destino. El punto principal es que se asocian privilegios especiales a los usuarios confinados según su rol.

La siguiente tabla proporciona ejemplos de dominios confinados básicos para usuarios de Linux en Red Hat Enterprise Linux:

Tenga en cuenta que system_u es una identidad de usuario especial para los procesos y objetos del sistema. Nunca debe asociarse a un usuario de Linux. Además, unconfined_u y root son usuarios no confinados. Por estas razones, no están incluidos en la tabla anterior de capacidades de usuario de SELinux.

Junto con los usuarios de SELinux ya mencionados, hay roles especiales, que pueden ser asignados a esos usuarios usando el comando semanage user. Estos roles determinan lo que SELinux permite hacer al usuario:

Para listar todos los roles disponibles, introduzca el comando seinfo -r:

$ seinfo -r
Roles: 14
   auditadm_r
   dbadm_r
   guest_r
   logadm_r
   nx_server_r
   object_r
   secadm_r
   staff_r
   sysadm_r
   system_r
   unconfined_r
   user_r
   webadm_r
   xguest_r

Tenga en cuenta que el comando seinfo lo proporciona el paquete setools-console, que no está instalado por defecto.

El siguiente procedimiento demuestra cómo añadir un nuevo usuario Linux al sistema. El usuario se asigna automáticamente al usuario de SELinux unconfined_u.

Utiliza los siguientes pasos para añadir un nuevo usuario confinado en SELinux al sistema. Este procedimiento de ejemplo asigna el usuario al derecho de usuario de SELinux staff_u con el comando para crear la cuenta de usuario.

Por defecto, todos los usuarios de Linux en Red Hat Enterprise Linux, incluyendo los usuarios con privilegios administrativos, son asignados al usuario no confinado de SELinux unconfined_u. Puede mejorar la seguridad del sistema asignando usuarios a usuarios confinados de SELinux. Esto es útil para cumplir con la Guía de Implementación Técnica de Seguridad V-71971. Para más información acerca de los usuarios confinados y no confinados, consulte Gestión de usuarios confinados y no confinados.

Puede configurar el servidor HTTP Apache para que escuche en un puerto diferente y proporcione contenido en un directorio no predeterminado. Para evitar las consiguientes denegaciones de SELinux, siga los pasos de este procedimiento para ajustar la política de SELinux de su sistema.

Puedes cambiar partes de la política de SELinux en tiempo de ejecución utilizando booleanos, incluso sin tener conocimiento de la escritura de la política de SELinux. Esto permite realizar cambios, como permitir el acceso de servicios a volúmenes NFS, sin necesidad de recargar o recompilar la política de SELinux. El siguiente procedimiento demuestra el listado de booleanos de SELinux y su configuración para lograr los cambios requeridos en la política.

Los montajes NFS en el lado del cliente se etiquetan con un contexto por defecto definido por una política para volúmenes NFS. En RHEL, este contexto por defecto utiliza el tipo nfs_t. Asimismo, los recursos compartidos de Samba montados en el lado del cliente se etiquetan con un contexto predeterminado definido por la política. Este contexto por defecto utiliza el tipo cifs_t. Puede habilitar o deshabilitar booleanos para controlar qué servicios pueden acceder a los tipos nfs_t y cifs_t.

Para permitir que el servicio de servidor HTTP Apache (httpd) acceda y comparta volúmenes NFS y CIFS, realice los siguientes pasos:

Siga sólo los pasos necesarios de este procedimiento; en la mayoría de los casos, sólo tendrá que realizar el paso 1.

Después de identificar que SELinux está bloqueando su escenario, es posible que tenga que analizar la causa raíz antes de elegir una solución.

En la mayoría de los casos, las sugerencias proporcionadas por la herramienta sealert le dan la orientación correcta sobre cómo solucionar los problemas relacionados con la política de SELinux. Consulte Análisis de los mensajes de denegación de SELinux para obtener información sobre cómo utilizar sealert para analizar las denegaciones de SELinux.

Tenga cuidado cuando la herramienta sugiere usar la herramienta audit2allow para los cambios de configuración. No debe utilizar audit2allow para generar un módulo de política local como primera opción cuando vea una denegación de SELinux. La resolución de problemas debe comenzar con una comprobación de si hay un problema de etiquetado. El segundo caso más frecuente es que hayas cambiado la configuración de un proceso, y hayas olvidado avisar a SELinux de ello.

# semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"

Este comando semanage agrega el contexto para el directorio /srv/myweb/ y todos los archivos y directorios bajo él a la configuración del contexto de archivos de SELinux. La utilidad semanage no cambia el contexto. Como root, utilice la utilidad restorecon para aplicar los cambios:

# restorecon -R -v /srv/myweb

$ matchpathcon -V /var/www/html/*
/var/www/html/index.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0
/var/www/html/page1.html has context unconfined_u:object_r:user_home_t:s0, should be system_u:object_r:httpd_sys_content_t:s0

En este ejemplo, los archivos index.html y page1.html están etiquetados con el tipo user_home_t. Este tipo se utiliza para los archivos de los directorios personales de los usuarios. Si se utiliza el comando mv para mover archivos desde el directorio personal, los archivos pueden ser etiquetados con el tipo user_home_t. Este tipo no debería existir fuera de los directorios personales. Utilice la utilidad restorecon para restaurar dichos archivos a su tipo correcto:

# restorecon -v /var/www/html/index.html
restorecon reset /var/www/html/index.html context unconfined_u:object_r:user_home_t:s0->system_u:object_r:httpd_sys_content_t:s0

Para restaurar el contexto de todos los archivos de un directorio, utilice la opción -R:

# restorecon -R -v /var/www/html/
restorecon reset /var/www/html/page1.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0
restorecon reset /var/www/html/index.html context unconfined_u:object_r:samba_share_t:s0->system_u:object_r:httpd_sys_content_t:s0

Por ejemplo, para permitir que el servidor HTTP Apache se comunique con MariaDB, active el booleano httpd_can_network_connect_db:

# setsebool -P httpd_can_network_connect_db on

Tenga en cuenta que la opción -P hace que la configuración persista a través de los reinicios del sistema.

Si se deniega el acceso a un servicio concreto, utiliza las utilidades getsebool y grep para ver si hay algún booleano que permita el acceso. Por ejemplo, utilice el comando getsebool -a | grep ftp para buscar booleanos relacionados con FTP:

$ getsebool -a | grep ftp
ftpd_anon_write --> off
ftpd_full_access --> off
ftpd_use_cifs --> off
ftpd_use_nfs --> off

ftpd_connect_db --> off
httpd_enable_ftp_server --> off
tftp_anon_write --> off

Para obtener una lista de booleanos y saber si están activados o desactivados, utilice el comando getsebool -a. Para obtener una lista de booleanos con su significado y saber si están activados o desactivados, instale el paquete selinux-policy-devel y utilice el comando semanage boolean -l como root.

# semanage port -l | grep http
http_cache_port_t              tcp      3128, 8080, 8118
http_cache_port_t              udp      3130
http_port_t                    tcp      80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t            tcp      5988
pegasus_https_port_t           tcp      5989

El tipo de puerto http_port_t define los puertos en los que puede escuchar el Servidor HTTP Apache, que en este caso son los puertos TCP 80, 443, 488, 8008, 8009 y 8443. Si un administrador configura httpd.conf para que httpd escuche en el puerto 9876 (Listen 9876), pero la política no se actualiza para reflejar esto, el siguiente comando falla:

# systemctl start httpd.service
Job for httpd.service failed. See 'systemctl status httpd.service' and 'journalctl -xn' for details.

# systemctl status httpd.service
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled)
   Active: failed (Result: exit-code) since Thu 2013-08-15 09:57:05 CEST; 59s ago
  Process: 16874 ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop (code=exited, status=0/SUCCESS)
  Process: 16870 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)

Un mensaje de denegación de SELinux similar al siguiente se registra en /var/log/audit/audit.log:

type=AVC msg=audit(1225948455.061:294): avc:  denied  { name_bind } for  pid=4997 comm="httpd" src=9876 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:port_t:s0 tclass=tcp_socket

Para permitir que httpd escuche en un puerto que no está listado para el tipo de puerto http_port_t, utilice el comando semanage port para asignar una etiqueta diferente al puerto:

# semanage port -a -t http_port_t -p tcp 9876

La opción -a añade un nuevo registro; la opción -t define un tipo; y la opción -p define un protocolo. El último argumento es el número de puerto a añadir.

Para estas situaciones, después de que se deniegue el acceso, utilice la utilidad audit2allow para crear un módulo de política personalizado que permita el acceso. Puedes informar de las reglas que faltan en la política de SELinux en Red Hat Bugzilla. Para Red Hat Enterprise Linux 8, cree errores contra el producto Red Hat Enterprise Linux 8 y seleccione el componente selinux-policy. Incluya la salida de los comandos audit2allow -w -a y audit2allow -a en dichos informes de errores.

Si una aplicación pide privilegios de seguridad importantes, podría ser una señal de que la aplicación está comprometida. Utilice herramientas de detección de intrusos para inspeccionar ese comportamiento sospechoso.

La página web Solution Engine en el Portal del Cliente de Red Hat también puede proporcionar orientación en forma de un artículo que contiene una posible solución para el mismo problema o uno muy similar que usted tiene. Seleccione el producto y la versión pertinentes y utilice palabras clave relacionadas con SELinux, como selinux o avc, junto con el nombre de su servicio o aplicación bloqueada, por ejemplo: selinux samba.

El sistema de Auditoría de Linux almacena por defecto las entradas de registro en el archivo /var/log/audit/audit.log. Para listar sólo los registros relacionados con SELinux, utilice el comando ausearch con el parámetro de tipo de mensaje establecido en AVC y AVC_USER como mínimo, por ejemplo:

# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR

Una entrada de denegación de SELinux en el archivo de registro de auditoría puede tener el siguiente aspecto:

type=AVC msg=audit(1395177286.929:1638): avc:  denied  { read } for  pid=6591 comm="httpd" name="webpages" dev="0:37" ino=2112 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir

Las partes más importantes de esta entrada son:

La entrada de registro anterior puede traducirse en:

SELinux denied the httpd process with PID 6591 and the httpd_t type to read from a directory with the nfs_t type.

El siguiente mensaje de denegación de SELinux se produce cuando el servidor HTTP Apache intenta acceder a un directorio etiquetado con un tipo para el conjunto Samba:

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for  pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

Esta negación de SELinux se puede traducir en:

SELinux denied the httpd process with PID 2465 to access the /var/www/html/file1 file with the samba_share_t type, which is not accessible to processes running in the httpd_t domain unless configured otherwise.

La tecnología de seguridad multinivel (MLS) clasifica los datos utilizando los niveles de seguridad de la información:

Las reglas que se aplican al flujo de datos operan desde los niveles inferiores a los superiores, y nunca a la inversa.

MLS denomina a los procesos como subjects, y a los archivos, dispositivos y otros componentes pasivos del sistema como objects. Tanto los sujetos como los objetos se etiquetan con un nivel de seguridad, que implica la autorización de un sujeto o la clasificación de un objeto.

SELinux utiliza el modelo Bell-La Padula (BLP). Este modelo especifica cómo puede fluir la información dentro del sistema basándose en las etiquetas adjuntas a cada sujeto y objeto. En BLP, los procesos pueden leer el mismo nivel de seguridad o uno inferior, pero sólo pueden escribir en el mismo nivel de seguridad o uno superior.

El sistema siempre combina las reglas de acceso MLS con los permisos de acceso convencionales (permisos de archivo). Por ejemplo, si un usuario con un nivel de seguridad "Secreto" utiliza el Control de Acceso Discrecional (DAC) para bloquear el acceso a un archivo por parte de otros usuarios, esto también bloquea el acceso de los usuarios con un nivel de seguridad "Alto Secreto". Un nivel de seguridad superior no permite automáticamente navegar arbitrariamente por un sistema de archivos.

Los usuarios con autorizaciones de alto nivel no adquieren automáticamente derechos administrativos en los sistemas de varios niveles. Aunque pueden tener acceso a toda la información del ordenador, esto es diferente de tener derechos administrativos.

Siga los siguientes pasos para cambiar la política de SELinux de dirigida a la seguridad multinivel (MLS).

Una política de seguridad SELinux es una colección de reglas SELinux. Una política es un componente central de SELinux y es cargada en el kernel por las herramientas de espacio de usuario de SELinux. El kernel impone el uso de una política SELinux para evaluar las solicitudes de acceso en el sistema. Por defecto, SELinux deniega todas las solicitudes excepto las que corresponden a las reglas especificadas en la política cargada.

Cada regla de política de SELinux describe una interacción entre un proceso y un recurso del sistema:

ALLOW apache_process apache_log:FILE READ;

Puede leer esta regla de ejemplo como The Apache process can read its logging file. En esta regla, apache_process y apache_log son labels. Una política de seguridad SELinux asigna etiquetas a los procesos y define las relaciones con los recursos del sistema. De este modo, una política asigna entidades del sistema operativo a la capa de SELinux.

Las etiquetas de SELinux se almacenan como atributos extendidos de los sistemas de archivos, como ext2. Puedes listarlas usando la utilidad getfattr o un comando ls -Z, por ejemplo:

$ ls -Z /etc/passwd
system_u:object_r:passwd_file_t:s0 /etc/passwd

Donde system_u es un usuario SELinux, object_r es un ejemplo de rol SELinux, y passwd_file_t es un dominio SELinux.

La política de SELinux por defecto provista por los paquetes selinux-policy contiene reglas para aplicaciones y demonios que son parte de Red Hat Enterprise Linux 8 y son provistos por paquetes en sus repositorios. Las aplicaciones no descritas en una regla de esta política de distribución no están limitadas por SELinux. Para cambiar esto, tiene que modificar la política usando un módulo de política, el cual contiene definiciones y reglas adicionales.

En Red Hat Enterprise Linux 8, puede consultar la política SELinux instalada y generar nuevos módulos de política utilizando la herramienta sepolicy. Los scripts que sepolicy genera junto con los módulos de política siempre contienen un comando que utiliza la utilidad restorecon. Esta utilidad es una herramienta básica para arreglar problemas de etiquetado en una parte seleccionada de un sistema de archivos.

Este procedimiento de ejemplo proporciona los pasos para confinar un simple demonio mediante SELinux. Sustituya el demonio por su aplicación personalizada y modifique la regla de ejemplo según los requisitos de esa aplicación y su política de seguridad.

Para simplificar la creación de nuevas políticas de SELinux para contenedores personalizados, RHEL 8 proporciona la utilidad udica. Puede utilizar esta herramienta para crear una política basada en una inspección del archivo de notación de objetos JavaScript (JSON) del contenedor, que contiene definiciones de capacidades Linux, puntos de montaje y puertos. La herramienta combina consecuentemente las reglas generadas usando los resultados de la inspección con las reglas heredadas de un bloque de SELinux Common Intermediate Language (CIL) especificado.

El proceso de generación de la política SELinux para un contenedor utilizando udica tiene tres partes principales:

Durante la fase de análisis, udica busca las capacidades de Linux, los puertos de red y los puntos de montaje.

Basándose en los resultados, udica detecta qué capacidades de Linux necesita el contenedor y crea una regla SELinux que permite todas estas capacidades. Si el contenedor se vincula a un puerto específico, udica utiliza las bibliotecas de espacio de usuario de SELinux para obtener la etiqueta SELinux correcta de un puerto que es utilizado por el contenedor inspeccionado.

Después, udica detecta qué directorios están montados en el espacio de nombres del sistema de archivos del contenedor desde el host.

La función de herencia de bloques del CIL permite a udica crear plantillas de SELinux allow rules centradas en una acción específica, por ejemplo:

Estas plantillas se llaman bloques y la política final de SELinux se crea fusionando los bloques.

Para generar una política de seguridad SELinux para un contenedor personalizado, siga los pasos de este procedimiento.

RHEL System Roles es una colección de roles y módulos de Ansible que proporcionan una interfaz de configuración consistente para gestionar remotamente múltiples sistemas RHEL. El rol de sistema SELinux permite las siguientes acciones:

La siguiente tabla proporciona una visión general de las variables de entrada disponibles en el rol del sistema SELinux.

El libro de jugadas de ejemplo /usr/share/doc/rhel-system-roles/selinux/example-selinux-playbook.yml instalado por el paquete rhel-system-roles demuestra cómo establecer la política dirigida en modo de aplicación. El libro de jugadas también aplica varias modificaciones de la política local y restaura los contextos de los archivos en el directorio /tmp/test_dir/.

Siga los pasos para preparar y aplicar un playbook de Ansible con su configuración de SELinux verificada.

Utilice los siguientes pasos para transferir su configuración personalizada y verificada de SELinux entre sistemas basados en RHEL 8.