Назад | Перейти на главную страницу

Почему 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;

У меня была аналогичная проблема (запуск проверки RAID-контроллера на машине с поддержкой selinux).

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

semodule -DB

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

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

Повернуть журнал, удалить старый журнал: 

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 (у которого есть оболочка nologin) выполнить такую ​​команду, как:

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

#!!!! 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 };

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

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

Ты пробовал:

setsebool -P zabbix_can_network=1

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

yum install policycoreutils-python
semanage permissive -a zabbix_agent_t

Удачи