Forum Linux.debian/ubuntu Pourquoi chrooter bind ?

Posté par  (site web personnel) .
Étiquettes : aucune
2
6
avr.
2009
Bonjour !

Je me demandais que était l'intérêt de chrooter bind, ou d'ailleurs un démon quel qu'il soit... Est-ce que c'est parce que bind a plein de failles ou simplement parce qu'il sera par définition accessible a tout le monde ?

Est-ce que ca ne reviendrait pas au même de simplement le lancer en tant qu'utilisateur non privilégié ?

Merci !!

  • # Limiter les exploits possibles

    Posté par  (site web personnel) . Évalué à 3.

    Un chroot permet de cloisonner un serveur dans un endroit où seul le nécessaire est disponible pour faire fonctionner un service.

    Admettons que le service ait une faille de sécurité grave, exploitable immédiatement et sans correctif disponible (ce que l'on nomme un zero day) et que l'on ait un mauvais karma : la machine se fait pirater.

    Sur un système 'classique' le pirate profite de la faille, s'introduit dans le système, consulte les données présentes et en profite pour installer ses propres outils pour profiter des ressources de la machine.

    Sur un système 'chrooté' le pirate profite de la faille et... il se retrouve dans une grande pièce vide : pas de données utilisateurs ou de fichier de mot de passe, pas de compilateur ou d'interpreteur de script pour ses outils, bref il n'a pas la main sur grand chose.

    C'est là l'intérêt : on isole le service, et ce faisant, en cas de problème, on isole aussi le pirate.

    C'est bien sûr la théorie ; je présume toujours que si quelqu'un a pu rentrer frauduleusement, c'est qu'il y a moyen d'exploiter des choses imprévues et donc que le chroot ne fera que ralentir les choses et pas apporter une sécurité absolue.

  • # Parce que

    Posté par  (site web personnel) . Évalué à 2.

    On chroote des application pour renforcer leur sécurité.

    On le fait plus souvent sur bind car il est connu pour ses faille nombreuses.

    Les démons sont déjà lancé en tant qu'utilisateur particulier et pas en tant que root. Mais supposons qu'il y ait une faille, un inconnu a alors accès au système. Chroot permet de le limiter pour qu'il n'ait accès qu'à une petite sous partie du système, pas à tout.

    • [^] # Re: Parce que

      Posté par  . Évalué à 3.

      Le man chroot ne laisse pas entendre ceci, et donne même un exemple pour s'évader de la prison (si user root je l'accorde).
      chroot n'est pas un gage de sécurité et n'est pas son but d'ailleurs.
      Maintenant, avec un certain patch kernel centré sur la sécurité (et non mainline), c'est déjà un peu mieux.

      • [^] # Re: Parce que

        Posté par  (site web personnel) . Évalué à 4.

        Pas tout à fait.
        Il est parfaitement possible de sortir du chroot lorsqu'on est root.

        Mais un démon comme bind tourne en simple utilisateur. Ce qui fait qu'il faut découvrir une seconde faille à l'intérieur du chroot pour en sortir, ce qui est déjà plus rare.

        • [^] # Re: Parce que

          Posté par  (site web personnel) . Évalué à 6.

          Sauf que le bind dans le chroot n'est pas mis a jour aussi facilement que les binaires de la distribution... Bref, j'ai vu des bind en chroot qui n'étaient clairement plus mis à jour.

          Si chroot, bien penser à la procédure de mise à jour de tout ce qui est dans le chroot.

          • [^] # Re: Parce que

            Posté par  (site web personnel) . Évalué à 1.

            Sauf que le bind dans le chroot n'est pas mis a jour aussi facilement que les binaires de la distribution... Bref, j'ai vu des bind en chroot qui n'étaient clairement plus mis à jour.

            Personnellement je n'utilise bind qu'avec FreeBSD. Je suis assez surpris d'apprendre que certaines distro distribuent un bind non chrooté.

            • [^] # Re: Parce que

              Posté par  . Évalué à 1.

              Je suis surpris que toutes les distros ne fournissent pas par défaut un apache chrooté.

          • [^] # Re: Parce que

            Posté par  (site web personnel) . Évalué à 1.

            Les binaires ne sont pas eux mêmes chrootés, dans le tuto que j'ai suivi tu lui passes juste une option au moment de son démarrage pour lui dire de se chrooter lui même en user bind/named.

            Et après il faut juste lui créer deux trois répertoires dont il a besoin, déplacer les fichiers de config (en faisant un lien symbolique du répertoire des confs vers /etc/bind) et puis après ca roule.

            Avec cette méthode, dans quelle mesure ca pourrait poser un problème lors de l'upgrade du paquet si presqu'aucun fichier ne bouge ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.