I sistemi Unix,
offrono generalmente una funzione che permette di fare funzionare un
processo in un file system ridotto, in cui una certa directory diventa
temporaneamente la sua nuova directory radice. Si tratta della funzione
chroot(), che nel caso di sistemi GNU/Linux, può essere utilizzata
solo da un processo con i privilegi dell'utente root.
Le distribuzioni GNU/Linux mettono normalmente a disposizione il programma chroot (1) che permette di utilizzare in pratica questa funzione. In alternativa, ne esiste un'altra versione perfettamente funzionante con GNU/Linux (anche se non si trova nelle distribuzioni), che offre il vantaggio di fondere le funzionalità di chroot e di su; si tratta di chrootuid di Wietse Venema. 187.1 Principio di
funzionamento Il processo da avviare in questo ambiente deve trovare lì tutto quello che gli può servire, per esempio le librerie, o altri programmi se il suo scopo è quello di avviare altri sottoprocessi. È la stessa situazione che si verifica quando si predispone la directory ~ftp/ per l'accesso al servizio FTP anonimo. A titolo di esercizio, può essere preparata una directory del genere riproducendo /bin/, /sbin/, /lib/ e /etc/. # mkdir /tmp/nuova_root # cp -dpR /bin /sbin /lib /etc /tmp/nuova_root Con quanto preparato in questo modo, si può avviare una shell circoscritta all'ambito della directory /tmp/nuova_root/, che viene fatta diventare appunto la nuova directory radice. # chroot /tmp/nuova_root /bin/bash Con questo comando, si fa in modo che venga utilizzata la funzione chroot() perché /tmp/nuova_root/ diventi la directory radice per il processo avviato con /bin/bash. È importante comprendere che /bin/bash va inteso qui come parte del sotto-file system e si tratta in generale si /tmp/nuova_root/bin/bash. Per concludere l'esempio, una volta verificato che si sta lavorando effettivamente in un ambiente ristretto, basta fare terminare il processo per cui è stata cambiata la directory radice, cioè bash. # exit 187.2 Possibilità
di questo meccanismo Si potrebbe immaginare la possibilità di creare delle utenze in cui gli utenti non possano girovagare nel file system, limitandoli all'ambito di un sotto-file system appunto. Tuttavia, dal momento che un sistema GNU/Linux non permette l'utilizzo della funzione chroot() agli utenti comuni, di fatto non è possibile, almeno con i mezzi normali. 187.2.1 Utilizzo di
chroot chroot directory [comando] Se non viene indicato alcun comando, viene eseguito /bin/sh, nel sotto-file system a cui ci si riferisce. Al termine del funzionamento del processo avviato con il comando, si ritorna allo stato precedente, con il file system nelle condizioni in cui si trovava prima. 187.2.2 Utilizzo di
chrootuid chrootuid directory utente comando chrootuid non fa parte delle distribuzioni GNU/Linux standard, ma può essere ottenuto facilmente dalla sua origine, presso l'università di Eindhoven in Olanda, <ftp://ftp.porcupine.org/pub/security/chrootuid1.3.tar.gz>. 187.3 Un esempio pratico:
TELNET Per semplificare le cose, si può creare una copia del sistema in funzione, a partire da una sottodirectory (ammesso che ci sia abbastanza spazio disponibile nel disco fisso). Si suppone di farlo nella directory /sicura/. # mkdir /sicura # cp -dpR /bin /dev /etc /home /lib /opt /root /sbin /usr /var /sicura # mkdir /sicura/tmp # chmod 1777 /sicura/tmp # mkdir /sicura/proc # chmod 0555 /sicura/proc Quindi si «entra» in questo sistema e si fa un po' di pulizia, eliminando in particolare tutto quello che nella directory etc/ non serve. Infatti, si deve considerare che in questo piccolo ambiente non esiste una procedura di inizializzazione del sistema, non esiste l'avvio di programmi demone e non si configura la rete. L'unica attenzione deve essere data alla configurazione delle shell che si vogliono poter utilizzare. # chroot /sicura ... # exit Il sistema circoscritto appena creato, può avere delle difficoltà a funzionare in un sistema GNU/Linux, a causa della mancanza del contenuto della directory proc/ che dovrebbe essere montato anche lì. Questo inserimento può essere definito convenientemente una volta per tutte nel file /etc/fstab del file system normale, avendo così due punti di innesto diversi e simultanei.
# /etc/fstab Una volta sistemato questo particolare, tutto funziona meglio nel sistema che si articola dalla directory /sicura/. Per fare in modo che il servizio TELNET utilizzi questo spazio riservato, si deve modificare il file di configurazione del supervisore dei servizi di rete del file system normale; per esempio, nel caso di Inetd, il file /etc/inetd.conf va modificato in un modo simile a quello seguente:
telnet stream tcp
nowait root /usr/sbin/tcpd /sicura/telnetd Come si vede, per l'avvio del servizio è stato indicato l'eseguibile /sicura/telnetd, che in pratica è uno script di shell che contiene la chiamata del comando chroot, prima dell'avvio del vero demone in.telnetd.
#! /bin/sh In questo caso, quanto indicato come /usr/sbin/in.telnetd, è in realtà /sicura/usr/sbin/in.telnetd. Una volta definito questo, dopo aver montato anche la directory /sicura/proc/ e dopo aver riavviato il supervisore dei servizi di rete, si può accedere con un cliente TELNET nel proprio sistema locare come utente root, per sistemare le cose (per farlo, temporaneamente, occorre che il file /sicura/etc/securetty preveda anche i dispositivi /dev/ttyp*, oppure quelli che sono utilizzati effettivamente per l'accesso attraverso TELNET). Una volta sistemate
le cose come si desidera, si dovrà avere cura di impedire l'accesso
remoto da parte dell'utente root, tenendo conto che al limite questo
utente potrebbe anche essere cancellato all'interno di /sicura/etc/passwd # telnet localhost ... Una volta entrati nel mini sistema, dopo essersi accertati che funziona (basta creare un file e su un'altra console virtuale vedere che si trova collocato a partire dalla directory /sicura/), si comincia a disinstallare tutto quello che non serve e che non si vuole lasciare usare agli utenti. Probabilmente, tutto quello che riguarda la configurazione della rete dovrebbe essere eliminato, mentre qualche cliente particolare potrebbe essere lasciato a disposizione degli utenti. Anche la directory dev/ dovrebbe essere controllata, lasciando al suo interno solo i dispositivi indispensabili. Di certo non servono i dispositivi che permettono l'accesso a unità di memorizzazione: gli utenti remoti non devono avere la possibilità di montare o smontare dischi. Gli stessi file etc/passwd e etc/group (ed eventualmente etc/shadow) possono essere modificati per eliminare tutti gli utenti di sistema, compreso root che potrebbe essere aggiunto nel momento in cui si volesse fare qualche intervento dall'interno). In pratica, si tratterebbe di lasciare solo gli utenti del servizio TELNET.
Copyright (c) 2000-3000 by Ing. Eduardo Palena Napolifirewall.com |