☰

¿Por qué SELinux bloquea las llamadas sudo de mi agente Zabbix?

tag-icon • tag-icon centos selinux zabbix
¿Por qué SELinux bloquea las llamadas sudo de mi agente Zabbix?

Tengo algunas comprobaciones de Zabbix que requieren sudo. Estos son los contenidos de /etc/sudoers.d/zabbix

zabbix ALL=(ALL)    NOPASSWD: /bin/yum history
zabbix ALL=(ALL)    NOPASSWD: /bin/needs-restarting
zabbix ALL=(ALL)    NOPASSWD: /sbin/check31
zabbix ALL=(ALL)    NOPASSWD: /usr/sbin/crm_mon --as-xml

Cuando fuerzo la verificación desde mi proxy Zabbix, aparece el siguiente error de permiso denegado (pacemaker.status usa /usr/sbin/crm_mon --as-xml):

bash-5.0$ zabbix_get -s my-server -k pacemaker.status
sudo: PAM account management error: System error
sudo: unable to send audit message: Permission denied

Verifiqué que SELinux efectivamente está bloqueando mis llamadas configurando temporalmente SELinux en modo permisivo.

Luego, intenté permitir estas llamadas siguiendo los siguientes pasos.

Primero, roté el registro de auditoría porque estaba lleno de mensajes irrelevantes de números anteriores:

service auditd rotate

Luego eliminé todas las dontaudits de la política:

semodule -DB

En el proxy Zabbix provoqué el error al ejecutar la zabbix_getllamada como se indicó anteriormente.

A partir de los registros, creé un módulo SELinux y lo instalé con semodule:

cat /var/log/audit/audit.log | audit2allow -M zabbix-agent
semodule -i zabbix-agent.pp

Aún así, recibo el mismo error de permiso denegado al enviar el mensaje de auditoría cuando ejecuto zabbix_get. Investigué un poco, desactivar dontaudits debería funcionar y obligar a SELinux a registrar mensajes adicionales para solucionar este problema, pero lo hice y no funciona para mi situación.

Este es el zabbix-agent.tearchivo audit2allowque ha creado:

module zabbix-agent 1.0;

require {
    type zabbix_agent_t;
    type chkpwd_exec_t;
    class unix_dgram_socket create;
    class file execute_no_trans;
    class netlink_audit_socket create;
}

#============= zabbix_agent_t ==============
allow zabbix_agent_t chkpwd_exec_t:file execute_no_trans;
allow zabbix_agent_t self:netlink_audit_socket create;
allow zabbix_agent_t self:unix_dgram_socket create;

Respuesta1

Has probado:

setsebool -P zabbix_can_network=1

Si ya permitió lo anterior, puede intentar esto:

yum install policycoreutils-python
semanage permissive -a zabbix_agent_t

Buena suerte

Respuesta2

Tuve un problema similar (ejecutando una verificación del controlador RAID en una máquina habilitada para Selinux).

El eslabón que me faltaba era el:

semódulo -DB

para permitir algunas políticas distintas a las de auditoría. Luego retome la política.

La referencia fue:https://forums.centos.org/viewtopic.php?t=62829 Es importante tener selinux configurado en permisivo primero cuando realice la captura. Al igual que usted, hice algo como (después de configurarlo en permisivo y capturar y aplicar la política):

rotar registro, eliminar registro antiguo:

service auditd rotate

semodule -DB (no deshabilita reglas de auditoría)

  • ejecute el comando desde zabbix (configuración - hosts - ejecutar una vez)

  • ejecute lo siguiente para obtener el archivo de política

    grep -i avc /var/log/audit/audit.log | audit2allow -M políticax

  • correr

    semodule -i políticax.pp

  • ejecute el comando en Zabbix nuevamente para verificar si funciona

  • correr

    semódulo -B

    para habilitar reglas de no auditoría nuevamente.

Mi regla sudoers se ve así:

zabbix ALL=(root) NOPASSWD: /opt/MegaRAID/storcli/storcli64

Intenté si el usuario de zabbix (que tiene shell nologin) podía ejecutar el comando como:

su -s /bin/bash -c 'sudo /opt/MegaRAID/storcli/storcli64 /c0 /eall /sall show' zabbix

Recomiendo probar lo mismo con sus comandos para asegurarse de que se ejecuten correctamente como usuario zabbix.

También utilicé recoverycon en los sudoers y el archivo de sombra, pero no estoy seguro si eso ayudó. También configuré el contexto zabbix_agent_t en el script que ejecuto, pero es posible que eso no haya tenido efecto.

Por último, pero no menos importante, aquí está el archivo de política que apliqué y que me funcionó, tal vez puedas simplemente compilarlo y aplicarlo y ver si funciona:

cat mypolz1.te 

module mypolz1 1.0;

require {
    type zabbix_exec_t;
    type zabbix_agent_t;
    type system_dbusd_t;
    class capability { net_admin sys_admin };
    class dbus send_msg;
    class unix_dgram_socket write;
    class file { execute execute_no_trans };
    class netlink_audit_socket { read write };
}

#============= zabbix_agent_t ==============

#!!!! This avc is allowed in the current policy
allow zabbix_agent_t self:capability net_admin;
allow zabbix_agent_t self:capability sys_admin;

#!!!! This avc is allowed in the current policy
allow zabbix_agent_t self:netlink_audit_socket { read write };

#!!!! This avc is allowed in the current policy
allow zabbix_agent_t self:unix_dgram_socket write;

#!!!! This avc is allowed in the current policy
allow zabbix_agent_t system_dbusd_t:dbus send_msg;

#!!!! This avc is allowed in the current policy
allow zabbix_agent_t zabbix_exec_t:file { execute execute_no_trans };

Como puede ver, tenía algunas políticas configuradas, tal vez el administrador del sistema fue el que hizo el truco (antes de ejecutar el comando pero sin resultados).

Creo que la iteración es clave, porque después de cada paso surgirán diferentes problemas que la política aplicada mitigará. ¡Buena suerte!

información relacionada