Почему SELinux блокирует вызовы sudo моего агента Zabbix?

У меня есть несколько проверок Zabbix, которые требуют sudo. Это содержимое /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

Когда я принудительно выполняю проверку с моего прокси-сервера Zabbix, я получаю следующую ошибку “доступ запрещен” (pacemaker.status использует /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

Я проверил, что SELinux действительно блокирует мои вызовы, временно установив SELinux в разрешающий режим.

Затем я попытался разрешить эти вызовы, пройдя через следующие шаги.

Сначала я ротировал журнал аудита, так как он был полон нерелевантными сообщениями от предыдущих проблем:

service auditd rotate

Затем я удалил все dontaudits из политики:

semodule -DB

На прокси-сервере Zabbix я вызвал ошибку, выполнив вызов zabbix_get, как указано выше.

Из журналов я создал модуль SELinux и установил его с помощью semodule:

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

Однако я все равно получаю ту же ошибку “доступ запрещен” при отправке аудиторного сообщения, когда выполняю zabbix_get. Я провел некоторые исследования, отключение dontaudits должно решить эту проблему и заставить SELinux записывать дополнительные сообщения для ее решения, но я это сделал, и это не сработало в моей ситуации.

Вот файл zabbix-agent.te, который создал audit2allow:

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;

Вы пробовали:

setsebool -P zabbix_can_network=1

если вы уже разрешили вышеуказанное, тогда вы можете попробовать это:

yum install policycoreutils-python
semanage permissive -a zabbix_agent_t

Удачи

У меня была аналогичная проблема (проверка RAID-контроллера на машине с включенным SELinux).

Для меня недостающим звеном был:

semodule -DB

чтобы включить некоторые неаудиторные политики.
Затем заново захватите политику.

Ссылка была:https://forums.centos.org/viewtopic.php?t=62829
Важно, чтобы SELinux был сначала установлен в разрешающий режим, когда вы захватываете.
Даже немного похоже на то, что я сделал (после установки в разрешающий режим, захвата и применения политики):

уменьшение журнала, удаление старого журнала:

service auditd rotate

semodule -DB (отключает правила без аудита)

• выполните команду с zabbix (конфигурация – хосты – выполнить один раз)

• выполните следующее, чтобы получить файл политики

  grep -i avc /var/log/audit/audit.log | audit2allow -M policyx

• выполните

  semodule -i policyx.pp

• выполните команду в Zabbix снова, чтобы проверить, работает ли она

• выполните

  semodule -B

  чтобы снова включить правила без аудита.

Мое правило sudoers выглядит так:

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

Я попробовал, может ли пользователь zabbix (у которого нет оболочки входа) выполнить команду так:

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

Рекомендую попробовать то же самое для ваших команд, чтобы убедиться, что они выполняются правильно от имени пользователя zabbix.

Я также использовал restorecon для файлов sudoers и shadow, но не уверен, что это помогло.
Я также установил контекст zabbix_agent_t на скрипт, который я выполняю, но это могло не оказать эффекта.

Наконец, вот файл политики, который я применил, и который сработал для меня, возможно, вы можете просто скомпилировать и применить его и посмотреть, сработает ли он:

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 ==============

#!!!! Этот avc разрешен в текущей политике
allow zabbix_agent_t self:capability net_admin;
allow zabbix_agent_t self:capability sys_admin;

#!!!! Этот avc разрешен в текущей политике
allow zabbix_agent_t self:netlink_audit_socket { read write };

#!!!! Этот avc разрешен в текущей политике
allow zabbix_agent_t self:unix_dgram_socket write;

#!!!! Этот avc разрешен в текущей политике
allow zabbix_agent_t system_dbusd_t:dbus send_msg;

#!!!! Этот avc разрешен в текущей политике
allow zabbix_agent_t zabbix_exec_t:file { execute execute_no_trans };

Как вы можете видеть, у меня были установлены некоторые политики, возможно, sysadmin является той, которая сработала (до того, как я заставил команду работать, но без вывода).

Я думаю, что итерация имеет решающее значение, потому что после каждого шага вы будете сталкиваться с различными проблемами, которые применение политики затем может смягчить.
Удачи!

существует булева переменная selinux, которую вы можете установить:

setsebool -P zabbix_run_sudo 1

возможно, поэтому учетная запись zabbix не может выполнять “sudo”.