préambule
Je continue d'entendre les gens réitérer les idées fausses de partout sur Internet.
tout d'abord; Combien de découvertes accidentelles y a-t-il eu, qui simplement ... en raison de cause à effet , ont fini par être utilisées pour autre chose que sa destination?
ce qui était et ce qui est une prison Chroot
Chroot a été initialement conçu pour changer le répertoire racine du processus ou de l'utilisateur (idéal pour la compilation de logiciels à partir de sources inconnues). cela a assuré la sécurité du système de base, ainsi qu'un appareil de banc d'essai rapide, y compris un nettoyage facile. des années ont passé depuis, et son concept et ses utilisations implicites ont certainement changé, de même.
chroot a été utilisé efficacement et se trouve directement dans la base de code de plusieurs programmes et bibliothèques (c'est-à-dire openSSHd, apache2 + mod_security2 / mod_chroot, dovecot, sendmail, openVPN, pam_chroot, et bien plus encore ). supposer que toutes ces applications grand public ont implémenté des solutions de sécurité défectueuses n'est tout simplement pas vrai
chroot est une solution pour la virtualisation du système de fichiers: rien de moins, rien de plus. l'hypothèse selon laquelle vous pouvez facilement sortir d'un chroot n'est pas non plus vraie ... tant que vous respectez les directives d'exécution des processus à l'intérieur de la prison chroot.
quelques étapes pour sécuriser votre prison chroot
c'est-à-dire NE PAS exécuter les processus comme ROOT. cela pourrait ouvrir un vecteur d'escalade racine (ce qui est également vrai à l'intérieur ou à l'extérieur du chroot). n'exécutez pas de processus à l' intérieur du chroot, en utilisant le même utilisateur qu'un autre processus en dehors du chroot. séparer chaque processus et utilisateur dans son propre Chroot afin de limiter les surfaces d'attaque et assurer la confidentialité. montez uniquement les fichiers, bibliothèques et périphériques nécessaires. enfin, chroot NE remplace PAS la sécurité du système de base. sécuriser le système dans son intégralité.
une autre note importante: beaucoup de gens pensent qu'OpenVZ est cassé, ou qu'il n'est pas égal par rapport à la virtualisation complète du système. ils font cette hypothèse car il s'agit essentiellement d'un Chroot, avec une table de process qui a été stérilisée. avec des mesures de sécurité en place sur le matériel et les appareils. dont la plupart peuvent être implémentées dans un chroot.
tous les administrateurs n'ont pas le niveau de connaissances requis pour sécuriser tous les paramètres de noyau nécessaires sur un serveur dédié ou sous une virtualisation complète du système. cela signifie que le déploiement d'OpenVZ signifie que vos clients auront beaucoup moins de surface d'attaque pour essayer de couvrir et de sécuriser avant de déployer leurs applications. un bon hôte fera un bon travail en sécurisant ces paramètres, et à son tour, cela vaut mieux non seulement pour tout le monde sur le nœud ou dans le centre de données, mais pour Internet dans son ensemble ...
comme indiqué, le chroot fournit la virtualisation du système de fichiers. vous devez vous assurer qu'il n'y a pas d'exécutables setuid, d'applications non sécurisées, de bibliothèques, de liens symboliques sans propriétaire, etc. d'une autre manière, compromettre quelque chose résidant à l'intérieur du chroot, échappant à la prison, généralement par une escalade de privilèges ou en injectant sa charge utile dans le système de base.
si cela se produit, c'est généralement le résultat d'une mauvaise mise à jour, d'un exploit de jour nul ou d' une erreur humaine idiomatique .
pourquoi chroot est toujours utilisé, par opposition à la virtualisation complète du système
considérez ce scénario: vous exécutez un serveur privé virtuel, avec le nœud hôte exécutant OpenVZ. vous ne pouvez tout simplement pas exécuter quoi que ce soit qui fonctionne au niveau du noyau. cela signifie également que vous ne pouvez pas utiliser la virtualisation du système d'exploitation pour séparer les processus et fournir une sécurité supplémentaire. ainsi, vous DEVEZ utiliser chroot à cet effet.
de plus, chroot est durable sur n'importe quel système, quelles que soient les ressources disponibles. Autrement dit, il a le moins de frais généraux de tout type de virtualisation. cela signifie qu'il est toujours important sur de nombreuses boîtes bas de gamme.
considérez un autre scénario: vous avez apache exécuté dans un environnement virtualisé. vous souhaitez séparer chaque utilisateur. la fourniture d'un système de fichiers virtualisé via un chroot ajouté à apache (mod_chroot, mod_security, etc.) serait la meilleure option pour assurer la plus grande confidentialité entre les utilisateurs finaux. cela permet également d'éviter la collecte d'informations et offre une autre couche de sécurité.
Autrement dit, il est important de mettre en œuvre la sécurité dans les couches . Chroot étant potentiellement l'un d'entre eux. tout le monde et chaque système n'ont pas le luxe d'avoir accès au noyau, par conséquent, chroot STILL sert toujours un but. il existe une variété d'applications dans lesquelles la virtuaisation complète du système est essentiellement excessive.
En réponse à votre question
je n'utilise pas particulièrement CentOS, mais je sais que Bind abandonne désormais ses privilèges avant les opérations. je suppose cependant que la liaison est chrootée en raison de son historique de vecteurs d'attaque et de vulnérabilités potentielles.
aussi ... il est plus logique de chrooter automatiquement cette application, que non, car tout le monde n'a pas accès à la virtualisation complète au niveau du système / système d'exploitation. ceci, à son tour, et en théorie, contribue à assurer la sécurité de la base d'utilisateurs CentOS:
les fournisseurs de systèmes d'exploitation ne font tout simplement pas l'hypothèse que chacun exécute le même système. de cette façon, ils peuvent aider à fournir une couche de sécurité supplémentaire dans son ensemble ...
il y a une raison pour laquelle tant d'applications utilisent cela , et pourquoi évidemment votre système d'exploitation le fait par défaut: car il EST utilisé comme une fonction de sécurité, et cela fonctionne. avec une préparation minutieuse, comme indiqué précédemment, c'est encore un autre obstacle que l'attaquant potentiel doit surmonter la plupart du temps, limitant les dommages à la seule prison chroot.