SELinux bloqueando o sudo do zabbix_agentd

Question

Eu tenho um parâmetro de usuário personalizado para o Zabbix que chama uma ferramenta RAID CLI de hardware (arcconf / megacli) e verifica se alguma matriz está degradada. Como essas ferramentas são somente raiz, configurei sudoers para permitir o acesso do usuário do zabbix sem senha:

Defaults:zabbix !requiretty
Cmnd_Alias ZABBIX_MEGACLI_CMDS = /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -aALL
zabbix  ALL     = (ALL) NOPASSWD: ZABBIX_MEGACLI_CMDS

No CentOS 5, o zabbix_agentd foi executado sem confinamento e tudo correu bem. No CentOS 6, o agente agora é executado em um domínio zabbix_agent_t separado. Isso causou problemas. Inicialmente, o próprio binário do sudo não pôde ser executado, mas eu adicionei esta política:

sudo_exec(zabbix_agent_t)

Agora, ele morre de uma maneira diferente:

type=AVC msg=audit(1407137597.193:157): avc:  denied  { create } for  pid=3145 comm="sudo" scontext=unconfined_u:system_r:zabbix_agent_t:s0 tcontext=unconfined_u:system_r:zabbix_agent_t:s0 tclass=unix_dgram_socket
type=SYSCALL msg=audit(1407137597.193:157): arch=c000003e syscall=41 success=no exit=-13 a0=1 a1=80002 a2=0 a3=1 items=0 ppid=3121 pid=3145 auid=0 uid=496 gid=495 euid=0 suid=0 fsuid=0 egid=495 sgid=495 fsgid=495 tty=(none) ses=3 comm="sudo" exe="/usr/bin/sudo" subj=unconfined_u:system_r:zabbix_agent_t:s0 key=(null)
type=AVC msg=audit(1407137597.193:158): avc:  denied  { create } for  pid=3145 comm="sudo" scontext=unconfined_u:system_r:zabbix_agent_t:s0 tcontext=unconfined_u:system_r:zabbix_agent_t:s0 tclass=netlink_audit_socket
type=SYSCALL msg=audit(1407137597.193:158): arch=c000003e syscall=41 success=no exit=-13 a0=10 a1=3 a2=9 a3=7fffce049a20 items=0 ppid=3121 pid=3145 auid=0 uid=496 gid=495 euid=0 suid=0 fsuid=0 egid=495 sgid=495 fsgid=495 tty=(none) ses=3 comm="sudo" exe="/usr/bin/sudo" subj=unconfined_u:system_r:zabbix_agent_t:s0 key=(null)

Esta é a abordagem correta para fazer as coisas? Quais outras políticas posso adicionar para que o zabbix_agent_t possa executar o sudo? Se o sudo funcionar, ele ainda estará confinado no domínio zabbix_agent_t ou devo adicionar, por exemplo, TYPE=unconfined_t para a linha de sudoers? Devo adotar o link e o s / nrpe_t / zabbix_agent_t /?

EDITAR:

Não tenho certeza se essa é a melhor ideia, mas ...

sudo_exec(zabbix_agent_t)
domtrans_pattern(zabbix_agent_t, sudo_exec_t, unconfined_t)

parece funcionar. Eu suponho que o pior caso seja a segurança do sudo e dos arquivos sudoers.

    

Answer 1

A maneira de lidar com isso é coletar todas as informações sobre o acesso que o programa precisa e, em seguida, permitir explicitamente apenas esse acesso em um módulo de política personalizado.

Isso é bastante fácil de fazer.

Primeiro, você defina o domínio permissivo , para que o SELinux temporariamente não imponha suas regras. Ele ainda registrará as negações e, posteriormente, você usará esses registros.

semanage permissive -a zabbix_agent_t

Em seguida, deixe o programa rodar e deixe-o fazer o que for necessário. O log de auditoria preencherá o que seria negado, e esses registros também mostrarão quais permissões precisarão ser concedidas. Em seguida, veja esses registros com ausearch .

ausearch -r -m avc -ts today

Nós gere um módulo de política local contendo as permissões necessárias. (Você precisa usar a opção -r com ausearch aqui para que a saída possa ser processada por outros scripts.)

Se você viu entradas claramente irrelevantes, redirecione a saída para um arquivo e edite-a para removê-las. Em seguida, use o arquivo aqui.

ausearch -r -m avc -ts today | audit2allow -M zabbix_megacli

Finalmente, instalamos nosso novo módulo de política local e reativamos a aplicação do SELinux.

semodule -i zabbix_megacli.pp
semanage permissive -d zabbix_agent_t