Introduction à Hardened GentooCe guide est conçu pour clarifier les différents aspects du projet Hardened Gentoo (Gentoo sécurisé), expliquer leurs usages complémentaires et détailler leurs rôles respectifs dans le projet. Le principe de sécurité que nous mettons en œuvre est le principe de la sécurité par couches. Ce principe est fondamental pour assurer qu'une machine ne puisse être compromise et, si elle l'est, pour minimiser les dégâts. En combinant une série de technologies de sécurité différentes, nous obligeons un intrus à franchir plusieurs obstacles avant qu'il ne soit en mesure de compromettre un système. Pour cette raison nous recommandons toujours que vous déterminiez vos besoins spécifiques et qu'en fonction de ces besoins vous combiniez ces solutions pour protéger votre système. Dans ce document, nous allons essayer de vous expliquer ces options et de quelle manière elles peuvent se combiner. Hardened Gentoo, en soi, n'est pas un produit ou une solution. Il s'agit simplement d'un projet regroupant des développeurs travaillant tous dans un même but : la sécurité active. Les sous-projets qui composent Hardened Gentoo n'ont d'autres liens, entre eux, que d'appartenir au projet principal. Vous pouvez vous représenter de la même manière KDE et GNOME qui sont tous deux des projets de gestionnaire de bureau : Ils ont un but commun, mais ne sont pas liés entre eux.
PaX est au cœur du projet. PaX est un correctif (patch) du noyau qui permet de se protéger contre les dépassements de tampons et de tas (buffer et heap overflows) et contre les attaques similaires. PaX est votre première ligne de défense. En raison de la mauvaise conception de certains logiciels, vous êtes en permanence susceptibles d'être attaqué par dépassement de tampon ou de tas. Les dépassements de tampons et de tas peuvent être exploités lorsque des applications ne vérifient pas les limites des données saisies par l'utilisateur. Lorsqu'un intrus, par le biais d'une application, a la possibilité d'insérer des données directement en mémoire, sans qu'elles soient vérifiées par l'application, il y a risque de dépassement. Des langages de programmation bas niveau tels que C et C++ ne protègent pas automatiquement contre les dépassements. Il en résulte que lorsqu'un tampon est dépassé, le code adjacent peut être récrit par les données saisies par l'utilisateur. Cela devrait provoquer un crash de l'application si le code saisi par l'utilisateur n'est pas « compris » par la machine. Cela se manifeste généralement par une erreur de pagination (page fault) parce que les caractères qui dépassent le tampon et entrent dans la zone de l'exécutable sont traités comme des adresses qui n'existent (probablement) pas. C'est le résultat le plus bénin d'un dépassement. Toutefois, si l'attaquant connaît une faille de ce type, il aura l'opportunité d'ajouter du shellcode à sa saisie et, plutôt que de provoquer un crash de l'application, la machine exécutera les instructions fournies dans la portion « dépassante » des données saisies. Le shellcode le permet puisque c'est de cette manière que les instructions sont stockées en mémoire pour être exécutées par le processeur. Le shellcode se compose d' « opcodes » qui se traduisent par des routines en assembleur. Un attaquant connaît ces « opcodes » sur le bout des doigts et peut créer du shellcode qui lui permet de faire tout ce qu'il veut ; par exemple : exécuter un shell en tant que root et l'attacher à un port. Lorsque cela se produit, l'utilisateur légitime ne s'en aperçoit pas puisque l'application ne crash pas et le code arbitraire de l'attaquant lui permet alors de faire ce qu'il souhaite. PaX permet de mitiger ce problème en plaçant en mémoire, de manière aléatoire, chaque fonction et tampon des applications. Cela s'appelle ASLR ou Address Space Layout Randomization (couche d'espace d'adresse aléatoire) et c'est la pierre angulaire de PaX. En attribuant les espaces mémoire de manière aléatoire pour toutes les fonctions et tampons, l'attaquant est incapable de produire une saisie qui garantit que son shellcode sera exécuté (ce qui rend sa tâche très difficile puisque l'application crashera probablement et qu'elle sera redémarrée dans d'autres espaces mémoire choisis aléatoirement). ASLR est plus utile quand il est utilisé avec du code PIE (Position Independent Executable), mais il fonctionne également avec du code standard ce qui impose, toutefois, une charge supplémentaire au système. PaX offre également la possibilité aux segments exécutables d'être exécutables, mais sans accès en écriture ou avec accès en écriture, mais non exécutable. Cela s'appelle pageexec. Il n'est pas possible de réaliser cela au niveau matériel sur les processeurs à base de x86 étant donné que les concepteurs de cette architecture, pour gagner de la place, ont rassemblé les deux indices « exécutable » et « accès en écriture » en un seul indice. Puisque qu'une « page » devrait avoir soit l'accès en écriture, soit l'accès en lecture et en exécution, il ne sert à rien de paramétrer les tampons en « non exécutables » puisqu'on ne pourrait alors plus les lire. Par conséquent, sur les architectures à base de x86, PaX émule ce comportement au niveau logiciel, ce qui induit une charge supplémentaire sur le système, mais est une aide précieuse pour la sécurité. PIE et SSP (Stack Smashing Protection - Protection contre la corruption de pile) sont généralement groupés dans les discussions parce qu'ils font partie de la même chaîne d'outils « hardened ». Cependant, afin de clarifier les choses, PIE et SSP ont des technologies et des objectifs différents. PIE seul n'apporte aucune amélioration à la sécurité mais, lorsqu'il est combiné avec PaX dans le noyau, c'est un outil puissant contre les dépassements. SSP est entièrement implémenté dans le domaine utilisateur et protège contre les attaques stack smashing sans l'assistance du noyau. Puisqu'ils sont implémentés séparément et qu'ils n'agissent pas au même niveau, ils représentent deux couches de protection. Par exemple, une attaque nommée ret2libc pourrait passer PaX sans encombre, mais serait bloquée par SSP. Nous avons déployé de grands efforts pour fournir aux utilisateurs une manière facile de construire l'espace utilisateur avec du code PIE afin de bénéficier de l'ASLR avec très peu de surcharge sur le système. En plus de PIE, notre chaîne d'outils « hardened » fournit également SSP. SSP protège contre les attaques stack smashing en allouant un espace en dehors des tampons et en lui attribuant un « canari » (un marqueur) aléatoire et crypté. Si le canari a été écrasé après une écriture sur le tampon, SSP sera alors en mesure de le détecter et de tuer l'application exploitée. La chaîne « hardened » offre aux utilisateurs un espace utilisateur PIE/SSP de la manière la plus facile qui soit. Les « stages » estampillés « hardened » sont des stages standards construits avec PIE et SSP. Ils n'incluent pas les contrôles d'accès SELinux/RSBAC/grsecurity. Contrôles d'accès obligatoires PaX est sans doute la première couche de protection, peut-être la deuxième ou la troisième si vous avez un firewall et/ou une solution de détection d'intrusion réseau. Il est également recommandé d'utiliser le contrôle des accès pour améliorer la sécurité de votre système. Il est très important que vous vous représentiez le contrôle des accès comme la dernière couche de protection. Le contrôle des accès est très utile pour contenir un attaquant ayant déjà accès à votre système ou à vos utilisateurs locaux. Actuellement, « Hardened Gentoo » supporte 3 solutions de contrôle des accès : SELinux, grsecurity et RSBAC. Si vous souhaitez utiliser grsecurity, vous n'avez pas à vous soucier des stages puisque grsecurity ne requiert aucune modification de l'espace utilisateur. Utilisez simplement les stages « hardened » et, une fois que vous serez prêt à construire le noyau, utilisez un noyau compatible grsecurity tel que « hardened-sources ». Une fois que votre système est fonctionnel vous pouvez utiliser le mode d'apprentissage de grsecurity pour construite les ACL's pour votre système. De même que grsecurity, RSBAC ne requiert pas de modifications dans l'espace utilisateur, mais peut, en revanche, être installé après une installation Gentoo normale. RSBAC est supporté par le noyau « rsbac-sources ». Une fois que votre système est fonctionnel vous pouvez choisir parmi les différents modèles de contrôle d'accès RSBAC puisqu'ils se présentent tous sous la forme de modules. La documentation Gentoo de RSBAC liste les différents modèles offerts et donne plus d'information sur chacun d'eux. Nous avons donc parlé des deux couches de protection que nous offrons. Nous avons l'intention d'en fournir plus dans le futur. Des exemples de couches supplémentaires sont la détection/prévention d'intrusion qui deviendrait alors la première couche, avant même PaX ; Le cryptage de disques et des partitions d'échange (swap) qui permet une protection contre les failles « physiques »; Les audits, qui permettent de détecter et d'agir selon les risques, avant qu'il ne se transforment en « système compromis ». Le cryptage des flux réseau et l'authentification forte sont des couches qui sont fort bien supportées par Linux en standard et qui ne seront probablement pas abordées ici.
Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5. |
|