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