Guide pratique de l'utilisation de BIND en environnement restreint

Adaptation française du guide pratique Chroot-BIND HOWTO

Adaptation française: Vincent Loupien

Préparation de la publication de la v.f.: Jean-Philippe Guérard

Version : 1.5.fr.0.9

28 juin 2004

Résumé

Ce document décrit l'installation du serveur de noms BIND 9 fonctionnant dans un environnement restreint en tant qu'utilisateur non-root, pour fournir une sécurité améliorée et pour réduire au minimum les effets potentiels d'une compromission. Notez que ce document a été mise à jour pour BIND 9 ; si vous faites fonctionner un BIND 8, vous avez besoins du guide pratique de l'utilisation de BIND 8 en environnement restreint à la place.


Table des matières

1. Introduction
1.1. Objet de ce document
1.2. Pourquoi ?
1.3. Où ?
1.4. Comment ?
1.5. Mise en garde
2. Préparation de l'environnement restreint
2.1. Création d'un utilisateur
2.2. Arborescence de répertoire
2.3. Mise en place des données de BIND
2.4. Fichiers pour le support du système
2.5. Journalisation des évènements
2.6. Restreindre les permissions
3. Compiler et installer votre beau BIND tout neuf
3.1. Compiler
4. Installer votre beau BIND tout neuf
4.1. Installer les binaires
4.2. Mise en place du script d'init
4.3. Changement de configuration
5. La fin
5.1. Lancement de BIND
5.2. Voilà !
A. Annexes
1. Mises à jour ultérieures de BIND
2. Remerciements
3. Politique de distribution de ce document

1. Introduction

Ceci est le guide pratique de BIND en environnement restreint ; allez voir Section 1.3, « Où ? » pour le site principal, qui contient la version la plus récente de ce document. Nous supposons que vous savez déjà configurer et utiliser BIND (le serveur de Noms de Domaines Internet de Berkeley). Si ce n'est pas le cas, je vous recommande de lire d'abord le guide pratique du DNS (DNS HOWTO). Nous supposons également que vous avez une connaissance suffisante de compilation et d'installation d'un logiciel sur votre système de type Unix.

1.1. Objet de ce document

Ce document décrit quelques précautions de sécurité supplémentaires que vous pouvez prendre quand vous installez BIND. Il explique comment configurer BIND de sorte qu'il réside dans un environnement restreint, ceci signifiant qu'il ne peut pas voir ou avoir accès aux fichiers à l'extérieur de sa propre arborescence. Nous le configurerons également pour l'exécuter en tant qu'utilisateur non-root.

Le principe d'un environnement restreint est assez simple. Lorsque vous exécutez BIND (ou tout autre processus) dans un environnement restreint (c'est-à-dire avec une racine différente du système de fichier — d'où le nom de la commande utilisée « chroot », c'est-à-dire, en anglais, « changer la racine »), le processus ne peut tout simplement pas voir les autres parties du système de fichiers en dehors de son environnement. Vous avez probablement déjà rencontré un environnement restreint auparavant, si vous avez déjà fait un ftp vers un serveur de fichier public.

Parce que le processus d'environnement restreint est beaucoup plus simple avec BIND 9, je vais commencer par légèrement développer ce document, pour y inclure plus d'astuce générale sur la manière de sécuriser une installation de BIND. Néanmoins, ce document n'est pas (et ne souhaite pas devenir) une référence complète pour la sécurisation de BIND. Si vous faites uniquement ce qui est décris dans ce document, vous n'avez pas encore terminé de sécuriser votre serveur de nom !

1.2. Pourquoi ?

Le principe lors de l'exécution de BIND dans un environnement restreint est de limiter la quantité d'accès que n'importe quel individu malveillant pourrait gagner en exploitant une des vulnérabilités de BIND. C'est pour la même raison que nous exécutons BIND en tant qu'utilisateur non-root.

Ceci devrait être considéré comme un supplément aux précautions normales de sécurité (exécution de la dernière version, utilisation des listes de contrôle d'accès, et cætera), et non pas comme une solution de remplacement de ces dernières.

Si la sécurité du DNS vous intéresse, quelques autres produits pourraient également vous intéresser. Compiler BIND avec StackGuard peut être une bonne idée pour assurer une plus grande protection. Son utilisation est simple ; elle équivaut à utiliser un gcc standard. Il existe aussi une alternative sécurisée à BIND, DNScache, écrit par Dan Berstein. Dan est l'auteur de qmail et DNScache semble en suivre la même philosophie.

1.3. Où ?

La dernière version de ce document est toujours disponible à partir du site Web des Utilisateurs de Linux/Logiciel Libre de Regina, Sask., à l'adresse http://www.losurs.org/docs/howto/Chroot-BIND.html.

Il existe maintenant une traduction japonaise de ce document, maintenue par . Elle est disponible à l'adresse http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html. BIND est disponible à l'adresse de l'Internet Software Consortium à l'adresse http://www.isc.org/bind.html. Au moment de la publication de ce document, la version courante de BIND 9 est 9.2.0. BIND 9 est sortie depuis longtemps maintenant, et beaucoup de personnes l'emploient en production. Néanmoins, encore plus de conservateurs préfèrent demeurer en BIND 8. Si vous êtes une telle personne, lisez s'il vous plaît mon Guide pratique de l'utilisation de BIND 8 en environnement restreint (disponible au même endroit) pour les conseils de son exécution en environnement restreint, mais soyez averti que BIND 8 est moins proprement exécutable en environnement restreint. Gardez à l'esprit que des trous de sécurité sont connus dans toutes les versions de BIND, assurez-vous que vous exécutez bien la dernière version !

1.4. Comment ?

J'ai écrit ce document à partir de mon expérience du paramétrage de BIND dans un environnement restreint. Dans mon cas, j'avais déjà un BIND en exploitation sous la forme d'un paquet provenant de ma distribution Linux. Je vais supposer que beaucoup d'entre vous êtes dans la même situation, que vous allez juste récupérer et modifier les fichiers de configuration provenant de votre installation actuelle de BIND, puis désinstaller le paquet avant d'installer le nouveau. Ne désinstallez pas le paquet tout de suite ; nous pourrions avoir besoin d'y récupérer quelques fichiers.

Si vous n'êtes pas dans ce cas, vous devriez néanmoins être capable de comprendre ce document. La seule différence est que, lorsque je copie un fichier existant, vous devrez d'abord le créer vous-même. Le guide pratique du DNS peut être utile pour cela.

1.5. Mise en garde

Cette procédure a fonctionné pour moi, sur mon système. Vous pouvez avoir à la modifier. Ce n'est qu'une façon d'aborder la question ; il y a d'autres moyens d'arriver à la même solution (cependant l'approche restera la même). Il s'est juste trouvé que ma première tentative a fonctionné,et j'ai donc tout noté.

À ce jour, mon expérience de BIND se limite à l'installation sur des serveurs Linux. Cependant, la plupart des instructions dans ce document doivent être facilement applicables à d'autres saveurs d'UNIX, et j'essaierai d'indiquer les éventuelles différences dont j'ai la connaissance. J'ai également reçu des suggestions de personnes utilisant d'autres distributions et d'autres plates-formes, et j'ai essayé d'incorporer leurs commentaires lorsque cela était possible.

Si vous utilisez Linux, vous devez être sur que vous utilisez un noyau 2.4 avant d'essayer ceci. Le paramètre -u (exécution par un utilisateur non-root) a besoin de ce nouveau noyau.

2. Préparation de l'environnement restreint

2.1. Création d'un utilisateur

Comme cela est mentionné dans l'introduction, il n'est pas conseillé de faire fonctionner BIND en root. Ainsi, avant de commencer, créons un utilisateur spécifique pour BIND. Notez que vous ne devez jamais employer un utilisateur générique comme nobody pour cela. Ainsi, quelques distributions, comme SuSE et Mandrake Linux ont commencé à fournir un utilisateur spécifique (généralement appelé named) ; vous pouvez simplement adapter cet utilisateur à nos desseins, si vous le souhaitez. Ceci exige l'ajout d'une ligne comme celle qui suit dans /etc/passwd :

named:x:200:200:Nameserver:/chroot/named:/bin/false

Et une comme ceci dans /etc/group :

named:x:200:

Ceci crée un utilisateur et un groupe appelés named pour BIND. Assurez-vous que les UID et les GID (les deux à 200 dans cet exemple) sont uniques sur votre système. L'interpréteur de commande est mis à /bin/false parce que cet utilisateur n'aura jamais besoin de se connecter.

2.2. Arborescence de répertoire

Nous devons maintenant mettre en place l'arborescence de répertoire que nous allons utiliser pour l'environnement restreint dans lequel BIND s'exécutera. Cela peut être n'importe ou dans votre système de fichiers ; celui qui est vraiment paranoïaque pourra même la mettre dans un volume séparé. Je supposerai que vous emploierez /chroot/named. Commençons en créant l'arborescence de répertoire suivante :

/chroot
  +-- named
       +-- dev
       +-- etc
       |    +-- namedb
       |         +-- slave
       +-- var
            +-- run

Si vous utilisez la commande GNU mkdir (tel que celle d'un système Linux), vous pouvez créer l'arborescence de répertoire comme cela :

# mkdir -p /chroot/named
# cd /chroot/named
# mkdir -p dev etc/namedb/slave var/run

2.3. Mise en place des données de BIND

Si vous avez déjà fait une installation conventionnelle de BIND et si vous l'utilisez, votre fichier named.conf et vos fichiers de zone existent déjà. Ces fichiers doivent être déplacés (ou copiés pour plus de sûreté) dans l'environnement restreint, de sorte que BIND puisse les atteindre. named.conf ira dans /chroot/named/etc, et les fichiers de zone pourront aller dans /chroot/named/etc/namedb. Par exemple :

# cp -p /etc/named.conf /chroot/named/etc/

# cp -a /var/named/* /chroot/named/etc/namedb/

BIND aura normalement besoin d'écrire dans le répertoire namedb, mais dans l'intérêt du resserrage de sécurité, nous ne lui permettrons pas de faire cela. Si votre serveur de nom est esclave pour n'importe quelles zones, il aura besoin de mettre à jour ces fichiers de zones, ce qui veut dire nous devrons les enregistrer dans un répertoire séparé, dans lequel BIND devra avoir accès.

# chown -R named:named /chroot/named/etc/namedb/slave

Gardez à l'esprit que si vous déplacez n'importe quelles zones que vous avez dans ce répertoire vous devez mettre à jour votre named.conf en conséquence. BIND aura aussi besoin d'écrire dans le répertoire /var/run, pour y mettre ses fichiers pid et ses fichiers de statistiques, donc permettons-lui de le faire :

# chown named:named /chroot/named/var/run

2.4. Fichiers pour le support du système

Une fois que BIND s'exécute dans l'environnement restreint, il n'est pas du tout capable d'avoir accès aux fichiers en dehors de celui-ci. Cependant, il doit avoir accès à quelques fichiers clefs, mais pas autant que BIND 8 en a besoin. Un fichier dont BIND a besoin à l'intérieur de sa prison est le bon vieux /dev/null. Notez que la commande exactement nécessaire pour créer ce fichier spécial peut varier de système en système ; vérifiez votre script /dev/MAKEDEV pour en être sûr. Quelques systèmes peuvent également exiger /dev/zero, que nous pouvons créer pareillement. Il est mentionné que BIND 9.2.0 release candidates exigent maintenant /dev/random aussi. Pour la plupart des systèmes Linux, nous pouvons employer les commandes suivantes :

# mknod /chroot/named/dev/null c 1 3
# mknod /chroot/named/dev/random c 1 8
# chmod 666 /chroot/named/dev/{null,random}

Pour FreeBSD 4.3, c'est :

# mknod /chroot/named/dev/null c 2 2
# mknod /chroot/named/dev/random c 2 3
# chmod 666 /chroot/named/dev/{null,random}

Vous avez besoin d'un autre fichier dans le répertoire /etc à l'intérieur de l'environnement restreint. Vous devez copier /etc/localtime (parfois nommé /usr/lib/zoneinfo/localtime sur certains systèmes) de façon à ce que BIND journalise les évènements avec un horodatage correct. La commande suivante se chargera de ceci :

# cp /etc/localtime /chroot/named/etc/

2.5. Journalisation des évènements

BIND a beau être prisonnier de son environnement restreint, il ne peut pas graver son journal sur les murs de sa cellule :-) Normalement, BIND écrit les journaux grâce à syslogd, le démon de journalisation des évènements du système. Cependant, ce type de journalisation est effectué en envoyant les entrées d'évènements vers le socket spécial /dev/log. Puisqu'il est à l'extérieur de l'environnement restreint, BIND ne peut plus l'employer désormais. Heureusement, il existe quelques solutions pour contourner cela.

2.5.1. La solution idéale

La solution idéale de ce dilemme exige une version raisonnablement récente de syslogd qui prend en charge le paramètre -a introduit par OpenBSD. Reportez-vous aux pages de manuel de votre syslogd(8) pour voir si vous avez une telle version. Si c'est la cas, la seule chose que vous ayez à faire est d'ajouter le paramètre « -a /chroot/named/dev/log » à la ligne de commande lorsque vous lancez syslogd. Sur les systèmes qui utilisent un init SysV complet (ce qui inclut la plupart des distributions Linux), vous pouvez faire cela dans le fichier /etc/rc.d/init.d/syslog. Par exemple, sur mon système Linux Red Hat, j'ai changé la ligne

daemon syslogd -m 0

en

daemon syslogd -m 0 -a /chroot/named/dev/log

Intéressant, à partir de la Red Hat 7.2, Red Hat a apparemment rendu ce processus plus facile. Il y a maintenant un fichier appelé /etc/sysconfig/syslog dans lequel des paramètres supplémentaires pour syslogd peuvent être définis. Les systèmes Caldera OpenLinux utilisent un démon de lancement appelé ssd, qui lit la configuration dans /etc/sysconfig/daemons/syslog. Il vous suffit de modifier la ligne d'options pour que cela ressemble à ceci :

OPTIONS_SYSLOGD="-m 0 -a /chroot/named/dev/log"

De la même façon sur les systèmes SuSE, on m'a dit que le meilleur endroit pour ajouter ce paramètre est le fichier /etc/rc.config. Changer la ligne

SYSLOGD_paraMS=""

en

SYSLOGD_paraMS="-a /chroot/named/dev/log"

devrait faire l'affaire. Et, le dernier mais non le moindre, pour FreeBSD 4.3 vous avez apparemment juste à éditer le fichier rc.conf et d'y indiquer la suite :

syslogd_flags="-s -l /chroot/named/dev/log"

Le -s est pour des raisons de sécurité, et fait partie des paramètre par defaut. Le -l est un chemin local dans lequel on peu mettre un autre endroit pour la journalisation des évènements. Une fois que vous avez compris comment faire cette modification sur votre système, il vous suffit de redémarrer syslogd, que cela soit en l'arrêtant et en le relançant (avec les paramètres supplémentaires), ou en employant le script d'init SysV qui le fera pour vous :

# /etc/rc.d/init.d/syslog stop
# /etc/rc.d/init.d/syslog start

Une fois redémarré, vous devez voir dans /chroot/named/dev un « fichier » appelé log qui ressemble à ceci :

srw-rw-rw-   1 root     root            0 Mar 13 20:58 log

2.5.2. L'autre solution

Si vous avez un ancien syslogd, alors vous devez trouver une autre façon de faire vos journalisations. Il existe quelques programmes pour faire ça, comme holelogd, qui est conçu pour agir comme un mandataire en acceptant les entrées d'évènements du BIND en environnement restreint pour les passer au véritable socket /dev/log. Vous pouvez aussi tout simplement configurer BIND pour journaliser les évènements dans un fichier au lieu de les passer à syslog. Voyez la documentation de BIND pour plus de détails si vous choisissez d'utiliser cette méthode.

2.6. Restreindre les permissions

La première des choses, se sentir libre de restreindre l'accès à la totalité du répertoire /chroot à l'utilisateur root. Bien sur, tout le monde ne voudra pas faire cela, spécialement si vous avez d'autres logiciels installés dans cette arborescence qui n'apprécieront pas cela.

# chown root /chroot
# chmod 700 /chroot

Vous pouvez aussi sans danger restreindre l'accès de /chroot/named à l'utilisateur named.

# chown named:named /chroot/named
# chmod 700 /chroot/named

Pour un peu plus de restriction, sur les systèmes Linux nous pouvons rendre quelques fichiers et répertoires immuables, en utilisant l'utilitaire chattr sur les systèmes de fichier ext2.

# cd /chroot/named
# chattr +i etc etc/localtime var

De la même manière, sur FreeBSD 4.3, vous pouvez regarder chflags si vous souhaitez rendre certaines choses immuables. Comme exemple, ce qui suit peut changer n'importe quoi dans le répertoire /chroot/named/etc en immuable :

# chflags schg /chroot/named/etc/*(*).

Cela serait bien de faire cela pour le répertoire dev aussi, mais malheureusement cela empêche syslogd de créer son socket dev/log. Vous pouvez aussi choisir de mettre le bit immuable sur d'autres fichiers dans la prison, tel que vos fichiers de zone primaire, si il n'y pas de raison qu'ils changent.

3. Compiler et installer votre beau BIND tout neuf

3.1. Compiler

Compiler BIND 9 pour l'utiliser dans une prison d'environnement restreint est une expérience plus plaisante que ce l'était avec BIND 8. En fait, vous n'avez rien de spécial à faire ; le standard ./configure && make suffira. Gardez à l'esprit que si vous voulez activer le support d'IPv6 dans un BIND (--enable-ipv6) sur des systèmes Linux, vous devez vérifier les versions du noyau et de la glibc. Si vous avec un noyau 2.2, vous avez besoin de la glibc 2.1, et si vous avez un noyau 2.4, vous avez besoin de la glibc 2.2. BIND est un peu regardant à propos de cela.

4. Installer votre beau BIND tout neuf

Je dois signaler que si vous avez une installation existante de BIND, par exemple en provenance d'un RPM, vous devrez probablement la désinstaller avant d'installer la nouvelle. Sur un système Red Hat, cela implique probablement de désinstaller les paquets bind et bind-utils, et peut-être bind-devel et caching-nameserver, si vous les avez. Vous voudrez sans doute sauvegarder une copie du script d'init (par exemple /etc/rc.d/init.d/named), s'il y a en un, avant de faire ceci ; ce sera utile plus tard. Si vous mettez à jour depuis une ancienne version de BIND, tel que BIND 8, vous devriez lire le document de migration dans le fichier doc/misc/migration dans le paquet source de BIND. Je n'ai traité aucune solution de migration dans ce document ; J'ai simplement assumé que vous remplacez une existante, fonctionnelle installation de BIND 9.

4.1. Installer les binaires

C'est la partie facile :-). Lancez juste make install et laissez le tout faire pour vous. Vraiment, c'est ce qui se passe.

4.2. Mise en place du script d'init

Si vous avez un script d'init provenant de votre distribution, le mieux serait probablement de simplement le modifier pour exécuter le nouveau binaire, avec les paramètres appropriés. Les paramètres sont… (roulement de tambour s'il vous plaît…)

  • -u named, pour exécuter BIND avec l'utilisateur named , plutôt que root.

  • -t /chroot/named, pour que BIND s'exécute dans l'environnement restreint que nous avons mis en place.

  • -c /etc/named.conf, pour que BIND trouve sa configuration à l'intérieur de la prison.

Ce qui suit est le script d'init que j'utilise avec mon système Red Hat 6.0. Comme vous pouvez voir, il est presque identique à celui livré par Red Hat. Je n'ai pas cependant essayé la commande rndc, mais je ne vois pas pour qu'elle raison elle ne fonctionnerait pas.

#!/bin/sh
#
# named           Le rôle de ce script "shell" est de démarrer et d'arrêter
#                 named (serveur DNS BIND).
#
# chkconfig: 345 55 45
# description: named (BIND) est le serveur de nom de domain (DNS) \
# qui est utilisé pour résoudre les noms de domaines en adresses IP.
# probe: true

# Bibliothèque basique de fonctions.
. /etc/rc.d/init.d/functions

# Configuration basique du réseau.
. /etc/sysconfig/network

# Vérifie que la gestion du réseau est assurée
[ ${NETWORKING} = "no" ] && exit 0

[ -f /usr/local/sbin/named ] || exit 0

[ -f /chroot/named/etc/named.conf ] || exit 0

# En fonction de ce qui est appelé.
case "$1" in
  start)
	# Démarrer le démon.
        echo -n "Démarrage de named : "
        daemon /usr/local/sbin/named -u named -t /chroot/named -c /etc/named.conf
        echo
        touch /var/lock/subsys/named
        ;;
  stop)
        # Arrêter le démon.
        echo -n "Arrêt de named : "
        killproc named
        rm -f /var/lock/subsys/named
        echo
        ;;
  status)
        status named
        exit $?
        ;;
  restart)
        $0 stop
        $0 start
        exit $?
        ;;
  reload)
        /usr/local/sbin/rndc reload
        exit $?
        ;;
  probe)
        # named sait comment redémarrer intelligemment ; nous ne voulons pas
        # que linuxconf nous propose de le redémarrer à chaque fois
        /usr/local/sbin/rndc reload >/dev/null 2>&1 || echo start
        exit 0
        ;;

  *)
        echo "Utilisation: named {start|stop|status|restart|reload}"
        exit 1
esac

exit 0

Comme pour syslogd, sous Red Hat 7.2 ce processus est maintenant plus facile. Il y a un fichier nommé /etc/sysconfig/named dans lequel les paramètres supplémentaires pour syslogd peuvent être définis. La version par défaut de /etc/rc.d/init.d/named dans une Red Hat 7.2, cependant, vérifie l'existence de /etc/named.conf avant de démarrer. Nous devons corriger ce chemin. Sur les systèmes Caldera OpenLinux, vous avez juste besoin de modifier les variables définies au début et il va s'occuper du reste pour vous :

NAME=named
DAEMON=/chroot/named/bin/$NAME
OPTIONS="-t /chroot/named -u named -g named"

Et pour FreeBSD 4.3,vous pouvez éditer le fichier rc.conf et modifier la suite :

named_enable="YES"
named_program="chroot/named/bin/named"
named_flags="-u named -t /chroot/named -c /etc/namedb/named.conf"

4.3. Changement de configuration

Vous devez aussi ajouter ou modifier quelques options dans votre named.conf pour avoir vos divers répertoires en ordre. En particulier, vous devez ajouter (ou changer, si vous les avez déjà) les directives suivantes dans la section options :

directory "/etc/namedb";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";

Au moment ou ce fichier est lu par le démon named, tout les chemins sont relatifs à l'environnement restreint. Au moment de la rédaction de ce document, BIND 9 ne supporte pas la totalité des fichiers de statistiques et de dépôts comme le pouvez la précédente version. Présumons que les prochaines le pourrons ; si vous exécuter de telle configuration, vous devez ajouter des entrées additionnelles pour forcer BIND à les écrire dans le répertoire /var/run.

5. La fin

5.1. Lancement de BIND

Tout devrait être configuré, et vous devriez être prêt à lancer votre nouveau BIND plus sécurisé. Si vous utilisez un script d'init du style SysV, vous pouvez simplement le lancer par :

# /etc/rc.d/init.d/named start

Assurez-vous d'avoir arrêté toutes les anciennes versions de BIND qui pourraient encore fonctionner avant de faire cela.

5.2. Voilà !

Vous pouvez aller faire un petit somme maintenant ;-).

A.  Annexes

1. Mises à jour ultérieures de BIND

Ainsi, vous avez un BIND 9.1.2 tout joliment placé dans son environnement restreint et assez peaufiné à votre goût... et vous entendez parler de cette rumeur que BIND 9.1.3 est finalement sortie, et vous avez juste une moment pour l'essayer. Devrez-vous repasser entièrement par ce long processus pour installer cette nouvelle version ?

Pas du tout. En fait, vous avez juste besoin de compiler le nouveau BIND et l'installer par dessus l'ancien. N'oubliez pas d'arrêter l'ancienne version et de redémarrer BIND ou c'est l'ancienne version qui continuera à tourner !

2. Remerciements

Je voudrais remercier les gens suivants pour leur aide dans la création de ce guide pratique :

Et le dernier mais certainement pas le moindre, je voudrais remercier Nakano Takeo pour avoir traduit en japonais ce guide pratique de BIND en environnement restreint. Vous pouvez trouver sa traduction à l'adresse http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html.

3. Politique de distribution de ce document

Copyright © Scott Wunsch, 2000-2001. Ce document peut être distribué seulement en conformité aux termes de la licence LDP tels que définis à l'adresse http://metalab.unc.edu/LDP/COPYRIGHT.html.

Ce guide pratique est une documentation libre ; vous pouvez le redistribuer ou le modifier conformément à la licence de LDP. Il est distribué dans l'espoir qu'il sera utile, mais sans aucune garantie ; sans même les garanties de commercialisation ou d'adaptation dans un but spécifique. Voir la licence de LDP pour plus de détails.