Pourquoi chroot est considéré comme peu sûr?

Je joue avec CentOS Box depuis quelques années maintenant. Je suis donc assez à l'aise avec le terminal. Cependant, j'ai lu beaucoup de billets de blog affirmant que chroot n'est pas sûr et que la quantité de ces messages fait peur. En est-il vraiment ainsi? Pourquoi?

J'utilise chroot pour verrouiller les utilisateurs SFTP uniquement dans un contexte spécifique, sans aucun shell ni commande. Alors vraiment, quel est le problème de sécurité avec ça?

La question est exilée de StackOverflow .

— Aleksandr Makov
source

Premièrement: la question n'a pas été fermée / migrée sur Stack Overflow , mais c'est clairement OT là. L'action appropriée serait d'attendre qu'il soit migré ou de le signaler et de demander à un mod de le faire, et non de le publier sur un autre site. Mais deuxièmement: si vous "jouez avec CentOS", vous vous trompez également ici. Ce site est destiné aux administrateurs système professionnels, pas aux amateurs - veuillez consulter notre FAQ .

— Sven

@SvenW merci, je garderai à l'esprit votre conseil pour l'avenir. Et à propos de la «seconde», eh bien, désolé, mais je ne vois pas comment ma question viole la FAQ. Après l'avoir lu deux fois maintenant, je peux dire que non. En ce qui concerne la phrase "jouer avec CentOS", eh bien, je pensais qu'il était assez évident que les utilisateurs chrootants et SFTP uniquement et être pris en compte sur la sécurité est un sujet très sérieux dont les professionnels peuvent bénéficier aussi bien dans leur entreprise que dans n'importe quel autre " environnements professionnels.

— Aleksandr Makov

@sven au cas où vous ne le sauriez pas, SF a été supprimé de la liste de migration de SO en raison du nombre de mauvaises questions qu'il nous envoie.

— MDMarra

Réponses:

Parce que, dans la plupart des cas, un processus racine peut facilement quitter le chroot. C'est de par leur conception, car chroot n'a jamais été conçu comme un dispositif de sécurité.

Alan Cox a quelque peu réprimandé un développeur qui a soumis un correctif de noyau pour «corriger» ce comportement, affirmant que chroot a été utilisé à mauvais escient en tant que dispositif de sécurité, mais n'a jamais été conçu pour en être un.

— MDMarra
source

Parfait! Merci beaucoup. Il s'agit donc de processus racine présents dans la racine ou accessibles depuis celle-ci. Merci.

— Aleksandr Makov

Je viens de vérifier qu'en exécutant le programme C montré sur unixwiz.net/techtips/mirror/chroot-break.html en tant que root sur Linux 4.18, il est possible d'échapper au chroot.

— pts

Alors, ne donnez pas de privilèges root. Même les systèmes "sécurisés" classiques ont des comptes root.

— Cees Timmerman du

Je connais au moins un exemple des raisons pour lesquelles il est considéré comme peu sûr. Un environnement chroot /procn'est pas isolé, il est donc assez facile d'accéder aux ressources n'appartenant pas aux processus démarrés dans votre chroot.

L'utilisation d'un environnement chrooté pour SFTP est correcte et améliore considérablement le niveau de sécurité. Ne l'abusez pas comme une virtualisation basée sur des conteneurs, qui offre plus de niveaux de sécurité. En cela, je souligne ce qui se trouve dans la réponse de @ MDMarra.

— gertvdijk
source

Je vous remercie. Alors maintenant, il devient plus clair que le chroot lui-même n'est pas pauvre en sécurité mais sa sécurité dépend plutôt de l'environnement où il est installé.

— Aleksandr Makov

En fait, chroot n'est pas pauvre en matière de sécurité, car il n'a jamais été conçu pour être un dispositif de sécurité. Il devait être un outil de développement pour exécuter plusieurs versions des mêmes binaires côte à côte avec différentes dépendances. Ce n'est pas un substitut pour sécuriser correctement les services - même si cela peut être utile dans certaines circonstances tant que vous comprenez ce que c'est et ce que ce n'est pas.

— MDMarra

MDMarra, donc en gros, chroot n'est pas destiné à être utilisé pour capturer des connexions SSH. À votre avis, est-ce que "chrooter les connexions SSH entrantes" vous semble quelque peu peu professionnel et devrait-il être évité?

— Aleksandr Makov

Non, pas nécessairement, réalisez simplement que tout exploit qui pourrait entraîner une élévation de privilèges ou tout processus s'exécutant en tant que root dans le chroot serait banal. Cela peut certainement être une pièce du puzzle, mais cela ne devrait pas être le tout.

— MDMarra