» SelfLinux » Internet » Domain Name System » Abschnitt 27 SelfLinux-0.12.3
zurück Startseite Kapitelanfang Inhaltsverzeichnis PDF-Download (121 KB) GFDL weiter

SelfLinux-Logo
Dokument Domain Name System  Autor
 Formatierung
 GFDL
 

34 Chroot-Umgebung

Um es noch sicherer zu bekommen, kann man bind auch in einer chroot-Umgebung laufen lassen. Das macht allerdings etwas mehr Arbeit, denn alle von bind benötigten Dateien müssen dann unterhalb dieses chroot-Verzeichnisses liegen. Dazu sind dann einige Schritte notwendig. Vorallem muß bind als eigener User laufen, da chroot mit Root-Rechten nicht sinnvoll funktioniert.

Zunächst muß einen minimale Verzeichnisstruktur erzeugt werden, die bind verwenden kann. Sie kann z.B. unter /var/named.chroot erzeugt werden. Dazu folgendes Kommando (als root!):

root@linux # mkdir -p /var/named.chroot/etc
root@linux # mkdir -p /var/named.chroot/var/named
root@linux # mkdir -p /var/named.chroot/var/run
root@linux # mkdir -p /var/named.chroot/bin
root@linux # mkdir -p /var/named.chroot/usr/sbin
root@linux # mkdir -p /var/named.chroot/dev
root@linux # mkdir -p /var/named.chroot/lib

Nun müssen die Konfigurationsdatei und die Datenbanken kopiert werden:

root@linux # cp -p /etc/named.conf /var/named.chroot/etc/
root@linux # cp -pR /var/named /var/named.chroot/var

Nun sind die Rechte der Dateien zu korrigieren:

root@linux # chown -R root:root /var/named.chroot/
root@linux # chmod 755 /var/named.chroot
root@linux # chmod 755 /var/named.chroot/*
root@linux # chown -R named:named /var/named.chroot/var/named/
root@linux # chown -R named:named /var/named.chroot/var/run/
root@linux # chmod 644 /var/named.chroot/etc/*
root@linux # chmod 755 /var/named.chroot/lib/*
root@linux # chmod 755 /var/named.chroot/usr/sbin
root@linux # chmod 755 /var/named.chroot/usr/sbin/*

Normalerweise verwendet man dynamisch gelinkte Binärdateien, und so müssen die Bibliotheken kopiert werden. Zuerst muß man schauen, welche Libs benötigt werden:

root@linux # ldd `which named`

Eine Ausgabe könnte sein:

libc.so.6 => /lib/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Es kann bei anderen Unix-Derivaten sein, dass das Kommando ldd oder which nicht verfügbar ist. Dann muß ein anderer Weg gefunden werden.

Diese Dateien werden kopiert:

root@linux # cp -p /lib/libc.so.6 /var/named.chroot/lib/
root@linux # cp -p /lib/ld-linux.so.2 /var/named.chroot/lib/

Dann benötigt BIND die Gerätedatei /dev/null. Hat man ein modernes /bin/cp, so reicht ein:

root@linux # cp -a /dev/null /var/named.chroot/dev/

andernfalls muß man das Gerät neu anlegen:

root@linux # mknod /var/named.chroot/dev/null c 1 3

(Die konkreten Parameter können wiederum bei anderen Unix-Derivaten abweichen).

BIND benötigt die Datei /etc/localtime:

root@linux # cp /etc/localtime /var/named.chroot/etc/

und natürlich seine eigenen /etc/passwd-Einträge. Diese können z.B. mit folgenden Einzeilern erzeugt werden:

root@linux # cat /etc/passwd | grep 'named' > /var/named.chroot/etc/passwd
root@linux # cat /etc/group | grep 'named' > /var/named.chroot/etc/group

Wenn bind über syslogd(8) loggt, und nicht nur über eigene logfiles, muß hier noch weiter angepaßt werden. Normalerweise greift BIND auf /dev/log zu. Diese Datei ist nun aber nicht mehr erreichbar. syslogd muß also eine Datei zusätzlich verwenden, die erreichbar ist. Ein halbwegs moderes syslogd kennt dazu den Parameter "-a", der nun beim Start des Syslogdeamons angegeben werden muß. Dazu muß u.U. das Startscript angepaßt werden. Bei einer SuSE-Distribution kann man aber auch den Parameter SYSLOGD_PARAMS in /etc/rc.config verwenden:

/etc/rc.config
SYSLOGD_PARAMS="-a /var/named.chroot/dev/log"
  

Sonst muß der "-a"-Parameter an der entsprechenden Stelle im Startscript hinzugefügt werden. Danach ist syslogd neu zu starten. dabei sollte syslogd nun diese Datei erzeugt haben. Leider neigen scheinbar einige syslogd-Versionen dazu, hier Bugs zu besitzen, und nur noch diesen Socket auzuwerten oder dergleichen. Ein Update sollte dem abhelfen.

Soll bind nicht über syslogd loggen, sondern in Dateien schreiben, kann folgendes konfiguriert werden:

/etc/named.conf
logging {

        channel file_log {
                file "named.log";
                severity info;
        };

        channel file_debug {
                file "named.run";
                severity dynamic;
        };

        category default {
                file_log; file_debug;
        };
};
  

Nun müssen die Programme selbst kopiert werden, mindestens named und named-xfer (mit which named kann herrausgefunden werden, wo sich diese befinden). Dabei muß beachtet werden, dass der Pfad zu named-xfer "hardcoded" im Binärprogramm steht. Dieser Pfad muß dann um den chroot-Pfad erweitert werden, damit das Programm von bind gefunden wird. Liegen named und named-xfer z.B. in /usr/sbin (wie bei SuSE), so müssen sie nach /var/named.chroot/usr/sbin kopiert werden:

root@linux # cp /usr/sbin/named* /var/named.chroot/usr/sbin/

Man kann natürlich auch in ein anderes Verzeichnis kopieren, muß dann aber in der Konfigurationsdatei den Pfad entsprechend angeben, z.B.:

/etc/named.conf
options {
        ...
        named-xfer "/bin/named-xfer";
};
  

Dabei ist wieder zu beachten, dass die benötigten Libs geladen werden können. Der hier angegebene Pfad ist natürlich um das Chroot-Verzeichnis gekürzt anzugeben, da BIND dann von dieser nichts mehr sieht, also unter /bin etwas anderes versteht, als ein nicht ge-chrooteter Prozeß.

Der Startaufruf für BIND muß nun nur noch um den Parameter "-t" erweitert werden:

root@linux # /usr/sbin/named -u named -g named -t /var/named.chroot

Nun sollte überprüft werden, ob Anfragen noch richtig beantwortet werden, und ob ein Zonetransfer funktioniert.

Da (ein älteres) ndc das pid-File in /var/run erwartet, und nicht in /var/named.chroot/var/run, kann hier ein Symlink helfen, der vom Startscript nach dem Starten jeweils erzeugt wird:

root@linux # ln -s /var/named.chroot/var/run/named.pid /var/run/

Beim Beenden kann der Link dann einfach gelöscht werden:

root@linux # rm -f /var/run/named.pid

Es ist zu beachten, dass ndc restart und ndc start nicht mehr verwendet werden sollten, da hier die Parameter aus unserem Startscript nicht verwendet werden! Dann wird bind unter root-Rechten ohne chroot ausgeführt!
Modernere ndc-Versionen handhaben die Verbindung anders. Es wird ein control channel verwendet, defaultmäßig ist das /var/run/ndc. Das kann über Parameter geändert werden. Ein modernes ndc kann aber auch über Parameter dazu veranlaßt werden, ein pid-File zu verwenden. Diese Defaults können beim Compilieren allerdings geändert werden. Sonst lautet der Aufruf von ndc wie folgt:

root@linux # ndc -c /var/named.chroot/var/run/ndc

Es ist wohl eine gute Idee, hierauf einen Shell-"Alias" zu setzen, z.B. in ~/.profile:

~/.profile
alias ndc='ndc -c /var/named.chroot/var/run/ndc'
  

Es sollte mindestens ein reload probiert werden, um zu sehen, ob z.B. bind jetzt noch seine Konfigurationsdatei lesen kann. Beim ersten Start funktioniert das immer, da vor dem Setzen der chroot Umgebung noch root-Rechte vorhanden sind, was bei reload ja nicht mehr der Fall ist. Gegebenenfalls sind die Rechte zu kontrollieren. Hierbei gilt, bind darf ruhig viel (alles) lesen können, aber nur die Slave-Zones schreiben (also darf dem User nur wenig gehören - nur das Slave-Zonen-Verzeichnis).



zurück Seitenanfang Startseite Kapitelanfang Inhaltsverzeichnis PDF-Download (121 KB) GFDL weiter