Il y a eu une série de débats sur la LKML récemment, car des éditeurs d'antivirus souhaitaient implémenter et faire intégrer des API permettant ce type de fonctionnalités dans le noyau Linux.
Un "cas d'utilisation" standard et clair était justement ce qui faisait défaut, lors de la première tentative d'introduction. Ou plutôt, il manquait la description précise de la menace dont c'était censé nous protéger : les exigences ne sont pas les mêmes selon qu'on cherche à protéger contre une attaque fine et ciblée - ie. un daemon root qui exécute du code arbitraire choisi sur mesure par un humain finira par prendre le dessus sur l'antivirus dans le noyau dans tout les cas (ce type de menaces est plutôt couvert par SELinux) - ou contre un code malicieux mais non ciblé, exécuté bêtement par un simple utilisateur imprudent... Il faut bien dire que cette façon de concevoir la protection contre les attaques (une protection facile à contourner mais qui serait suffisante pour s'épargner les bourinages de masse) est plutôt étrangère aux devs Linux.
A la seconde tentative de discussion, les développeurs d'antivirus ont finalement présenté leurs cas d'utilisation nécessitant une plus grande coopération du kernel. Le risque décrit était plutôt l'utilisation de Linux comme un serveur de fichier (samba, nfs, ftp, scp, ...) ou relayant des fichiers (mail, ...). Pour qu'un tel serveur ne soit pas une "zone d'ombre" du SI non protégée, permettant le stockage des virus, et exposant les postes clients, il faudrait intercepter les écritures sur son disque. Utiliser des hooks dans les services (comme ce que permettent Samba ou Postfix) est une solution efficace mais ne couvre pas tout les cas, et il est inenvisageable d'intégrer un hook vers un antivirus dans tout les daemons Linux possibles. Utiliser LD_PRELOAD et surcharger les fonctions open() & co ne couvre pas non plus tout les cas (le serveur nfs tourne dans le noyau, donc pas de lib, le preload ne marche pas pour les daemons liés statiquement, est ignoré par les binaires suid, et il faudrait surcharger les mille et une façons qu'offre linux pour écrire dans un fichier). Inotify ne leur convient pas non plus (notamment parce qu'il ne peux surveiller qu'un nombre limité de fichiers).
Ces débats sont amusants, il y a un coté "choc des cultures". Et c'est intéressant de constater que plusieurs éditeurs d'antivirus tentent de fournir du code noyau libre, et consacrent pas mal d'efforts pour faire merger ce travail (au point qu'ils ont finis par faire appel aux services de Red Hat pour concevoir le design de l'API dont ils avaient besoin, mais le dev. RH sur le coup n'a lui non plus pas encore réussi à proposer de solution qui convainque tout le monde). Beaucoup de pointures participaient aux débats (Alan Cox, Arjan van de Ven, Greg Kroah-Hartman, James Morris, Al Viro, Andi Kleen, Theodore Tso, Nick Piggin, Rieck van Riel, Christoph Hellwig, ...).
[^] # Re: Et la quarantaine et le système restore
Posté par herodiade . En réponse au journal Rions un peu avec les antivirus. Évalué à 4.
Un "cas d'utilisation" standard et clair était justement ce qui faisait défaut, lors de la première tentative d'introduction. Ou plutôt, il manquait la description précise de la menace dont c'était censé nous protéger : les exigences ne sont pas les mêmes selon qu'on cherche à protéger contre une attaque fine et ciblée - ie. un daemon root qui exécute du code arbitraire choisi sur mesure par un humain finira par prendre le dessus sur l'antivirus dans le noyau dans tout les cas (ce type de menaces est plutôt couvert par SELinux) - ou contre un code malicieux mais non ciblé, exécuté bêtement par un simple utilisateur imprudent... Il faut bien dire que cette façon de concevoir la protection contre les attaques (une protection facile à contourner mais qui serait suffisante pour s'épargner les bourinages de masse) est plutôt étrangère aux devs Linux.
A la seconde tentative de discussion, les développeurs d'antivirus ont finalement présenté leurs cas d'utilisation nécessitant une plus grande coopération du kernel. Le risque décrit était plutôt l'utilisation de Linux comme un serveur de fichier (samba, nfs, ftp, scp, ...) ou relayant des fichiers (mail, ...). Pour qu'un tel serveur ne soit pas une "zone d'ombre" du SI non protégée, permettant le stockage des virus, et exposant les postes clients, il faudrait intercepter les écritures sur son disque. Utiliser des hooks dans les services (comme ce que permettent Samba ou Postfix) est une solution efficace mais ne couvre pas tout les cas, et il est inenvisageable d'intégrer un hook vers un antivirus dans tout les daemons Linux possibles. Utiliser LD_PRELOAD et surcharger les fonctions open() & co ne couvre pas non plus tout les cas (le serveur nfs tourne dans le noyau, donc pas de lib, le preload ne marche pas pour les daemons liés statiquement, est ignoré par les binaires suid, et il faudrait surcharger les mille et une façons qu'offre linux pour écrire dans un fichier). Inotify ne leur convient pas non plus (notamment parce qu'il ne peux surveiller qu'un nombre limité de fichiers).
Ces débats sont amusants, il y a un coté "choc des cultures". Et c'est intéressant de constater que plusieurs éditeurs d'antivirus tentent de fournir du code noyau libre, et consacrent pas mal d'efforts pour faire merger ce travail (au point qu'ils ont finis par faire appel aux services de Red Hat pour concevoir le design de l'API dont ils avaient besoin, mais le dev. RH sur le coup n'a lui non plus pas encore réussi à proposer de solution qui convainque tout le monde). Beaucoup de pointures participaient aux débats (Alan Cox, Arjan van de Ven, Greg Kroah-Hartman, James Morris, Al Viro, Andi Kleen, Theodore Tso, Nick Piggin, Rieck van Riel, Christoph Hellwig, ...).
http://lwn.net/Articles/260918/
http://lwn.net/Articles/292872/
http://kerneltrap.org/mailarchive/linux-kernel/2008/8/18/297(...)