☰

Por que o SELinux está bloqueando as chamadas sudo do meu agente Zabbix?

tag-icon • tag-icon centos selinux zabbix
Por que o SELinux está bloqueando as chamadas sudo do meu agente Zabbix?

Eu tenho algumas verificações do Zabbix que exigem sudo. Este é o conteúdo 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

Quando forço a verificação do meu proxy Zabbix, recebo o seguinte erro de permissão negada (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

Verifiquei que o SELinux está de fato bloqueando minhas chamadas configurando temporariamente o SELinux no modo permissivo.

Em seguida, tentei permitir essas chamadas seguindo as etapas a seguir.

Primeiro, girei o log de auditoria porque estava cheio de mensagens irrelevantes de edições anteriores:

service auditd rotate

Em seguida, removi todos os dontaudits da política:

semodule -DB

No proxy Zabbix acionei o erro executando a zabbix_getchamada conforme indicado acima.

A partir dos logs criei um módulo SELinux e instalei-o com semodule:

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

Ainda assim, recebo o mesmo erro de permissão negada ao enviar a mensagem de auditoria quando executo o arquivo zabbix_get. Eu fiz algumas pesquisas, desligar dontaudits deve resolver e forçar o SELinux a registrar mensagens adicionais para resolver esse problema, mas eu fiz isso e não funciona para minha situação.

Este é o zabbix-agent.tearquivo audit2allowque foi criado:

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;

Responder1

Você tentou:

setsebool -P zabbix_can_network=1

se você já permitiu o acima, você pode tentar isto:

yum install policycoreutils-python
semanage permissive -a zabbix_agent_t

Boa sorte

Responder2

Eu tive um problema semelhante (executando uma verificação do controlador RAID em uma máquina habilitada para selinux).

O elo que faltava para mim era:

semódulo -DB

para permitir algumas políticas de não auditoria. Em seguida, recupere a política.

A referência foi:https://forums.centos.org/viewtopic.php?t=62829 É importante ter o selinux configurado como permissivo primeiro, quando você capturar. Muito parecido com você, fiz algo assim (depois de definir como permissivo e capturar e aplicar a política):

gire o log, remova o log antigo:

service auditd rotate

semodule -DB (desativa nenhuma regra de auditoria)

  • execute o comando do zabbix (configuração - hosts - execute uma vez)

  • execute o seguinte para obter o arquivo de política

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

  • correr

    semodule -i políticax.pp

  • execute o comando no Zabbix novamente para verificar se funciona

  • correr

    semódulo -B

    para ativar regras de não auditoria novamente.

Minha regra sudoers é semelhante a:

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

Tentei se o usuário zabbix (que possui shell nologin) pudesse executar o comando como:

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

Eu recomendo tentar o mesmo para seus comandos para garantir que eles sejam executados corretamente como usuário zabbix.

Também usei o restorecon nos sudoers e no arquivo shadow, mas não tenho certeza se isso ajudou. Também configurei o contexto zabbix_agent_t no script que executo, mas isso pode não ter surtido efeito.

Por último, mas não menos importante, aqui está o arquivo de política que apliquei e que funcionou para mim. Talvez você possa apenas compilá-lo e aplicá-lo e ver se 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 você pode ver, eu tinha algumas políticas definidas, talvez o sysadmin seja quem fez o truque (antes de executar o comando, mas sem saída).

Acho que a iteração é fundamental, porque após cada etapa você terá diferentes problemas que a política aplicada irá então mitigar. Boa sorte!

informação relacionada