2. Preparazione della gabbia

2.1 Creazione di un utente

Come detto nell'introduzione, è una pessima idea eseguire BIND con i privilegi di root. Quindi, prima di cominciare, creiamo un utente a parte per BIND. Non dovete mai usare a questo scopo un generico utente già presente, come nobody. Comunque, alcune distribuzioni come SuSE e Mandrake hanno iniziato a fornire un utente specifico per BIND (di solito chiamato named) che potete modificare invece di crearne uno da zero.

Per creare l'utente dovete aggiungere in /etc/passwd una riga come questa:

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

E per il gruppo un'altra come questa in /etc/group:

named:x:200:

Questo crea un utente e un gruppo per BIND chiamati named. Accertatevi che l'UID e il GID (nel nostro esempio entrambi 200) siano unici sul vostro sistema. La shell è impostata a /bin/false perché questo utente non avrà mai bisogno di fare il login.

2.2 Struttura delle directory

Ora dobbiamo impostare la struttura delle directory che useremo per la gabbia chroot in cui BIND verrà eseguito. Può essere ovunque nel vostro filesystem, i più paranoici potrebbero anche metterla in una partizione separata. In seguito assumeremo di usare /chroot/named. Iniziamo creando questo albero di directory:

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

Se usate l'utilità GNU mkdir (come sui sistemi Linux), potete crearlo con questi comandi:

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

2.3 Sistemare i dati di BIND

Supponendo che abbiate già installato BIND in modo convenzionale e che lo stiate già utilizzando, avrete già un file named.conf e i file di zona. Questi file devono essere spostati (o solo copiati, per sicurezza) nella gabbia chroot, in modo che BIND possa accedervi: named.conf va in /chroot/named/etc e i file di zona possono andare in /chroot/named/etc/namedb. Per esempio:

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

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

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

Ricordate che dovrete spostare tutti i file delle zone per cui fate da slave in questa directory ed aggiornare il vostro named.conf.

BIND avrà anche bisogno di scrivere i suoi pidfile e le informazioni sulle statistiche di uso nella directory /var/run, perciò permettiamogli di farlo:

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

2.4 File per il supporto al sistema

Una volta che BIND è nella sua gabbia chroot non potrà più accedere a nessun file fuori da essa. Però avrà bisogno di accedere ad alcuni file fondamentali, anche se non a tanti quanti ne servivano a BIND 8.

Uno dei file che gli serviranno nella sua gabbia è il buon vecchio /dev/null. Attenzione che il comando esatto per creare questo device node può variare da sistema a sistema; controllate il vostro script /dev/MAKEDEV per sicurezza. Alcuni sistemi potrebbero richiedere anche /dev/zero, che può essere creato in modo simile. Si dice che la release candidata BIND 9.2.0 richieda anche /dev/random. Per la maggior parte dei sistemi Linux potete usare i seguenti comandi:

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

Per FreeBSD 4.3 invece:

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

Vi servirà anche un altro file nella directory /etc all'interno della gabbia. Dovete copiare /etc/localtime (su alcuni sistemi noto come /usr/lib/zoneinfo/localtime) in modo che i log di BIND riportino l'ora esatta degli eventi registrati. Lo potete fare con il seguente comando:

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

2.5 Logging

A differenza di un normale avanzo di galera, BIND non può scrivere le sue registrazioni di log sui muri :-). In genere a questo scopo BIND usa syslogd, il demone dei log di sistema. Comunque questo tipo di logging è effettuato scrivendo le voci di registrazione nello speciale socket /dev/log, che però ora non può usare perché si trova fuori dalla sua gabbia. Per fortuna ci sono un paio di soluzioni a questo problema.

La soluzione ideale

Il modo ideale per risolvere il problema richiede una versione ragionevolmente recente di syslogd, che supporti lo switch -a introdotto da OpenBSD. Controllate la pagina di manuale syslogd(8) per sapere se la versione di syslogd che avete lo supporta o no.

Se sì, tutto quello che dovete fare è aggiungere lo switch "-a /chroot/named/dev/log" alla linea di comando che lancia syslogd. Sui sistemi che usano il SysV-init completo (ovvero la maggior parte delle distribuzioni Linux) tale riga si trova solitamente nel file /etc/rc.d/init.d/syslog. Per esempio, sul mio sistema Linux Red Hat ho cambiato la riga

daemon syslogd -m 0

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

È interessante notare come dalla Red Hat 7.2 questo processo sia anche più facile. Ora c'è un file /etc/sysconfig/syslog in cui definire parametri supplementari per syslogd.

I sistemi Caldera OpenLinux usano un esecutore di demoni, ssd, che legge la configurazione dal file /etc/sysconfig/daemons/syslog. In questo caso dovrete soltanto modificare la riga delle opzioni in questo modo:

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

In modo simile, mi è stato detto che sui sistemi SuSE il posto migliore per aggiungere questa opzione è il file /etc/rc.config. Cambiare la riga

SYSLOGD_PARAMS=""

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

E per ultimo ma non per importanza, con FreeBSD 4.3 sembra che dobbiate soltanto modificare il file rc.conf e scrivere:

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

Una volta capito come intervenire sul vostro syslogd e scritta la sua nuova configurazione riavviate syslogd, o con kill e riavviandolo (con i parametri supplementari), oppure usando gli script SysV-init che lo fanno per voi:

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

Appena ripartito syslogd, dovreste vedere un "file" in /chroot/named/dev di nome log, che dovrebbe apparire così:

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

Le altre soluzioni

Se avete un syslogd troppo vecchio dovrete trovare un altro sistema per scrivere i vostri log. Ci sono un paio di programmi in giro, come holelogd, che aiutano agendo come "proxy" ed accettando le voci di log dal BIND in chroot e passandole al vero socket /dev/log.

In alternativa potete configurare BIND per fargli scrivere i log su normali file invece di farli passare attraverso syslog. Leggete la documentazione di BIND per scoprire i dettagli su come farlo se scegliete questa strada.

2.6 Restrizione dei permessi

Prima di tutto sentitevi autorizzati a restringere l'accesso all'intera directory /chroot al solo utente root. Chiaramente non tutti potrebbero volerlo fare, soprattutto se avete altri software installati in quella directory che non apprezzano la cosa.

# chown root /chroot
# chmod 700 /chroot

Potete anche tranquillamente limitare l'accesso a /chroot/named all'utente named:

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

Per un accesso ancora più ristretto, sui sistemi Linux possiamo rendere alcuni file e directory immutabili, usando l'utilità chattr sui filesystem ext2:

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

In modo equivalente, su FreeBSD 4.3 potreste voler dare un'occhiata a chflags se volete rendere file e directory immutabili. Per esempio il comando che segue dovrebbe rendere immutabile tutto il contenuto della directory /chroot/named/etc:

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

Sarebbe una bella cosa farlo anche per la directory dev ma purtroppo questo impedirebbe a syslogd di creare il suo socket dev/log. Potete impostare il bit immutabile anche per altri file o directory della gabbia chroot, come i file di zona primaria, se sapete che non non cambieranno mai.