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:Serveur de noms:/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
       +-- bin
       +-- dev
       +-- etc
       |    +-- namedb
       +-- lib
       +-- 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 devra sûrement écrire dans le répertoire namedb, et probablement dans certains des fichiers contenus dans ce répertoire. Par exemple, si votre serveur DNS est esclave pour une zone, il devra y mettre à jour les fichiers de cette zone. De plus, BIND peut générer des statistiques, ce qu'il fait dans ce répertoire. Pour cette raison, vous devrez probablement faire de l'utilisateur named le propriétaire de ce répertoire et de son contenu :

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

BIND aura aussi besoin d'écrire dans le répertoire /var/run, pour y mettre ses fichiers pid et son socket ndc, 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 capable du tout d'avoir accès aux fichiers en dehors de celui-ci. Cependant, il doit avoir accès à quelques fichiers clefs, comme la bibliothèque C du système. Les bibliothèques exigées dépendront de votre saveur d'Unix. Pour la plupart des systèmes Linux modernes, les commandes suivantes seront suffisantes pour mettre en place les bibliothèques nécessaires :

# cd /chroot/named/lib
# cp -p /lib/libc-2.*.so .
# ln -s libc-2.*.so libc.so.6
# cp -p /lib/ld-2.*.so .
# ln -s ld-2.*.so ld-linux.so.2

Vous pouvez aussi simplement compiler des versions statiquement liées des binaires de BIND pour les placer dans votre environnement restreint. Vous devez aussi copier ldconfig dans l'environnement restreint et l'exécuter pour créer un etc/ld.so.cache pour l'environnement restreint. Les commandes suivantes devraient le permettre :

# cp /sbin/ldconfig /chroot/named/bin/
# chroot /chroot/named /bin/ldconfig -v

BIND a encore besoin d'un fichier système dans son environnement restreint : le bon vieux /dev/null. De nouveau, la commande exacte nécessaire pour créer ce fichier spécial peut varier de système en système ; vérifiez votre script /dev/MAKEDEV pour être sûr. Quelques systèmes peuvent également exiger /dev/zero. Pour la plupart des systèmes Linux, nous pouvons employer la commande suivante :

# mknod /chroot/named/dev/null c 1 3

Pour terminer, vous avez besoin de quelques fichiers supplémentaires dans le répertoire /etc à l'intérieur de l'environnement restreint. En particulier, vous devez copier /etc/localtime (parfois nommé /usr/lib/zoneinfo/localtime sur certains systèmes) de façon à ce que BIND enregistre les évènements avec un horodatage correct. Vous devez également créer un petit fichier group contenant uniquement le groupe named. Les deux commandes suivantes se chargeront de ceci :

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

# echo 'named:x:200:' > /chroot/named/etc/group

Gardez à l'esprit que le GID, 200 dans cet exemple, doit correspondre à celui que vous avez défini dans le vrai /etc/group défini au dessus.

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 deux 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

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, je me suis 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. 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 « proxy » 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.