SELinux : détecter et corriger les problèmes de droits

Le problème

Dans le cadre de la supervision MySQL, l’agent Zabbix est censé exécuter cette commande en local pour s’assurer que le serveur accepte bien les connexion :

mysqladmin -h 127.0.0.1 ping

Si je lance la commande en local :

zabbix@1.2.3.4:~$ mysqladmin -h 127.0.0.1 ping
mysqld is alive

Mais quand c’est l’agent Zabbix lui-même qui lance la commande :

mysqladmin: connect to server at '127.0.0.1' failed
error: 'Can't connect to MySQL server on '127.0.0.1' (110)'
Check that mysqld is running on 127.0.0.1 and that the port is 3306.
You can check this by doing 'telnet 127.0.0.1 3306'

Pourtant les deux tests-ci-dessus ont un fonctionnement identique. C’est la même commande qui est utilisée dans les deux cas, avec les même droits. Après une heure à faire des tests et à s’arracher les cheveux pour comprendre d’où peut venir le problème, j’ai pensé à SELinux. Pour voir si SELinux est activé :

root@1.2.3.4:~# getenforce
Enforcing

Là c’est activé, sinon ça m’afficherait Permissive ou Disabled.

Je désactive temporairement SELinux pour faire des tests avec setenforce 0. Comme la supervision Zabbix se mets à fonctionner, je sais que le problème vient de là. Je réactive SELinux avec setenforce 1.

La solution

Pour désactiver définitivement SELinux il faut faire echo "0" > /selinux/enforce. Mais comme je suis sur une plateforme demandant un niveau de sécurité élevé, je ne peux pas le désactive. Il va donc falloir autoriser l’agent Zabbix à utiliser MySQL.

On installe d’abord un utilitaire qui va bien nous aider :

apt-get install policycoreutils

Ensuite on surveille le fichier audit.log :

tail -f -n 0 /var/log/audit/audit.log | audit2allow

À chaque fois que l’agent Zabbix tente de se connecter au MySQL, ca affiche quelque chose qui ressemble à ça :

#============= zabbix_agent_t ==============
allow zabbix_agent_t mysqld_etc_t:file { open read };
#!!!! The file '/var/lib/mysql/mysql.sock' is mislabeled on your system.
#!!!! Fix with $ restorecon -R -v /var/lib/mysql/mysql.sock
#!!!! This avc can be allowed using the boolean 'daemons_enable_cluster_mode'
allow zabbix_agent_t mysqld_t:unix_stream_socket connectto;

On peut voir la cause du problème. L’agent Zabbix ne peut pas accéder à /var/lib/mysql/mysql.sock. Ça nous donne même l’option à activer : daemons_enable_cluster_mode.

Je lance donc les commandes suivantes :

setsebool -P daemons_enable_cluster_mode 1setsebool daemons_enable_cluster_mode 1

Il ne reste plus qu’à redémarrer l’agent Zabbix (systemctl restart zabbix-agent.service), et le problème est résolu.

Linux : créer une règle firewalld

Récemment j’ai dû créer une règle sur firewalld pour autoriser un agent Zabbix à communiquer. Comme je n’avais jamais utilisé cette solution jusque là j’ai un peu galéré. Voici ma procédure.

Faire un firewall-cmd --get-services. Ça va afficher la liste de tous les services gérés par firewalld. Normalement zabbix-agent n’est pas dedans. On va l’ajouter.

Créez le fichier /etc/firewalld/services/zabbix-agent.xml avec pour contenu :

<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>ZABBIX-AGENT</short>
  <description>Flux for zabbix-agent service.</description>
  <port protocol="tcp" port="10050"/>
</service>

Ensuite il faut recharger la configuration en lançant ces quatres commandes :

firewall-cmd --reload
firewall-cmd --add-service=zabbix-agent
firewall-cmd --permanent --add-service=zabbix-agent
firewall-cmd --reload

Si l’option --permanent n’est pas présente, cette configuration ne sera pas conservée après un redémarrage. Si l’option est présente, la configuration ne sera appliquée qu’à partir du redémarrage.

Je ne sais pas pourquoi il faut faire deux fois le --reload. Mais j’ai constaté que s’il n’est fait qu’une seule fois (quelque soit son emplacement), ça ne marche pas.