Nei precedenti articoli pubblicati nella serie “SSH in CHROOT: Una gabbia per la shell sicura” parte 1 e parte 2, veniva affrontato il tema della messa in sicurezza di SSH attraverso una Patch che obbligava determinati utenti a rimanere chiusi all’interno di una gabbia virtuale.
Dalla versione 5 di SSH però è possibile sfruttare un meccanismo nativo che implementa il CHROOT. Ecco spiegato come.

Capire la versione di SSH installata nel sistema

Prima di procedere con la configurazione del pacchetto è bene accertarsi che la versione di SSH installata nel sistema sia uguale o superiore alla 4.8p1, su sistemi Debian e derivati, l’interrogazione è possibile attraverso il seguente comando:

# dpkg -l openssh-*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Nome                                    Versione                                Descrizione
+++-=======================================-=======================================-==============================================================================================
ii  openssh-blacklist                       0.4.1                                   list of default blacklisted OpenSSH RSA and DSA keys
ii  openssh-blacklist-extra                 0.4.1                                   list of non-default blacklisted OpenSSH RSA and DSA keys
ii  openssh-client                          1:5.1p1-5                               secure shell client, an rlogin/rsh/rcp replacement
ii  openssh-server                          1:5.1p1-5                               secure shell server, an rshd replacement

Mentre in sistemi RedHat e derivati è sufficiente interrogare l’elenco pacchetti installati con rpm:

$ rpm -qa openssh*
openssh-4.3p2-16.el5
openssh-askpass-4.3p2-16.el5
openssh-clients-4.3p2-16.el5
openssh-server-4.3p2-16.el5

Nei casi riportati, sul sistema Debian (versione Lenny) la versione di SSH supporta nativamente il Chroot mentre il sistema RedHat (versione 5) no. In questo caso è necessario eseguire l’aggiornamento del pacchetto se ne si vorrà sfruttare la nuova funzionalità, ricompilando localmente la versione 5 partendo dai sorgenti disponibili presso il sito ufficiale del progetto OpenSSH oppure scaricando un rpm precompilato da repository pubblici come http://www.rpmfind.net.

Come funziona il CHROOT nativo

Il metodo con cui il demone SSH, previa configurazione, costruisce la gabbia per l’utente che effettua la login può essere diviso in due tipologie: l’accesso diretto via ssh e quello via sftp.
Nel primo caso la directory nella quale l’utente effettuerà il login dovrà contenere la struttura essenziale di file e directory necessaria alla navigazione all’interno del sistema, mentre attraverso il funzionamento sftp il demone non necessiterà di un ambiente nativo, ma sfruttando il comando interno sftp, fornirà l’interfaccia di accesso al sistema.

Predisposizione del sistema

I test che verranno effettuati nel corso dell’articolo partiranno dal presupposto che esista un gruppo denominato test e che tutte le utenze facenti parte di questo gruppo vengano ingabbiate.
Verrà quindi creato un utente denominato test con cui verranno effettuate le prove:

$ adduser test

Il comando crea automaticamente il gruppo omonimo.
Terminata la creazione dell’utente di test è necessario creare la struttura relativa alla gabbia. Per far questo è possibile utilizzare lo script create_chroot_env.sh contenuto nel file ssh-in-chroot-scripts.tar presentato nella precedente serie di articoli.
Lanciando il comando come segue:

$ ./create_chroot_env.sh /chroot

nella cartella /chroot verrà creato un ambiente con tutti i requisiti imposti da ssh per l’implementazione della gabbia.
Requisito essenziale per il corretto funzionamento del sistema è che la cartella nella quale verrà impostata la gabbia sia accessibile in scrittura alla sola utenza di root. Avendo lanciato lo script come utente root (non sarebbe possibile altrimenti utilizzare il path definito) tale requisito è pienamente rispettato.

Configurazione del demone per l’utilizzo via ssh

A questo punto la configurazione del server ssh andrà variata per supportare il chroot esclusivamente per le utenze facenti parte del gruppo test attraverso l’aggiunta delle seguenti righe nel file /etc/ssh/sshd_config:

Match Group test
        ChrootDirectory /chroot/

terminata la modifica le configurazioni andranno ricaricate attraverso il seguente comando:

$ /etc/init.d/ssh reload

Verifica del funzionamento

Per verificare il funzionamento della gabbia è sufficiente effettuare il login nel sistema e controllare come e se sia possibile muoversi all’interno di questo:

$ ssh test@172.16.1.130
test@172.16.1.130's password: 
Linux anomalia 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686
 
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
 
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jun  9 23:09:39 2009 from 172.16.1.1
-bash-3.2$ pwd
/
-bash-3.2$ ls
bin  dev  etc  home  lib
-bash-3.2$ cd ..
-bash-3.2$ pwd
/
-bash-3.2$ ls
bin  dev  etc  home  lib

l’output illustrato conferma le aspettative: a login effettuato non è possibile scorrere il path precedente alla cartella /. La gabbia funziona.

Configurazione del demone per l’utilizzo via sftp

La configurazione impostata non prevede l’utilizzo di sftp, infatti un tentativo di connessione non andrebbe a buon fine:

$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password: 
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer

per fare in modo che questo tipo di connessione sia utilizzabile, è necessario modificare nuovamente /etc/ssh/sshd_config sostituendo la riga

Subsystem sftp /usr/lib/openssh/sftp-server

con

Subsystem sftp internal-sftp

In questo modo si indica ad ssh di utilizzare per il comando sftp non lo script locale /usr/lib/openssh/sftp-server ma la versione interna al demone.

Verifica del funzionamento

A questo punto dopo aver ricaricato il demone, è possibile provare nuovamente la login via sftp:

$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password: 
subsystem request failed on channel 0
Couldn't read packet: Connection reset by peer
rasca@anomalia:~$ sftp test@172.16.1.130
Connecting to 172.16.1.130...
test@172.16.1.130's password: 
sftp> ls
bin   dev   etc   home  lib   
sftp> cd ..
sftp> ls 
bin   dev   etc   home  lib

Come da pronostico, il login ha avuto successo.
E’ da notare che in questo caso la directory di arrivo dell’utenza è sempre la / del chroot ma si può fare in modo che questa corrisponda ad una qualsiasi cartella o alla home dell’utente modificando il parametro ChrootDirectory nel file di configurazione di ssh. E’ consentito l’utilizzo delle diciture speciali %h, corrispondente alla homedir dell’utente, e %u, corrispondente al nome dell’utente.

        ChrootDirectory %h

E’ chiaro che ogni directory scelta dovrà possedere il requisito essenziale di essere di proprietà di root e non scrivibile da alcun gruppo.

Conclusioni

Rispetto alla soluzione presentata nei precedenti articoli, che comportava l’applicazione di una patch ai sorgenti di ssh, quanto illustrato ha l’indubbio vantaggio di sfruttare un’implementazione nativa che non necessita di operazioni sul pacchetto. Certo i requisiti richiesti, in particolare relativamente alla proprietà della cartella madre del chroot, sono piuttosto rigidi ed obbligano a riflettere su come distribuire le utenze.
La soluzione migliore, come sempre, è quella più funzionale allo scopo che ci si prefigge.

Dopo aver creato ed installato i pacchetti ssh con la patch per effettuare il chroot è tempo di creare fisicamente la gabbia sul disco ed un’utenza di test.

Creazione della gabbia
L’ambiente chroot in cui si muoverà l’utenza dopo aver effettuato il login dovrà essere composto sulla base delle limitazioni che si decideranno di applicare. Per il progetto descritto sinora è stato utilizzato uno script denominato create_chroot_env.sh (scaricabile nella sezione “allegati”) che accetta come parametro una directory nella quale è creato un ambiente base che comprende unicamente gli eseguibili necessari all’esecuzione della shell “bash”, del comando per il listing delle directory “ls” e di ssh stesso, in modo da consentire all’utente il collegamento sicuro ad altre macchine remote.

Una volta scaricato lo script è sufficiente eseguirlo passando come parametro la cartella nella quale verrà creata la gabbia chroot, /chroot:

./create_chroot_env.sh /chroot

Lo script creerà i path base, copierà gli eseguibili e le librerie ad essi associate ed infine creerà i device fondamentali al funzionamento del sistema chroot. Nulla vieta di modificarecreate_chroot_env.sh per aggiungere un programma diverso da quelli menzionati all’ambiente.

Ovviamente insieme ad ogni eseguibile aggiunto andranno aggiunte anche le librerie necessarie al suo funzionamento. Tali librerie sono ricavabili ad esempio attraverso il comando ldd. Per il comando ftp ad esempio l’esito di ldd sarà il seguente:

ldd /usr/bin/ftp
linux-gate.so.1 =>  (0xb7f74000)
libreadline.so.5 => /lib/libreadline.so.5 (0xb7f27000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7ef6000)
libc.so.6 => /lib/libc.so.6 (0xb7da9000)
libdl.so.2 => /lib/libdl.so.2 (0xb7da4000)
/lib/ld-linux.so.2 (0xb7f75000)

aggiungendo l’eseguibile /usr/bin/ftp e le librerie ricavate da ldd nella cartella lib/ dell’ambiente chroot, sarà possibile lanciare ftp dalla gabbia creata. Una nota di attenzione va posta sulle librerie ottenute con ldd che in realtà sono link simbolici. Nell’esempio appena riportato libreadline.so.5 è in realtà un link simbolico a libreadline.so.5.2, di conseguenza anche quest’ultimo file andrà copiato nella directory lib della gabbia chroot.

Creazione della prima utenza “carcerata”

Per completare il progetto manca solo la creazione di un utente con password che sia carcerato all’interno dell’ambiente chroot:

useradd -s /bin/bash -m -d /home/chroottest -g users chroottest
passwd chroottest

Il primo comando crea l’utente, lo assegna al gruppo users e crea la home directory, il secondo assegna la password per il login. La cartella “/home/chroottest” andrà spostata nella gabbia con i permessi limitati al solo utente:

mv /home/chroottest /chroot/home/
chmod 700 /chroot/home/chroottest/

Il comando useradd ha creato la riga relativa all’utente nel file di sistema /etc/passwd, tale riga deve essere presente nel file passwd dell’ambiente chroot. Tale operazione è possibile attraverso questo comando:

cat /etc/passwd | grep "^chroottest" >> /chroot/etc/passwd

A completamento della configurazione dell’utenza è necessaria la modifica della home directory all’interno del file passwd di sistema, vero nodo focale del progetto:

usermod -d /chroot/./home/chroottest  chroottest

Questa definizione della home directory permetterà al demone ssh di identificare l’utente come un prigioniero della gabbia e muoverlo prima di aprire una shell all’interno del path che segue il carattere “.”.

Il processo descritto può essere automatizzato con uno script come create_chroot_user.sh (scaricabile nella sezione “allegati”) al quale verrà passato il parametro relativo al nome utente :

./create_chroot_user.sh chroottest
Enter new UNIX password:
Retype new UNIX password:
passwd: password aggiornata correttamente

Primo login

Per verificare che le operazioni eseguite abbiano portato al risultato sperato è sufficiente effettuare una connessione ssh alla macchina con l’utente chroottest:

ssh chroottest@192.168.0.3
chroottest@192.168.0.3's password:
Last login: Thu Jan 31 19:31:18 2008 from 192.168.0.1
chroottest@debian:~$pwd
/home/chroottest

e verificare come non sia possibile retrocedere oltre la directory “/”:

chroottest@debian:~$ cd /
chroottest@debian:/$ ls
bin  dev  etc  home  lib
chroottest@debian:/$ cd ..
chroottest@debian:/$ ls
bin  dev  etc  home  lib

L’utente chroottest è prigioniero della gabbia creata e possiede un set di comandi limitato a quanto è stato stabilito in origine. Il progetto può dirsi quindi completo.

Siti ufficiali

OpenSSH
Patch CHROOT per OPENSSH

Bibliografia

Le pagine del Securing Debian Manual relative al chroot di ssh

Allegati

Script per la creazione della gabbia e dell’utente : ssh-in-chroot-scripts

La serie comprende questi articoli :

SSH in CHROOT: Una gabbia per la shell sicura (1 di 2)
SSH in CHROOT: Una gabbia per la shell sicura (2 di 2)

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Febbraio 2008.

OpenSSH è lo strumento per la connessione a sistemi remoti più utilizzato negli ambienti Linux: è sicuro, veloce e facile da installare. Un utente che si collega ad un Server attraverso ssh effettua un vero e proprio login nel sistema ed ha pieno accesso alle funzionalità che questo offre.

Su alcuni sistemi può però nascere l’esigenza di dover garantire l’accesso ssh ad utenze non privilegiate, che non abbiano cioè la possibilità di aggirarsi per il sistema. Certo una gestione oculata dei permessi di accesso ed esecuzione ai file critici può bastare per proteggersi, ma esiste una via più radicale per affrontare la questione, si tratta cioè della creazione di una gabbia che consenta all’utente l’utilizzo del sistema limitato ai comandi ed ai file definiti dall’amministratore : il chroot di ssh.

Significato di chroot e sua applicazione alla shell sicura

Il termine chroot (CHange ROOT) indica una forma di accesso diversa dallo standard, in un sottosistema generalmente contenente un numero di directory ed un set di comandi limitato.

Gli ambienti chroot vengono impiegati laddove si ha la necessità di far girare dei servizi in sicurezza in modo che se questi vengono in qualche modo violati, non consentono all’attaccante di aggirarsi per il sistema.

Il concetto di chroot applicato ad ssh si basa sulla stessa filosofia: restringere il set di file visionabili e comandi eseguibili i attraverso una gabbia, un filesystem ridotto all’essenziale.

osshChroot : la patch per openssh

Per utilizzare il chroot con ssh è necessario applicare una patch ai sorgenti originali del pacchetto openssh creata da Ricardo Cerqueira e mantenuta da James Dennis.

Tale patch modifica il comportamento in cui il demone openssh legge le informazioni dell’account dal file di sistema /etc/passwd. Infatti il codice aggiunto prevede che se nella home directory dell’utente che vuole effettuare il login esiste un carattere “.” (punto), allora prima di proseguire con la direzione della console alla homedir viene invocato il comando chroot sulla directory precedente il punto.

Questo significa, ad esempio, che se è stato costruito un ambiente chroot nella directory /chroot ed esiste un utente foo la cui homedir è /chroot/./home/foo, questo effettuerà il login nell’ambiente chroot creato sotto /chroot che corrisponderà per l’utente a / e la directory in cui si troverà sarà /home/foo.

Grazie a questa funzionalità sarà semplice separare utenti privilegiati da utenti “carcerati” all’interno della gabbia /chroot.

Patching, compilazione e creazione del pacchetto openssh

La procedura descritta si riferisce alla compilazione del pacchetto openssh in Debian Etch 4.0.

Per predisporre il sistema a compilare sorgenti e generare pacchetti è necessario installare i due pacchetti (e le dipendenze ad essi correlate) build-essential e devscripts:

apt-get install build-essential devscripts

Il sistema è pronto a compilare e produrre pacchetti, una volta reperiti i sorgenti di openssh attraverso il comando apt-get:

apt-get source openssh

E’ sufficiente scaricare la patch osshChroot tramite wget :

wget http://chrootssh.sourceforge.net/download/osshChroot-4.2p1.diff

Ed applicarla ai sorgenti:

cd openssh-4.3p2/
patch -p1 < ../osshChroot-4.2p1.diff

quindi attraverso la modifica del file debian/changelog o attraverso il comando debchange inseriamo le note per questo pacchetto, che riguardano essenzialmente la patch per il chroot e che hanno questa forma:

openssh (1:4.3p2-9chroot) unstable; urgency=high
 
[ RaSca ]
 
* chroot patch
 
-- root <root@debian.testlan.local>  Wed,  6 Feb 2008 16:00:08 +0100

prima di lanciare la compilazione dei sorgenti andranno soddisfatte tutte le dipendenze delle librerie del pacchetto openssh. Attraverso l’opzione build-dep del comando apt-get si può automatizzare questo processo:

apt-get build-dep openssh

E’ possibile quindi avviare la compilazione e generazione dei pacchetti attraverso il comando debuild:

debuild

I pacchetti verranno generati nella directory sottostante quella dei sorgenti:

cd ..
ls -1 *.deb
openssh-client_4.3p2-9_i386.deb
openssh-server_4.3p2-9_i386.deb
ssh_4.3p2-9_all.deb
ssh-askpass-gnome_4.3p2-9_i386.deb
ssh-krb5_4.3p2-9_all.deb

e potranno essere installati nel sistema attraverso il comando dpkg :

dpkg -i ssh_4.3p2-9chroot_all.deb openssh-client_4.3p2-9chroot_i386.deb openssh-server_4.3p2-9chroot_i386.deb

Nel prossimo articolo verrà analizzata la creazione dell’ambiente chroot e della prima utenza che vi effettuerà il login.

La serie comprende questi articoli :

SSH in CHROOT: Una gabbia per la shell sicura (1 di 2)
SSH in CHROOT: Una gabbia per la shell sicura (2 di 2)

Nota :

Questo articolo è originariamente apparso su Tux Journal nel Febbraio 2008.