Articolo di interpuntonet.it

(Monta,con una modifica al kernel,il file system come periferica loopback e il suo contenuto viene decrittato al volo) di Paris Cristiano paris@tiscalinet.it

Il tema della sicurezza informatica è oggi alla ribalta su numerose testate del settore e su gran parte della stampa generalista nazionale. Dagli articoli che vengono pubblicati, lo scenario sembra sconfortante: hacker incalliti che tentano di penetrare incessantemente nei computer dei poveri navigatori, già tartassati da problemi più concreti ed immediati, come le tariffe telefoniche che non accennano a diminuire.
La situazione in realtà è più rosea di quanto non si creda e, anzi, internet ci viene in aiuto come una fonte efficace e puntuale di informazioni sulle problematiche sollevate da un uso "ingenuo" del personal di casa, proponendo soluzioni semplici e alla portata di tutti.
Spesso, però, l'esigenza di proteggere i propri dati è reale e il contesto in cui ciò si verifica è spesso tra le stesse mura domestiche o all'interno di una lan aziendale od universitaria. E Linux ci viene in aiuto con strumenti facili da utilizzare ed estremamente flessibili.

Crittografia, questa sconosciuta

L'esigenza di proteggere le proprie comunicazioni da orecchie indiscrete è ben radicata nell'uomo: dal corriere a cavallo al pacchetto che si instrada tra i flussi tcp/ip, la necessità di rendere indecifrabili i dati sensibile è da sempre un interesse primario.
Cerchiamo però di inquadrare il problema in un ottica più vicina a noi; supponete che Alice debba spedire una messaggio ad Andrea. Tale messaggio contiene delle informazioni segrete che solo Andrea dovrebbe essere in grado leggere. Le informazioni contenute nel messaggio vengono quindi "codificate" con un mezzo di qualche tipo, come ad esempio la scrittura.

Nell'era informatica, Alice manderebbe un'email ad Andrea e il mezzo di codifica utilizzato sarebbe lo standard ascii che utilizziamo ogni giorno per scrivere testi. Il problema è che il testo scritto è intelligibile a chiunque sia in grado di leggerlo, visto che tutti conoscono il sistema di codifica del messaggio, la scrittura appunto.
Alice, allora, potrebbe inventare un nuovo sistema di codifica che farebbe conoscere solo ad Andrea, il quale diventerebbe, insieme ad Alice, l'unica persona in grado di capire il messaggio. Questi sistemi di codifica vengono definiti "crittosistemi", dalla parola "crittografico", il cui significato è "oscuro, incomprensibile".
In realtà, nei moderni crittosistemi si utilizzano schemi ben definiti: si stabilisce il sistema di codifica, che risulta noto a tutti, e si stabiliscono una o più "chiavi", ovvero oggetti che, tramite il crittosistema appunto, operano sul messaggio per codificarlo o per decodificarlo; e sono proprio queste chiavi a rimanere segrete.
Il punto fondamentale di tutto questo discorso è che, fatti salvi alcuni casi, un testo codificato con un crittosistema, risulta completamente illeggibile e privo di senso a chiunque non sia in possesso della chiave giusta per codificarlo: un testo crittografato è come fosse in una cassaforte.

Loopback device

Passiamo ora ad un argomento completamente diverso: i "loopback" device (la cui traduzione, un po' fantasiosa, potrebbe essere: "dispositivi che si mordono la coda"). Nella directory /dev di un sistema Unix sono presenti alcune device, indicati con la sigla

/dev/loop0
/dev/loop1

etc, il cui uso consiste nel "ricoprirli" con file presenti su un altro dispositivo, come un disco rigido, un volume nfs o un cdrom. Una volta che il device è stato "ricoperto", questo si può montare come un qualunque altro block-device il cui contenuto è stabilito proprio del file utilizzato. A questo punto è bene fare un esempio: supponiamo di voler creare un dischetto di "rescue", nell'eventualità che Linux un giorno si rovinasse, e di volerne distribuire l'immagine via internet.
Un utente proveniente da msdos probabilmente tenderà a formattare il dischetto, ad inserirvi dentro tutti i file necessari e a estrarre dal floppy un'immagine. L'utente Linux, invece, farà la cosa in maniera più "intelligente"; innanzitutto creerà un file di 1440Kb sul proprio disco rigido, con il comando:

dd if=/dev/zero of=~/dskimg bs=1024 count=1440

Tale comando copia il contenuto dei primi 1440Kb del file /dev/zero nel file ~/dskimg. Il file /dev/zero è un character device particolare, il quale restituisce, in ogni caso una serie di zeri e quindi il file ~/dskimg sarà una sequenza di 1474560 zeri: questa operazione corrisponde alla formattazione del dischetto, solo che, essendo fatta su un file disco rigido, risulterà estremamente più veloce.
A questo punto dovremo creare il file system, ovvero decidere quale formato debba avere l'immagine. Scegliamo allora il formato ext2, che è il più congeniale per Linux; diamo dunque il comando:

mke2fs ~/dskimg

A questo punto ~/dskimg contiene l'immagine di un dischetto vuoto, formattato in ext2, nel quale possiamo trasferire dei file; per far questo si potrebbe copiare l'immagine su un dischetto

dd if=~/dskimg of=/dev/fd0H1440 bs=1024 count 1440

montarlo e quindi copiarvi dentro i file necessari. Tutto questo, però, non ha molto senso dato che tutto può essere fatto direttamente su un dischetto vuoto; perché, quindi, non approfittare della velocità del disco rigido, saltando quest'ultima operazione? A questo scopo, possiamo usare i loopback device:

mount ~/dskimg /mnt/floppy -t ext2 -o loop=/dev/loop0,+
blocksize=1024

Questo comando ricopre il /dev/loop0 con il file ~/dskimg e lo monta in /mnt/floppy, dove sarà presente un file system tipico di un dischetto che in realtà non esiste. Su quest'ultimo si possono copiare file come su un comunissimo floppy che, alla fine delle operazioni, potrà essere tranquillamente smontato. Il file ~/dskimg può poi essere messo su internet per chiunque voglia farne uso, senza che un vero dischetto sia mai stato toccato.
Gli usi che se fanno sono comunque molto diversi: ad esempio potete scaricare l'immagine di un cdrom da internet (ad esempio quello di una distribuzione Linux) e procedere poi alla sua ispezione senza masterizzarlo, ma assegnando l'immagine iso a un loopback device e dando un comando analogo a quello visto in precedenza, aggiungendo l'opzione -t iso9660.

Loopback e crittografia: miscela esplosiva

Cosa c'entrano i loopback device e la crittografia? Lo vediamo subito. Innanzitutto dovete sapere che il kernel fornito con qualsiasi distribuzione Linux, nonché quello distribuito ufficialmente dal sito www.kernel.org è privo di un'importantissima componente: la crypto api. Questa fornisce una serie di potenti crittosistemi direttamente a livello di kernel, rendendo disponibili alcune funzioni che i programmi possono chiamare per implementare meccanismi di crittografia al loro interno. I loopback device, ad esempio, beneficiano proprio della presenza della crypt api: tramite questa e il modulo loop_gen è possibile crittografare in tempo reale e in maniera del tutto trasparente l'immagine di un filesystem.
Ma come implementare queste funzioni nel kernel? Innanzitutto dovrete scaricare la patch internazionale relativa al vostro kernel dal sito ufficiale www.kerneli.org; se, ad esempio, avete il kernel 2.2.13, dovete scaricare la patch chiamata int-2.2.13.x, dove x è un numero che indica la versione della patch internazionale: più è alto tale numero, più recente sarà la patch.
Ora, andate in

/usr/src

o nella directory dove avete installato i sorgenti del kernel, e date il comando:

ln -s linux-2.2.13 int-2.2.13

Supponendo che la patch si trovi anch'essa nella directory /usr/src e che sia compressa con bzip2 (estensione .bz2), lanciate

bzip2 -cd patch-int-2.2.13.x | patch -p0

che provvederà ad apportare le opportune modifiche ai sorgenti del kernel. Passate quindi alla configurazione Provvedete quindi alla configurazione, dando il comando make xconfig (o make menuconfig o ancora make config) e attivate le seguenti caratteristiche (y = yes, m = module)::

Sezione Crypto
Crypto ciphers - m
Blowfish cipher m
DES cipher m
DFC cipher m
IDEA cipher m
MARS cipher m
RC5 cipher m
RC6 cipher m
Serpend cipher m
Digest algorithm m
MD5 digest m

Sezione Block Device
Loopback device support m
Use relative numbers... m
General encryiption...m
CAST 128 encryption m
Twofish encryption m

Sezione Netowrking Options
CIPE:encrypted IP-in-UDP tunnelling n

A questo punto, se avete la versione 2.2.13 del kernel con la patch internazionale 2.2.13.2, sorge un problema (che forse si ripeterà nelle versioni successive): noterete, infatti, che l'opzione "General encryption support" non si attiverà se premete "m", a causa di un bug nei file di configurazione. Per aggirarlo, dovete editare il file

/usr/src/linux/drivers/+
block/Makefile

e cercare le linee:

ifeq ($(CONFIG_BLK_DEV_LOOP_GEN)+
,y)
LX_OBJS += loop_gen.o
else
ifeq ($(CONFIG_BLK_DEV_LOOP_GEN)+
,m)
MX_OBJS += loop_gen.o
endif
endif

cancellandole ed inserendo al loro posto la linea:

MX_OBJS += loop_gen.o

A questo punto ricompilate come al solito, installate il kernel e i moduli e riavviate. Se tutto è andato bene, siete quasi pronti ad utilizzare i loopback crittografati.

Editate il file

/etc/conf.modules

e inserite le linee:

alias net-pf-5 off
alias net-pf-4 off
alias net-pf-3 off
alias net-pf-6 off
alias loop-xfer-gen-0 loop_gen
alias loop-xfer-gen-10 loop_gen
alias loop-xfer-2 des
alias loop-xfer-4 blowfish
alias loop-xfer-6 idea
alias loop-xfer-7 serp6f
alias loop-xfer-8 mars6
alias loop-xfer-11 rc62
alias loop-xfer-15 dfc2
alias loop-xfer-16 rijndael

Queste linee sono essenziali al modulo "loop_gen" per identificare i vari crittosistemi con le rispettive cifre di riferimento (ad esempio, 6 = idea). A questo punto non rimane che prelevare la versione modificata del comando "losetup" che vi consentirà di utilizzare la cripto api: scaricate il file "util-linux-x.yz.tar.bz2" da ftp.kerneli.org, dove x, y e z sono il numero di versione indicata nel nome del file analogo "util-linux-x.yz.patch" in /usr/src/linux/Documentation/crypto/, e decomprimetelo in una directory (ad esempio, /usr/src) nella quale, supponendo di aver creato la directory /usr/src/util-2.9w, dovrete lanciare il comando:

cat /usr/src/linux/+
Documentation/crypto/+
util-linux2.9w-patch | patch -p0

Fatto questo, ricompilate il contenuto di "util-linux2.9w", evitando lo stadio del "make install" dato che potreste causare gravi danni al sistema operativo, compromettendo ad esempio la possibilità di accedere al prompt. Copiate solamente il file

/usr/src/util-linux2.9w/+
mount/losetup

in

/sbin

A questo punto avete a disposizione tutti gli strumenti necessari per crittografare i loopback device.

Alcuni consigli

All'atto pratico, l'utilizzo di un loopback device criptato non differisce da quello di uno standard. A cambiare è solo il comportamento di losetup, l'utility che consente di associare il loopback device ad un file o a u block device. Ad esempio, nel caso precedente, dopo aver creato il file immagine ~/dskimg e prima di creare il filesystem, date il comando:

losetup -e des /dev/loop0 ~/dskimg

Il programma vi chiederà una parola chiave che, a differenza della password di sistema, deve essere molto lunga: i crittosistemi moderni, infatti, utilizzano chiavi a 128-bit o più (a parte des che utilizza 64-bit) corrispondenti a ben 16 caratteri, che diventano molti di più se i 128-bit sono mappati sul solo insieme lettere+numeri. Con des, invece, dovete inserire almeno una decina di caratteri per la chiave (in questo caso non si parla di "password" ma di "passphrase", frae chiave, essendo questa molto più lunga; le passphrase sono migliori perché sono più immuni ad attacchi basati su dizionario). Se utilizzate, idea o addirittura Blowfish, le cose si complicano con chiavi a 20 caratteri o più che garantiscono un livello "militare" di protezione, oltre ad essere molto pesanti dal punto di vista della decodifica. Se potete, quindi, vi consigliamo di utilizzare il des per le vostre applicazioni.
Ritorniamo al nostro esempio. È il momento di creare il filesystem ext2:

mke2fs /dev/loop0

e quindi di "montarlo":

mount /dev/loop0 -t ext2 /mnt/floppy

dopodiché potete cominciare a copiare i file. Terminate le operazioni di copia, smontate l'immagine con la sequenza:

umount /dev/loop0
losetup -d /dev/loop0

Ora, l'immagine del vostro dischetto sarà completamente crittografata e solo voi che conoscete la password sarete in grado di montarla e leggerne il contenuto. Questo meccanismo è molto comodo per crittografare un'intera parte dell'albero della vostra home directory (ad esempio quella contente documenti privati) e renderla inaccessibile anche a chi riuscisse ad infiltrarsi dall'esterno nel sistema operativo.
Questo approccio, tuttavia, presenta degli inevitabili svantaggi:

1 - L'uso di un crittosistema degrada le prestazioni del sistema, che è costretto ad eseguire calcoli molto lunghi e complicati su ciascun blocco del disco rigido. E' vero che questa situazione è leggermente mitigata dal fatto che i tempi di latenza dei dischi fissi sono molto alti e che quindi tale overhead risulta alla fine trascurabile; tuttavia, in un sistema che utilizza pesantemente copie cache in memoria centrale dei blocchi su disco, tale sovraccarico potrebbe essere evidente.

2 - I mount sono pubblici. Quando un file system è montato in una qualsiasi directory, virtualmente il suo contenuto è accessibile a chiunque. Teoricamente, il problema si potrebbe risolvere restringendo l'accesso al mount point (tramite i comandi chown, chgrp e chmod), ma è pur vero che gran parte degli attacchi dall'esterno mirano ad impossessarsi dei privilegi di root, che è comunque in grado di accedere a qualunque risorsa. Quando non siete nel sistema, i vostri dati sono al sicuro, ma se entrate e montate il filesystem crittografato, non c'è garanzia ulteriore.

Per aggirare il secondo problema, montate il filesystem solo quando siete sconnessi dalla rete oppure, se questo è troppo costoso (in un server questo non si può fare), utilizzate altri tool, come il Secure File System, che forniscono servizi analoghi tramite interfacce di rete nfs e sono pensati per a risolvere questo tipo di inconvenienti.
Infine, segnaliamo un ulteriore problema: se provate, infatti, a masterizzare l'immagine di un file system crittografato, noterete che i dati al suo interno non saranno più accessibili dal cdrom. Questo perché, nella trasposizione, è cambiata la lunghezza del blocco del device su cui l'immagine è registrata: tale parametro è utilizzato da loop_gen.o nell'algoritmo di crittografia e può essere considerato parte integrante della chiave. Visto che la lunghezza del blocco è cambiata, anche la chiave è cambiata e voi non potrete più decodificare il file system.
In un futuro questo problema verrà certamente risolto e io stesso, infatti, ho proposto una modifica al kernel che, se verrà approvata nelle prossime versioni, dovrebbe risolvere questo inconveniente. Comunque, se non avete necessità di criptare cdrom e volete assicurarvi un po' di privacy in più, provate i loopback device e ricordatevi le passowrd!