Ir al contenidoIr a la navegación de la página: página anterior [tecla de acceso p]/página siguiente [tecla de acceso n]
documentation.suse.com / Resolución de problemas de SELinux

Resolución de problemas de SELinux

Fecha de publicación: 12 Dic 2024
DESCRIPCIÓN

Un sistema con SELinux en el modo enforcing puede provocar denegaciones de acceso que pueden impedir que las aplicaciones se ejecuten correctamente. Puede utilizar audit2allow o setroubleshoot para analizar los mensajes de denegación de forma sencilla.

INTENCIÓN

Este artículo proporciona instrucciones sobre cómo resolver las denegaciones de acceso causadas por SELinux sin disminuir la seguridad del sistema.

ESFUERZO

Se tardan aproximadamente 30 minutos en leer el artículo.

OBJETIVO

Podrá utilizar una de las herramientas descritas a continuación para depurar las denegaciones de SELinux.

REQUISITOS

  • Un sistema en ejecución con SELinux habilitado.

1 El archivo /var/log/audit/audit.log

 

Por defecto, si SELinux es la razón por la que algo no funcione, se envía un mensaje de registro al archivo /var/log/audit/audit.log.

Nota
Nota: /var/log/audit/audit.log vacío

Si ve un registro /var/log/audit/audit.log vacío, normalmente significa que el servicio auditd no se está ejecutando. En tal caso, haga lo siguiente:

  1. Inicie el servicio auditd: 

    > sudo systemctl start auditd

  2. Habilite el servicio en los destinos del sistema mediante: 

    > sudo systemctl enable auditd

En el archivo /var/log/audit/audit.log se almacenan los mensajes de denegación de acceso, eventos de servicio, etc.

En el Ejemplo 1: “Líneas de ejemplo de /etc/audit/audit.log”, puede ver un ejemplo parcial del contenido de /var/log/audit/audit.log.

Ejemplo 1: Líneas de ejemplo de /etc/audit/audit.log
 
type=DAEMON_START msg=audit(1348173810.874:6248): auditd start, ver=1.7.7 format=raw kernel=3.0.13-0.27-default auid=0 pid=4235 subj=system_u:system_r:auditd_t res=success
type=AVC msg=audit(1348173901.081:292): avc:  denied  { write } for  pid=3426 comm="smartd" name="smartmontools" dev=sda6 ino=581743 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:293): avc:  denied  { remove_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:294): avc:  denied  { unlink } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:295): avc:  denied  { rename } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582373 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:296): avc:  denied  { add_name } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state~" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=dir
type=AVC msg=audit(1348173901.081:297): avc:  denied  { create } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:298): avc:  denied  { write open } for  pid=3426 comm="smartd" name="smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316

Un solo mensaje tiene el aspecto siguiente: 

type=AVC msg=audit(1348173901.081:299): avc:  denied  { getattr } for  pid=3426 comm="smartd" path="/var/lib/smartmontools/smartd.WDC_WD2500BEKT_75PVMT0-WD_WXC1A21E0454.ata.state" dev=sda6 ino=582390 scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:var_lib_t tclass=file

Cada línea del mensaje se puede dividir en secciones. Por ejemplo, las secciones de la última línea son:

type=AVC:

Cada línea de registro de auditoría relacionada con SELinux comienza con la identificación del tipo, por ejemplo, type=AVC. Tenga en cuenta que un mensaje con el tipo type=SYSCALL que sigue a otro con un tipo diferente y tiene el mismo valor de msg puede proporcionar más información sobre el evento.

msg=audit(1348173901.309:300):

Esta es la marca horaria, que se escribe en tiempo de época, el número de segundos que han transcurrido desde el 1 de enero de 1970. Puede utilizar date -d en la parte situada delante del punto de la notación de tiempo de época para averiguar cuándo se produjo el evento: 

> date -d @1348173901
Thu Sep 20 16:45:01 EDT 2012
avc: denied { append }:

La acción específica que se ha denegado. En este caso, el sistema ha denegado la adición de datos a un archivo. Mientras examina el archivo de registro de auditoría, puede ver otras acciones del sistema, como write open, getattr y más.

for pid=1316:

El ID de proceso del comando o proceso que inició la acción.

comm="rsyslogd":

El comando específico que estaba asociado con ese PID.

name="smartmontools":

El nombre del sujeto de la acción.

dev=sda6 ino=582296:

El dispositivo de bloque y el número de inodo del archivo implicado.

scontext=system_u:system_r:syslogd_t:

El contexto de origen, que es el contexto del iniciador de la acción.

tclass=file:

Una identificación de clase del sujeto.

2 Análisis de /var/log/audit/audit.log con audit2allow

 

En lugar de interpretar los eventos de /var/log/audit/audit.log por sí mismo, puede utilizar el comando audit2allow.

El comando ayuda a analizar los mensajes de registro crípticos de /var/log/audit/audit.log. Una sesión de resolución de problemas de audit2allow siempre consta de tres comandos diferentes. En primer lugar, utilizaría audit2allow -w -a para presentar la información de auditoría de una forma más fácil de leer. Por defecto, audit2allow -w -a funciona en el archivo audit.log. Si desea analizar un mensaje específico del archivo audit.log, cópielo en un archivo temporal y analice el archivo con: 

> sudo audit2allow -w -i FILENAME
Ejemplo 2: Análisis de mensajes de auditoría
 
> sudoaudit2allow -w -i testfile
type=AVC msg=audit(1348173901.309:300): avc:  denied  { append } for  pid=1316
comm="rsyslogd" name="acpid" dev=sda6 ino=582296
scontext=system_u:system_r:syslogd_t tcontext=system_u:object_r:apmd_log_t tclass=file
Esto ha sido causado por:

Falta una regla de acceso de aplicación de tipo (TE).

Para generar un módulo cargable que permita este acceso, ejecute: 

> sudo audit2allow

Para averiguar qué regla específica ha denegado el acceso, puede utilizar audit2allow -a para mostrar las reglas de aplicación de todos los eventos que se registraron en el archivo audit.log , o audit2allow -i FILENAME para mostrarlo para los mensajes que ha almacenado en un archivo específico:

Ejemplo 3: Ver qué líneas deniegan el acceso
 
> sudoaudit2allow -i testfile
#============= syslogd_t ==============
allow syslogd_t apmd_log_t:file append;

Para crear un módulo SELinux con el nombre mymodule que pueda cargar para permitir el acceso que se ha denegado anteriormente, ejecute: 

> sudo audit2allow -a -R -M mymodule

Si desea hacer esto para todos los eventos que se han registrado en el archivo audit.log, utilice los argumentos del comando -a -M. Para hacerlo solo para mensajes específicos que se encuentren en un archivo específico, utilice -i -M como en el ejemplo siguiente:

Ejemplo 4: Creación de un módulo de directivas que permita una acción previamente denegada
 
> sudoaudit2allow -i testfile -M example
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i example.pp

Como indica el comando audit2allow, ahora puede ejecutar este módulo mediante el comando semodule -i, seguido del nombre del módulo que audit2allow ha creado para usted (example.pp en el ejemplo anterior).

3 Análisis de mensajes de AVC mediante setroubleshoot

 

Para analizar los mensajes de denegación de AVC de forma sencilla, puede utilizar la herramienta setroubleshoot.

3.1 Descripción general de setroubleshoot

 

3.1.1 ¿Qué es setroubleshoot?

 

setroubleshoot es una herramienta que recopila eventos de auditoría de SELinux desde el kernel y analiza estos eventos. Si se produce un evento de este tipo, setroubleshoot informa al administrador.

3.1.2 Componentes de setroubleshoot

 

El proceso de resolución de problemas de SELinux incluye los siguientes componentes, todos ellos instalados en SLE Micro por defecto.

  • setroubleshoot-server proporciona las siguientes herramientas:

    • setroubleshootd: el daemon principal que gestiona las peticiones entrantes y las definiciones de complementos. El daemon se activa a pedido y no es necesario ejecutarlo a través del servicio systemd. Solo puede gestionarlo un usuario con privilegios y un usuario setroubleshoot dedicado.

    • Una base de datos de alertas en el archivo /var/lib/setroubleshoot/setroubleshoot_database.xml.

    • sealert: una interfaz de usuario de línea de comandos para analizar /var/log/audit.log.

    • sedispatch: un asignador de auditoría que explora los mensajes de AVC de SELinux y los transforma en un mensaje DBus, que luego pasa al daemon.

  • setroubleshoot-plugins: los complementos se utilizan para el análisis de mensajes de AVC y proporcionan sugerencias sobre cómo solucionar problemas.

3.1.3 ¿Cómo funciona setroubleshoot?

 

setroubleshoot incluye un daemon y complementos de análisis. Cuando un complemento detecta un problema, se informa al daemon, que comprueba si se trata de un problema conocido. Si no es así, el nuevo problema se añade a la base de datos junto con una solución sugerida.

3.1.4 Ventajas de setroubleshoot

 

setroubleshoot proporciona las siguientes funciones para ayudarle a resolver problemas en sus sistemas SELinux protegidos:

  • Envío de alertas al administrador cuando se produce una denegación de AVC.

  • Análisis automático de las denegaciones de AVC.

  • Sugerencia de posibles soluciones, como ajustar la configuración del sistema o instalar actualizaciones, etc.

  • Navegación de alertas anteriores.

3.2 Configuración de setroubleshoot

 

Aunque la configuración de setroubleshoot no requiere ajustes, es posible que tenga que cambiar los valores por defecto. En las siguientes secciones se proporcionan los casos de uso habituales.

El archivo de configuración de setroubleshoot es /etc/setroubleshoot. Normalmente, no es necesario modificar la configuración además de definir las notificaciones por correo electrónico. Sin embargo, si necesita cambiar la configuración, puede editar el archivo o utilizar el comando setroubleshootd para configurar un elemento concreto. La sintaxis del comando es la siguiente: 

# setroubleshootd -c
SECTION.OPTION=VALUE

Por ejemplo, para definir la opción from_address, ejecute el comando de la siguiente manera: 

# setroubleshootd -c
email.from_address="example@mail.com"

3.2.1 Configuración del nivel de registro de setroubleshoot

 

El nivel de registro por defecto (el valor de sealert_log y setroubleshootd_log) se establece en warning. Sin embargo, puede definir uno de los siguientes valores:

critical

Solo se registran los errores graves que impiden el funcionamiento del sistema.

error

Se informa de errores graves que pueden afectar al sistema.

warning

Indicación de que ha ocurrido algo inesperado o de que podría producirse un problema en un futuro próximo. Sin embargo, el sistema funciona como se espera.

info

Se registra una confirmación de que el sistema se está ejecutando correctamente.

debug

Se registra información detallada para fines de depuración.

3.2.2 Configuración de setroubleshoot para enviar notificaciones por correo electrónico

 

setroubleshoot puede enviarle notificaciones por correo electrónico si hay una denegación de AVC en el sistema.

Para recibir estas notificaciones, haga lo siguiente:

  1. Abra la carpeta /etc/setroubleshoot/setroubleshoot.conf.

  2. En el archivo, ajuste los siguientes elementos de configuración según sus necesidades:

    smtp_host

    Si el servidor SMTP no se ejecuta en el host local, introduzca la dirección del servidor.

    smtp_port

    El valor por defecto es 25. Normalmente, este valor no requiere ningún ajuste.

    from_address

    Añada la dirección del remitente.

    subject

    Configure un tema genérico para todos los mensajes.

    recipients_filepath

    Especifique la ubicación de la lista de destinatarios de la notificación.

    use_sendmail

    Defina el valor true si utiliza SendMail.

  3. Cree el archivo de destinatarios de correo en la vía definida por la opción recipients_filepath (por defecto, /var/lib/setroubleshoot/email_alerts-recipients).

    Cada dirección de correo electrónico debe estar en una línea distinta. Los comentarios se indican con el símbolo #.

3.2.3 Configuración de la base de datos de setroubleshoot

 

Puede cambiar la cantidad de registros de la base de datos de setroubleshootd, su ubicación o el prefijo del nombre de archivo.

database_dir

Especifique una vía absoluta al directorio donde debe residir el archivo XML de la base de datos.

filename

Configure un prefijo personalizado para el nombre del archivo de la base de datos. El nombre del archivo tendrá el siguiente aspecto: FILENAME_PREFIX_database.xml.

max_alerts

Defina el número máximo de registros de la base de datos. Especifique 0 para tener un número ilimitado de registros.

max_alert_age

Las alertas anteriores al límite establecido se suprimen de la base de datos. Puede utilizar las unidades: year, month, day, hour, minute y second incluso en plural y puede utilizar más de una unidad, por ejemplo, 3 weeks 2 days, que equivale a 23 días. Si se deja vacío, no hay límite.

3.2.4 Configuración de setroubleshoot para recopilar información de servidores remotos

 

Puede configurar setroubleshoot para recopilar datos de auditoría de SELinux desde servidores remotos. Para ello, configure la lista de direcciones.

[listen_for_client] lista_de_direcciones

En el lado del servidor.

[client_connect_to] lista_de_direcciones

En el lado del cliente.

Las direcciones de la lista tienen este formato: 

          [{FAMILY}]ADDRESS[:PORT_NUMBER]

donde {FAMILY} es {inet} o {unix}%{path}s. Si la familia de direcciones es inet, puede especificar opcionalmente un número de puerto; de lo contrario, el número de puerto se establece en el valor por defecto especificado por la opción de configuración default_port. El valor por defecto {unix}%{path}s hostname significa que se escucha en el socket del dominio Unix local.

3.3 Ejecución del análisis de /var/log/audit/audit.log

 

Para permitir que la herramienta setroubleshoot analice el archivo de registro de auditoría, ejecute el comando: 

> sudo sealert -a /var/log/audit/audit.log

En el siguiente resultado de ejemplo, hay dos valores de puerto asignados al servicio SSHD: 

100% done
found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing sshd from name_bind access on the tcp_socket port 2222.

*****  Plugin bind_ports (92.2 confidence) suggests   ************************ 

If you want to allow sshd to bind to network port 2222
Then you need to modify the port type.
Do
# semanage port -a -t PORT_TYPE -p tcp 2222  1
    where PORT_TYPE is one of the following: ssh_port_t, vnc_port_t, xserver_port_t.

*****  Plugin catchall_boolean (7.83 confidence) suggests   ******************

If you want to allow nis to enabled
Then you must tell SELinux about this by enabling the 'nis_enabled' boolean.

Do
setsebool -P nis_enabled 1

*****  Plugin catchall (1.41 confidence) suggests   **************************

If you believe that sshd should be allowed name_bind access on the port 2222 tcp_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Additional Information:
...

First Seen                    2024-02-07 14:26:27 UTC
Last Seen                     2024-02-08 03:30:12 UTC
Local ID                      b5cbdd75-3f8d-425d-af75-f6cbf1540ffd 

Raw Audit Messages
type=AVC msg=audit(1707363012.797:25): avc:  denied  { name_bind } for  pid=841 comm="sshd" src=2222 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unreserved_port_t:s0 tclass=tcp_socket permissive=0


Hash: sshd,sshd_t,unreserved_port_t,tcp_socket,name_bind

1

El complemento bind_ports proporciona la solución más adecuada para el problema.