☰

Warum blockiert SELinux die Sudo-Aufrufe meines Zabbix-Agenten?

tag-icon • tag-icon centos selinux zabbix
Warum blockiert SELinux die Sudo-Aufrufe meines Zabbix-Agenten?

Ich habe einige Zabbix-Prüfungen, die sudo erfordern. Dies ist der Inhalt von /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

Wenn ich eine Prüfung von meinem Zabbix-Proxy aus erzwinge, erhalte ich die folgende Fehlermeldung „Zugriff verweigert“ (pacemaker.status verwendet /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

Ich habe überprüft, dass SELinux meine Anrufe tatsächlich blockiert, indem ich SELinux vorübergehend in den permissiven Modus versetzt habe.

Dann habe ich versucht, diese Anrufe zuzulassen, indem ich die folgenden Schritte ausgeführt habe.

Zuerst habe ich das Prüfprotokoll rotiert, da es mit irrelevanten Meldungen aus früheren Problemen voll war:

service auditd rotate

Ich habe dann alle Dontaudits aus der Richtlinie entfernt:

semodule -DB

Auf dem Zabbix-Proxy habe ich den Fehler ausgelöst, indem ich den zabbix_getAufruf wie oben beschrieben ausgeführt habe.

Anhand der Protokolle habe ich ein SELinux-Modul erstellt und es mit folgendem installiert semodule:

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

Trotzdem erhalte ich beim Senden der Audit-Meldung beim Ausführen denselben Fehler „Berechtigung verweigert“ zabbix_get. Ich habe ein wenig nachgeforscht und festgestellt, dass das Deaktivieren von Dontaudits funktionieren und SELinux zwingen sollte, zusätzliche Meldungen zu protokollieren, um dieses Problem zu beheben. Aber das habe ich getan und es funktioniert in meiner Situation nicht.

Dies ist die erstellte zabbix-agent.teDatei :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;

Antwort1

Hast du versucht:

setsebool -P zabbix_can_network=1

Wenn Sie das oben genannte bereits zugelassen haben, können Sie Folgendes versuchen:

yum install policycoreutils-python
semanage permissive -a zabbix_agent_t

Viel Glück

Antwort2

Ich hatte ein ähnliches Problem (Ausführen einer RAID-Controller-Prüfung auf einer Selinux-fähigen Maschine).

Das fehlende Bindeglied war für mich:

semodule -DB

um einige Nicht-Audit-Richtlinien zu aktivieren. Erfassen Sie dann die Richtlinie erneut.

Referenz war:https://forums.centos.org/viewtopic.php?t=62829 Es ist wichtig, dass Selinux beim Aufzeichnen zuerst auf „permissiv“ eingestellt ist. So ähnlich wie Sie habe ich Folgendes gemacht (nachdem ich es auf „permissiv“ eingestellt, aufgezeichnet und die Richtlinie angewendet hatte):

Protokoll rotieren, altes Protokoll entfernen:

service auditd rotate

semodule -DB (deaktiviert keine Audit-Regeln)

  • Führen Sie den Befehl von Zabbix aus (Konfiguration – Hosts – einmal ausführen).

  • Führen Sie Folgendes aus, um die Richtliniendatei abzurufen

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

  • laufen

    semodule -i policyx.pp

  • Führen Sie den Befehl in Zabbix erneut aus, um zu überprüfen, ob er funktioniert

  • laufen

    semodule -B

    um No-Audit-Regeln wieder zu aktivieren.

Meine Sudoers-Regel sieht folgendermaßen aus:

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

Ich habe versucht, ob der Zabbix-Benutzer (der über eine Nologin-Shell verfügt) den Befehl wie folgt ausführen könnte:

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

Ich empfehle, dasselbe für Ihre Befehle zu versuchen, um sicherzustellen, dass sie ordnungsgemäß als Benutzer zabbix ausgeführt werden.

Ich habe auch restorecon für die Sudoers und die Shadow-Datei verwendet, bin mir aber nicht sicher, ob das geholfen hat. Ich habe auch den zabbix_agent_t-Kontext für das von mir ausgeführte Skript festgelegt, aber das hatte möglicherweise keine Wirkung.

Zu guter Letzt ist hier die Richtliniendatei, die ich angewendet habe und die bei mir den Trick getan hat. Vielleicht können Sie sie einfach kompilieren und anwenden und sehen, ob es funktioniert:

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

Wie Sie sehen, hatte ich einige Richtlinien festgelegt. Vielleicht hat der Systemadministrator den Trick gemacht (bevor ich den Befehl ausgeführt habe, aber keine Ausgabe erhalten habe).

Ich denke, Iteration ist der Schlüssel, denn nach jedem Schritt treten unterschiedliche Probleme auf, die dann durch die Anwendung der Richtlinie gemildert werden. Viel Glück!

verwandte Informationen