☰

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

tag-icon • tag-icon centos selinux zabbix
Почему 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;

решение1

Ты пробовал:

setsebool -P zabbix_can_network=1

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

yum install policycoreutils-python
semanage permissive -a zabbix_agent_t

Удачи

решение2

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

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

semodule-DB

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

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

ротация журнала, удаление старого журнала:

service auditd rotate

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

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

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

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

  • бегать

    semodule -i policyx.pp

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

  • бегать

    семодуль -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 };

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

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

Связанный контент