Bon, d'autres ont attaqués les autres arguments, je me fais celui-ci: On Fri, Nov 25, 2005 at 06:22:36PM +0100, Marc PERRUDIN wrote: > Un argument pour le monolithique: c'est plus sure. En effet, chaque fois > que j'echange avec un specialiste de la sécurité, il ne jure que par le > monolithique car ca permet d'empecher les attaques de type LKM (ces > modules, du fait qu'ils sont directement dans le noyau, contourne une > grande part des outils de detections et sont très difficiles a reperer). > Il faut pour cela faire un noyau monolithique qui interdit completement > les modules et donc faire un noyau qui corresponde exactement a la > config materielle.
La faille de sécurité, c'est quand un ennemi prend le contrôle de root. Dès lors que root est perdu, la machine est perdue. Penser que l'interdiction de charger des modules met la machine en sécurité, c'est la même chose que se cacher derrière l'illusoire sécurité d'un mot de passe (composé préférablement de 2 caractères au moins). On ne le répètera jamais assez, root a tous les droits. En particulier, il a le droit d'aller lire et écrire dans /dev/mem (et de créer /dev/mem si un petit malin l'a retiré). Il a aussi le droit d'aller écrire dans /proc/kcore. Rajouter du code noyau à partir de là est plus difficile qu'avec un module, certe, mais c'est tout de même possible. Pour construire un système sûr, il ne suffira pas de désactiver ces fonctions du noyau: un intrus peut toujours cacher ses processus en remplaçant subrepticement la commande ps, la libc qui renvoie les résultats, etc. Plus les autres méthodes qui existent peut-être pour aller changer le code du noyau que je ne connais pas (changer la zimage du noyau et attendre le prochain reboot?). (je pense à tout ça sans être un spécialiste. je vous laisse imaginer ce à quoi un cracker motivé pourrait arriver?) Tiens, existe-t-il une méthode pour vérifier l'intégrité du noyau (genre checksum sur le code) pendant son fonctionnement? Y. -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
