Dolibarr V18.0.4 - antivirus clamAV

Bonjour,
Pour éviter de transporter les virus des postes des clients sur leur outil de gestion dolibarr, j’ai tenté de mettre en place sur un des serveurs dolibarr (sous rocky 9) ClamAV.
En principe, pas de souci pour l’installation de ClamAV qui c’est bien passée.
Lors du paramétrage de l’antivirus dans dolibarr je passe par config/sécu et je remplis le champ « Chemin complet vers la commande antivirus » dans l’onglet « Fichiers » comme suit : /usr/bin/clamdscan
J’ai bien entendu vérifié que le fichier est bien présent dans le répertoire.
J’ai également ajouter l’option --fdpass (pas trouvé l’explication sur cette option).
J’ai le retour systématique lors du test :
L’antivirus n’a pas pu valider ce fichier (il est probablement infecté par un virus) !
J’ai vérifier et désactivé mes sécurités (fail2ban, rkhunter et selinux) nada, que tchi !
Une aide serait bienvenue.
Merci.

Bonjour,

c’est une option de clamav qui transmet les droits du fichier à clamav (fdpass comme file descriptor pass), c’est nécessaire car le daemon clamav tourne en principe sous un user différent de phpfpm.

Il y a un autre sujet ouvert sur le même problème sous debian

Vos daemon clamav et freshclam sont-ils actifs ?

Vous devriez avoir quelque chose de similaire avec systemctl

clamav

Merci de votre réponse, du coup j’ai re vérifier l’installation du clamAV et corrigé pour Rocky 9

Ce qui donne :

Le tuto complet est à l’adresse suivante pour ceux qui sont concernés :

Donc, l’anti-virus fonctionne lorsque l’on le lance manuellement :

[root@gestion bin]# clamdscan anaconda-ks.cfg --fdpass
ERROR: Can’t access file /usr/bin/anaconda-ks.cfg

----------- SCAN SUMMARY -----------
Infected files: 0
Total errors: 1
Time: 0.000 sec (0 m 0 s)
Start Date: 2024:01:05 20:02:11
End Date: 2024:01:05 20:02:11
[root@gestion bin]#

Toutefois, l’erreur est la même :frowning:
Je suis dans un contexte selinux. Je vais fouillasser sur le sujet en allant dans le logs.

Si vous avez des pistes, je prends.

Merci de cette réponse qui m’a déjà fait avancer.

Bien,
Si j’ai oublié au début de mon post, méa culpa je vous souhaite à tous et toutes une magnifique nouvelle année 2024. Et je vais être conventionnel sur le sujet : d’abord la santé.
Sur ce problème d’antivirus, mes pistes m’amène sur un problème de droits sur le répertoire /tmp qui appartient à root/root.

Or, l’antivirus fonctionne sur l’utilisateur/groupe clamav.
Je me pose la question si je change les droits en ajoutant rw à tous le monde. Mais franchement c’est bizarre …

Un avis ?

Finalement en allant vérifier les droits sur rw pour tout le monde. Donc , je sèche !

Bonjour,
Peut-être mettre root dans le groupe clamav.

Merci gaecCAB, mais ce n’est pas une solution acceptable.
Cela cré une faille de sécurité (un gigantesque trou !).
Se servir de root pour faire des scans de virus c’est très très dangereux.
Bonne année.

Je relance le sujet car je n’ai toujours pas de solution.
Peux-être avec un débogage pour trouver l’erreur ?
Un piste ?
Merci par avance.

Pour commencer, anaconda-ks.cfg n’est pas supposé se trouver dans /usr/bin.

Pouvez-vous préciser la réponse ?

Vous lancez visiblement la commande clamdscan depuis le répertoire /usr/bin d’après votre invite root@gestion bin
Si le fichier anaconda-ks.cfg se trouve dans /usr/bin vous avez un problème, ce fichier n’a rien à faire là, et anaconda (à moins qu’il ne soit complètement buggué - ce qui serait tout de même étonnant pour l’installateur de RedHat) n’enregistre jamais ce fichier à cet endroit.
Si le fichier anaconda-ks.cfg ne se trouve pas dans /usr/bin il est tout à fait normal que clamdscan ne le trouve pas et renvoie ce message d’erreur.

Bonjour,
N’est-ce pas plutôt /bin ?
Mais votre remarque vaut pour /usr/bin et /bin.

Oui possible, cela dépend de la configuration du prompt shell s’il n’affiche que le dernier répertoire ou le chemin complet.
Je me suis basé sur le message d’erreur où clamdscan cherche le fichier /usr/bin/anaconda-ks.cfg

D’ailleurs, on n’est jamais supposé avoir son shell avec en chemin courant /usr/bin.

Je ne vois pas ce qui peut aboutir à cette situation de façon logique. On n’édite rien dans ce répertoire et on y fait appel qu’au travers du PATH.

Je suggère de vérifier les sauvegardes car peut-être est-ce une question de temps avant d’exécuter une mauvais commande.

Donc maintenant supposons que ce fichier soit ici : /root/anaconda-ks.cfg

Je n’utilise pas clamdcan mais ce que je comprends de la doc :

Pour le scanner, je lance en tant que root :

clamdscan /root/anaconda-ks.cfg

clamdscan envoie le fichier à clamd qui n’a pas besoin d’accéder de lui-même au fichier. Cette opération est potentiellement plus lente que la suivante :

Si je passe la commande fdpass, je donne la permission à clamd d’ouvrir de lui-même le fichier (il court-circuite alors les droits d’accès d’où la situation qui inquiète).

Pas exactement, c’est le file descriptor qui est passé à clamd, donc pas besoin d’avoir les droits sur le fichier, puisque le file descriptor a été obtenu par clamdscan qui lui a les droits du user qui l’execute.
Le file descriptor étant renvoyé par la fonction open

J’ai pris un raccourci d’explication. :nerd_face: Mais hop hop hop est là !

1 « J'aime »

Bonjour à tous et toutes,
Merci de vos retours.

Voici ci-dessous des infos qui vont éclaircir par rapport à vos commentaires :
Je suis connecté en root.
Dans le répertoire /root (home du root)
La distrib est Rocky 9.3 (si cela peut changer quelque chose)
[root@gestion ~]# ls -la
total 76
dr-xr-x—. 7 root root 4096 18 janv. 12:17 .
dr-xr-xr-x. 19 root root 264 11 janv. 12:24 …
-rw-------. 1 root root 1283 12 oct. 19:44 anaconda-ks.cfg
-rw-------. 1 root root 19575 18 janv. 12:17 .bash_history
-rw-r–r–. 1 root root 18 11 mai 2022 .bash_logout
-rw-r–r–. 1 root root 141 11 mai 2022 .bash_profile
-rw-r–r–. 1 root root 429 11 mai 2022 .bashrc
drwx------. 3 root root 20 28 déc. 11:05 .config
-rw-r–r–. 1 root root 100 11 mai 2022 .cshrc
drwx------. 20 root root 4096 19 janv. 03:36 .esmtp_queue
-rwxrwxr-x. 1 clamav clamav 8151 4 juil. 2023 install_monitoring_agent.sh
-rw-------. 1 root root 20 11 janv. 12:22 .lesshst
drwxrwxr-x. 7 clamav clamav 4096 29 mai 2023 linux
-rw-------. 1 root root 483 13 oct. 05:31 .mysql_history
drwx------. 3 root root 21 16 oct. 07:56 snap
drwx------. 2 root root 6 12 oct. 19:36 .ssh
-rw-r–r–. 1 root root 129 11 mai 2022 .tcshrc
-rw-r–r–. 1 root root 342 19 janv. 03:34 .wget-hsts
[root@gestion ~]# pwd
/root
[root@gestion ~]# clamdscan anaconda-ks.cfg --fdpass
/root/anaconda-ks.cfg: OK

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.022 sec (0 m 0 s)
Start Date: 2024:01:19 08:30:51
End Date: 2024:01:19 08:30:51
[root@gestion ~]#

Donc en root et en mode commande cela fonctionne.
Le clamdscan est exécuté avec le user clamscan :

[root@gestion ~]# ps -efd | grep clamd
clamscan 951 1 0 janv.16 ? 00:00:11 /usr/sbin/clamd -c /etc/clamd.d/scan.conf
root 479239 337837 0 08:35 pts/0 00:00:00 grep --color=auto clamd

La seule chose paramétré dans le clam.conf est le user clamscan.

Donc le mode commande fonctionne.

Dans le répertoire /bin :
[root@gestion ~]# cd /bin/
[root@gestion bin]# ll | grep clam
-rwxr-xr-x. 1 root root 126208 29 oct. 17:57 clambc
-rwxr-xr-x. 1 root root 130304 29 oct. 17:57 clamconf
-rwxr-xr-x. 1 root root 147032 29 oct. 17:57 clamdscan
-rwxr-xr-x. 1 root root 147000 29 oct. 17:57 clamdtop
-rwxr-xr-x. 1 root root 167448 29 oct. 17:57 clamscan
-rwxr-xr-x. 1 root root 130352 29 oct. 17:57 clamsubmit
-rwxr-xr-x. 1 root root 44368 29 oct. 17:57 freshclam
[root@gestion bin]#
on retrouve bien les commandes clam et notamment le clamdscan.
Peut-être devrais-je changer le user de ces commandes vers clamav ou le groupe virusgroup ?

Je me replonge dans le selinux au cas ou le contexte aurait évoluer sur mon serveur.

Merci dans tous les cas de vos pistes.

Après vérification par un arrêt de selinux, le problème est persistant. Ce n’est donc pas une problème de selinux.
Je vais faire un tour sur les logs de clamav.

L’erreur ne départ est en français, ça rend difficile de savoir mais ce n’est pas dit que c’est un problème de droit d’accès. Il dit qu’il ne sait pas s’il y a un virus ou non donc il sert à rien.

Il faut relancer la commande en anglais et chercher sur google :

LANG=US clamdscan …

Il affichera son message en anglais et ensuite => google.