Torrentflux, OpenBSD e Apache in Jail (chroot)

A pensarci bene, ci sono alcuni servizi di rete che sono da ritenersi “indispensabili”. Per servizi di questa tipologia è necessario poter disporre della massima sicurezza possibile.

A mio parere, sotto questo punto di vista, OpenBSD è sicuramente il sistema operativo adatto per eccellenza.

Ma qual’è, secondo voi, il servizio che più in assoluto è da ritenere critico?

Ovviamente il servizio di “download torrent” :)

Per un servizio come questo quindi è assolutamente d’obbligo utilizzare OpenBSD.

Basta scherzare, facciamo le persone serie.

Per chi non conoscesse torrentflux
Torrentflux è un frontend web per BitTornado scritto in php e come tutti i frontend che eseguono script per la scrittura di files su disco, sono spesso soggetti a pesanti vulnerabilità.

Perchè OpenBSD
Una caratteristica di questo SO è che Apache, il demone http, viene originariamente installato in una gabbia (jail) mediante la nota tecnica di chrooting, cioè di cambio della directory principale.

Questa tecnica di installazione non mira a rendere il server web più sicuro ma solamente a limitare i danni qualora ci fossero delle falle, questo perchè il servizio non è in grado di “vedere” l’intero disco ma solo una piccola parte.

Nello specifico, in OpenBSD, il servizio httpd è installato nella directory “/var/www“. Questa directory, grazie al chrooting diviene per il servizio la directory principale “/”. Poichè non è possibile risalire oltre la root di un filesystem ne consegue che il server web non è in grado di accedere ai file contenuti ad esempio in “/var”.

Installare torrentflux con queste restrizioni non è semplice perchè la gabbia inibisce l’uso di alcuni componenti essenziali come ad esempio python, necessario per eseguire il client BitTornado.

Navigando su Internet ho notato che non ci sono guide che spiegano come rendere possibile l’esecuzione di torrentflux all’interno della gabbia, così ho deciso di scrivere questo breve articolo.

Da Torrentflux a Torrentflux-b4rt
Una versione più avanzata di questo frontend si chiama torrentflux-b4rt. Questa guida può essere applicata tranquillamente a questa versione.

Cosa c’è da fare
La prima cosa che voglio mettere in chiaro è che è necessario dare ad Apache la possibilità di eseguire la shell. Questa è una cosa orrenda dal punto di vista della sicurezza ma non sono riuscito a trovare altre alternative. La spiegazione risiede nel fatto che torrentflux fa uso della funzione execute() di php per la quale pare che la shell sia indispensabile.

Detto questo, tutto quello che dobbiamo fare è rendere disponilibi i file necessari a torrentflux per poter eseguire correttamente il frontend.

Dando uno sguardo alla documentazione rilasciata insieme al software ed al codice sorgente, sono giunto alla conclusione che sono necessari i seguenti eseguibili:

sh;
awk;
du;
grep;
nice;
tar;
zip;
nohup;
python;
php (cli);

Per poter utilizzare questi eseguibili all’interno della gabbia però non è sufficiente copiarli nella cartella /var/www ma è necessario creare alcune directory e copiare alcune librerie.

Procediamo dunque con la creazione delle directory necessarie:

mkdir -p /var/www/bin
mkdir -p /var/www/usr/bin
mkdir -p /var/www/usr/lib
mkdir -p /var/www/usr/local/bin
mkdir -p /var/www/usr/local/lib
mkdir -p /var/www/usr/libexec
mkdir -p /var/www/etc
mkdir -p /var/www/tmp
chmod 777 /var/www/tmp

Le cartelle create possono tranquillamente appartenere al gruppo daemon con utente root, l’importante è che siano accessibili all’utente www (Apache).

A questo punto iniziamo a copiare i files necessari:

cp /bin/sh /var/www/bin/sh
cp /usr/bin/awk /var/www/bin/awk
cp /usr/bin/du /var/www/bin/du
cp /usr/bin/grep /var/www/bin/grep
cp /usr/bin/nice /var/www/bin/nice
cp /usr/bin/tar /var/www/bin/tar
cp /usr/bin/nohup /var/www/bin/nohup

Per capire se ci sono delle dipendenze per gli eseguibili che abbiamo appena copiato è possibile utilizzare il comando ldd aggiungendo come parametro l’eseguibile da verificare. Nel nostro caso grep ha bisogno di portare con se alcune librerie:

ldd /usr/bin/grep

/usr/bin/grep:
Start End Type Open Ref GrpRef Name
00000000 00000000 exe 1 0 0 /usr/bin/grep
073e9000 273f1000 rlib 0 1 0 /usr/lib/libz.so.4.1
0530f000 25343000 rlib 0 1 0 /usr/lib/libc.so.43.0
0da9b000 0da9b000 rtld 0 1 0 /usr/libexec/ld.so

Le librerie potrebbero avere nomi leggermente diversi, questo perchè le prove fatte per la scrittura di questo articolo prevedono l’uso di OpenBSD ver 4.3.
Dopo aver fatto questa verifica possiamo copiare le libreire nelle apposite locazioni:

cp /usr/bin/grep /var/www/usr/bin/grep
cp /usr/lib/libz.so.4.1 /var/www/usr/lib/libz.so.4.1
cp /usr/lib/libc.so.43.0 /var/www/usr/lib/libc.so.43.0
cp /usr/libexec/ld.so /var/www/usr/libexec/ld.so

Proseguiamo con la copia degli altri eseguibili necessari e delle relative librerie (ormai sapete come si fa):

cp /usr/local/bin/idle2.5 /var/www/usr/local/bin/idle2.5
cp /usr/local/bin/php /var/www/usr/local/bin/php
cp /usr/local/bin/zip /var/www/usr/local/bin/zip
cp /usr/local/bin/pydoc2.5 /var/www/usr/local/bin/pydoc2.5
cp /usr/local/bin/python2.5 /var/www/usr/local/bin/python2.5

Adesso creiamo un link simbolico all’eseguibile python2.5 tenendo a mente che il link dovrà essere dinamico altrimenti non funzionerà all’interno della nostra gabbia:

cd /var/www/usr/local/bin
ln -s python2.5 python

Un discorso ancora diverso deve essere fatto per le librerie di python. Usare semplicemente la tecnica descritta in precedenza non è sufficiente. Facendo una ricerca su Internet ho trovato un ineressante articolo che mi ha dato una mano in questo senso. Quando capitano problemi di questo tipo il mio consiglio è quello di verificare la gabbia per vedere se tutto funziona correttamente:

# chroot -u www /var/www /bin/sh
/bin/sh: No controlling tty (open /dev/tty: No such file or directory)
/bin/sh: warning: won’t have full job control

Tralasciate pure l’errore dovuto alla mancanza della cartella /dev.
Comunque sia, dopo alcuni tentativi che vi risparmio sono riuscito ad individuare le libreirie necessarie per l’esecuzione di python:

cp /usr/local/lib/libiconv.so.4.0 /var/www/usr/local/lib/libiconv.so.4.0
cp /usr/local/lib/libintl.so.4.0 /var/www/usr/local/lib/libintl.so.4.0
cp /usr/local/lib/libpython2.5.so.0.0 /var/www/usr/local/lib/libpython2.5.so.0.0
cp /usr/local/lib/libxml2.so.9.7 /var/www/usr/local/lib/libxml2.so.9.7
cp /usr/local/lib/python2.5 /var/www/usr/local/lib/python2.5
cp /usr/lib/libcrypto.so.13.0 /var/www/usr/lib/libcrypto.so.13.0
cp /usr/lib/libm.so.2.3 /var/www/usr/lib/libm.so.2.3
cp /usr/lib/libncurses.so.10.0 /var/www/usr/lib/libncurses.so.10.0
cp /usr/lib/libpanel.so.3.0 /var/www/usr/lib/libpanel.so.3.0
cp /usr/lib/libpthread.so.9.0 /var/www/usr/lib/libpthread.so.9.0
cp /usr/lib/libpython2.5.so.0.0 /var/www/usr/lib/libpython2.5.so.0.0
cp /usr/lib/libssl.so.11.0 /var/www/usr/lib/libssl.so.11.0
cp /usr/lib/libstdc++.so.44.0 /var/www/usr/lib/libstdc++.so.44.0
cp /usr/lib/libutil.so.11.0 /var/www/usr/lib/libutil.so.11.0

Spero di non aver dimenticato dipendenze ma in questo periodo non ho tanto tempo da dedicare al blog, se doveste trovare inesattezze provate a scrivere due righe, io provvederò a correggere il testo.

Rimane ancora una cosa da fare: copiare il file resolv.conf altrimenti BitTornado non sarà in grado di risolvere gli indirizzi IP:

cp /etc/resolv.conf /var/www/etc/resolv.conf

Prima di concludere volevo dire che nel presente documento non sono stati considerati tutti i comandi necessari a torrentflux, alcuni li ho volutamente lasciati fuori perchè li reputo pericolosi e di poca utilità (vedi ps usato per mostrare i processi in esecuzione sul server).

Per saperne di più
Chroot (wikipedia)
OpenBSD (FAQ)

Leave a comment

0 Comments.

Leave a Reply


[ Ctrl + Enter ]