staging.inyokaproject.org

Warum die ganzen Anpassungen der Configfiles? Man kann doch einfach die gleiche Ordnerstruktur im Jail erzeugen. Ist weniger Aufwand, vorallem wenn man mehr als nur ein Zonefile hat. Außerdem fehlen die notwendigen Änderungen im Apparmor-Configfile(zumindest bei 8.04). Ohne die läuft das so nicht! Auch muß ein Log-Socket innerhalb des Jails erstellt werden, weil sonst keine Meldungen mehr ins Syslog geschrieben werden können.

Hiermal meine Quick&Dirty Mitschrift. Vielleicht kann das mal jemand in eine brauchbare Form bringen und den Artikel entsprechend ändern.

Chroot-Umgebung bauen:

Verzeichnisstruktur erstellen: mkdir -p /var/chroot/named/{var/{cache/bind/backup,log/named,run/bind/run},etc,dev}

Alle Konfigurationsdateien in die neue Umgebung kopieren: cp -R /etc/bind /var/chroot/named/etc

Null- und Random-Devive anlegen: mknod /var/chroot/named/dev/null c 1 3 und mknod /var/chroot/named/dev/random c 1 8

Rechte für Ordner anpassen: find /var/chroot/named -type d -exec chmod 775 {} \;

Gruppe ändern: chgrp -R bind /var/chroot/named

Zur Kontrolle: ls -l /var/chroot/named/ :

drwxrwxr-x 2 root bind 4096 2009-03-23 16:37 dev
drwxrwxr-x 3 root bind 4096 2009-03-23 15:51 etc
drwxrwxr-x 5 root bind 4096 2009-03-23 16:16 var

Damit Bind weiterhin seine Messages an Syslog schicken kann, brauchen wir noch einen Log-Socket im Jail. Dazu die /etc/default/syslogd ändern:

SYSLOGD="" zu 
SYSLOGD="-a /chroot/named/dev/log"

Syslog neu starten: invoke-rc.d sysklogd restart

Ein ls -l /var/chroot/named/dev/ sollte ergeben:

srw-rw-rw- 1 root root    0 2009-03-23 16:37 log
crw-rw-r-- 1 root bind 1, 3 2009-03-23 15:42 null
crw-rw-r-- 1 root bind 1, 8 2009-03-23 15:42 random

Auf Ubuntu-8.04 läuft Apparmor und kontrolliert Zugriffe von Programmen auf Dateien. Deswegen wird auch dieses Konfigurationsfile geändert. Die Pfade auf alle Verzeichnisse in denen Bind liest oder schreibt müßen auf das Jail angepasst werden.

vi /etc/apparmor.d/usr.sbin.named

/usr/sbin/named {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_bind_service,
  capability setgid,
  capability setuid,
  capability sys_chroot,

  # /etc/bind should be read-only for bind
  # /var/lib/bind is for dynamically updated zone (and journal) files.
  # /var/cache/bind is for slave/stub data, since we're not the origin of it.
  # See /usr/share/doc/bind9/README.Debian.gz
  /var/chroot/named/etc/bind/** r,
  /var/chroot/named/var/lib/bind/** rw,
  /var/chroot/named/var/lib/bind/ rw,
  /var/chroot/named/var/cache/bind/** rw,
  /var/chroot/named/var/cache/bind/ rw,

  # some people like to put logs in /var/log/named/
  /var/chroot/named/var/log/named/** rw,

  # dnscvsutil package
  /var/lib/dnscvsutil/compiled/** rw,

  /proc/net/if_inet6 r,
  /usr/sbin/named mr,
  /var/chroot/named/var/run/bind/run/named.pid w,
  # support for resolvconf
  /var/chroot/named/var/run/bind/named.options r,
}

Neustart: invoke-rc.d apparmor restart

Jetzt noch /etc/default/bind9 wiefolgt ändern:

OPTIONS="-u bind " zu
OPTIONS="-u bind -t /var/chroot/named"

Bind neu starten: invoke-rc.d bind9 restart

Ein Problem bleibt noch. Die Logs haben nicht den richtigen Zeitstempel, bzw. den UTC. Ein kopieren von /etc/localtime und /etc/timzone brachte auch nicht die gewünschte Änderung. Hat hier jemand eventuell eine Lösung?

Apparmor war das Problem. Deswegen konnten die Files nicht gelesen werden.

Einfach noch folgendes in usr.sbin.named hinzufügen:

/var/chroot/named/etc/** r,
 /var/chroot/named/etc r,

Und cp /etc/timezone /var/chroot/named/etc/ .

Biketrialer schrieb:

Warum die ganzen Anpassungen der Configfiles? Man kann doch einfach die gleiche Ordnerstruktur im Jail erzeugen. Ist weniger Aufwand, vorallem wenn man mehr als nur ein Zonefile hat.

Das ist wohl eine Sache der persönlichen Präferenz. (Disclaimer: Den Artikel hab ich seinerzeit geschrieben. 😉 ) Man erkauft sich diese einmalige Zeitersparnis damit, dass man später mit irgendwelchen Einzeldateien in tief verschachtelten Verzeichnissen arbeiten muss. Und mit einem Editor der globales Suchen/Ersetzen kann, (oder gleich mit sed,) ist es vom Aufwand her auch ziemlich egal, wieviele Zonenfiles man besitzt. Die offizielle Bind-Doku schreibt dazu: https://www.isc.org/software/bind/documentation/arm95#id2596569

Außerdem fehlen die notwendigen Änderungen im Apparmor-Configfile(zumindest bei 8.04). Ohne die läuft das so nicht!

Stimmt. Ich hab den Artikel zu Dapper-Zeiten geschrieben. Das wäre also eine wertvolle Ergänzung.

Auch muß ein Log-Socket innerhalb des Jails erstellt werden, weil sonst keine Meldungen mehr ins Syslog geschrieben werden können.

Ebenfalls sinnvoll. Was die anderen Devices angeht: Anscheinend kann Bind auch das normale /dev/random von außerhalb des chroots benutzen, weil es wohl schon vor dem chroot-Aufruf geöffnet wird. Wofür wird /dev/null denn überhaupt gebraucht?

Das ist wohl eine Sache der persönlichen Präferenz. (Disclaimer: Den Artikel hab ich seinerzeit geschrieben. ) Man erkauft sich diese einmalige Zeitersparnis damit, dass man später mit irgendwelchen Einzeldateien in tief verschachtelten Verzeichnissen arbeiten muss. Und mit einem Editor der globales Suchen/Ersetzen kann, (oder gleich mit sed,) ist es vom Aufwand her auch ziemlich egal, wieviele Zonenfiles man besitzt.

Hmmm, da hast du natürlich auch recht. Ich finde es so aber schon einfacher(im Sinne von KISS). Zumal ich glaube, daß nicht allen Usern sed so klar ist.

Die offizielle Bind-Doku schreibt dazu:

Wie meinst du das? Da steht doch nichts über die zu verwendende Ordnerstruktur...oder stehe ich gerade aufm Schlauch?

Was die anderen Devices angeht: Anscheinend kann Bind auch das normale /dev/random von außerhalb des chroots benutzen, weil es wohl schon vor dem chroot-Aufruf geöffnet wird. Wofür wird /dev/null denn überhaupt gebraucht?

Laut dem von dir verlinkten Dokument von dem ISC, sollen diese Devices ja vorhanden sein. Ich habe es nicht ohne probiert, aber du hast ja auch eine Fehlermeldung erhalten, die das Fehlen dieser Devices bemängelte....

Pflegst du die Änderungen ein oder wollen wir uns noch etwas einigen? Bin gerne bereit noch zu helfen. Das usr.sbin.named ist so auch noch nicht ganz richtig. Werde es die Tage nochmal genauer ausprobieren.

Biketrialer schrieb:

Hmmm, da hast du natürlich auch recht. Ich finde es so aber schon einfacher(im Sinne von KISS). Zumal ich glaube, daß nicht allen Usern sed so klar ist.

Ich finde, Verzeichnisnamen wie /var/chroot/named/var/run/bind/run haben mit dem KISS-Prinzip nicht viel zu tun. 😉 Und von sed steht in dem Artikel ja auch nichts drin. Wer mit sed nicht vertraut ist, kann ja das Global Replace von seinem Lieblingseditor benutzen, und wer das nicht kennt, macht eben alles von Hand und braucht noch ein bisschen länger. Das sehe ich nicht als tragisch an. Deswegen bin ich für Beibehaltung der jetzigen Ordnerstruktur.

Die offizielle Bind-Doku schreibt dazu:

Wie meinst du das? Da steht doch nichts über die zu verwendende Ordnerstruktur...oder stehe ich gerade aufm Schlauch?

Direkt vorschreiben tun sie da nichts. Aber die Anweisung, dass man Optionen wie directory oder pid-file ändern müsste, deutet darauf hin, dass nicht an eine komplette Spiegelung des Verzeichnisbaums gedacht wird.

Was die anderen Devices angeht: Anscheinend kann Bind auch das normale /dev/random von außerhalb des chroots benutzen, weil es wohl schon vor dem chroot-Aufruf geöffnet wird. Wofür wird /dev/null denn überhaupt gebraucht?

Laut dem von dir verlinkten Dokument von dem ISC, sollen diese Devices ja vorhanden sein. Ich habe es nicht ohne probiert, aber du hast ja auch eine Fehlermeldung erhalten, die das Fehlen dieser Devices bemängelte....

Von /dev/null steht da nichts. /dev/zero ist was anderes. Außerdem steht da "depending on your operating system, you may need to set up ..." Die Warnung, die ich erhalten habe, sagt ja eindeutig aus, dass er das /dev/random außerhalb des Chroots benutzt, nicht etwa dass er nun ohne läuft und damit die Kryptofunktionen unsicherer sind. Es mag sein, dass es Betriebssysteme gibt, wo diese Vorgehensweise - erst das Device öffnen, dann chrooten, und dann den geöffneten Filehandle außerhalb des chroots weiter nutzen - nicht funktioniert.

Pflegst du die Änderungen ein oder wollen wir uns noch etwas einigen? Bin gerne bereit noch zu helfen. Das usr.sbin.named ist so auch noch nicht ganz richtig. Werde es die Tage nochmal genauer ausprobieren.

Zu dem AppArmor-Kram kann ich z.Zt. nichts sagen, da mein Server zu Hause noch unter Dapper läuft. Außerdem hab ich da gar kein chroot aktiviert. Ich hatte das nur mal auf 'nem Testserver um den Artikel zu schreiben. Insofern sollten wir uns darauf einigen, was wir denn nun ändern, und dann kannst du das auch gerne umsetzen und ich schau danach nochmal drüber, damit das auch von der Form her passt.

Derzeit ungetestet. Wenn sich niemand findet, der das uebernimmt - archivieren.

Artikel archiviert.

Ich würde gerne aus diesem Artikel Teile übernehmen und daher an den Code kommen. Ich bitte auch hier um eine Baustelle.

bitteschön: Baustelle/DNS-Server Bind/Erweiterte Konfiguration

Fürs Protokoll: Ich habe mich für eine Baustelle entschieden, obwohl dieser Artikel laut 8985581 nicht direkt bearbeitet werden soll. Aber so haben wir zumindest die Baustellen-Warnbox in DNS-Server Bind/Erweiterte Konfiguration .

@DJKUhpisse bitte gib Bescheid wenn du hier fertig bist und verweise zur Baustellen-Auflösung auf diesen Post. Danke.

Da DNS-Server Bind fertig ist, wird die Baustelle hier auch wieder aufgelöst, siehe 8985608.