Linux in Tasca: Slax e dati crittografati


Una delle prime esigenze che ho sentito lavorando sempre di più con Slax in boot dalla mia pendrive USB è stata quella di crittografare i dati che venivano salvati dal sistema. (english explanation here). Questa distro è fantastica e comodissima da portare dietro, tutto su una pendrive USB, una favola.

Tutte le modifiche alla configurazione di sistema ed i file creati o modificati durante l’utilizzo del sistema operativo vengono infatti salvati su un flat file che viene montato dallo script iniziale.

Con un minimo di conoscenza si può quindi montare quel file senza far partire il sistema ed accedere a tutti i dati contenuti.

E la cosa non è che mi facesse molto piacere, una penna USB si può sempre perdere….

Ho quindi sperimentato alcune soluzioni per proteggere i dati, senza perdere la flessibilità e la facilità d’uso che questa soluzione mi dava.

Quello che segue è il risultato a cui sono arrivato fino a questo momento. NON UTILIZZATELO PER DATI E INSTALLAZIONI REALI. Se volete potete fare qualche prova su una pennina dedicata, ma ricordate che se perdete tutto non è colpa mia ehehe In fondo sono ancora piuttosto niubbo con linux, saranno due mesi che ci frequentiamo….

Ecco in forma breve cosa ho fatto per riuscire ad ottenere la crittografazione del file di salvataggio dei dati.

  • Ho creato un file crittografato con cryptsetup, al suo interno ho creato un file system XFS
  • Ho dovuto aggiungere cryptsetup e dmsetup all’initrd di Slax, altrimenti non avrei potuto crittografare in fase di boot
  • Per lo stesso motivo ho dovuto aggiungere i moduli aes.ko e sha256.ko
  • Ho modificato lo script di Tomas per utilizzare il flat file crittato invece di quello classico (creando un nuovo cheatcode)
  • Ho modificato syslinux.cfg per includere le opzioni necessarie all’utilizzo del savefile crittato

Dopo queste operazioni otteniamo uno Slax che funziona in maniera identica a prima, può continuare ad utilizzare il vecchio sistema non crittato, ma opzionalmente può utilizzare un file crittato per il salvataggio dei dati. Durante il boot in questo caso lo script si interrompe per chiedere la password (che è stata specificata al momento della creazione del flat file). Per il resto tutto rimane uguale.

Che dire, al momento sono piuttosto eccitato per il piccolo successo ottenuto, tutto sembra funzionare come si deve, spero che non ci siano sgradevoli effetti collaterali da qualche parte. Per ora non ho modificato altre parti dello script di Tomas anche se sarebbe più pulito. Non ho neanche cambiato il cleanup finale, il file crittato viene smontato regolarmente e sembra che non sia necessario dare il comando di chiusura al sistema crittografico, speriamo sia vero ehehe

Ecco di seguito una spiegazione più dettagliata di quanto ho fatto.

Creazione del file flat crittografato e del file system xfs al suo interno. (640 MB ne mio caso)

dd if=/dev/urandom of=cryptosave.dat bs=1M count=640
losetup -f # to get the first loop available
losetup /dev/loopxxx cryptosave.dat # change xxx as needed
cryptsetup luksFormat /dev/loopxxx # ask for password
cryptsetup luksOpen /dev/loopxxx segreto # change xxx as needed
mkfs.xfs /dev/mapper/segreto
cryptsetup luksClose dev/mapper/segreto
losetup -d /dev/loopxxx

Copia dei file cryptsetup.static, dmsetup.static aes.ko e sha256.ko dentro l’initrd di Slax. Per farlo ho prima dovuto scaricare un package contenente cryptsetup, l’ho inserito nel sistema e quindi ho copiato i file nella struttura dell’initrd.

gzip -d initrd.gz
mkdir /mnt/init
mount initrd /mnt/init -o loop
cp /sbin/cryptsetup.static /mnt/init/bin
cp /sbin/dmsetup.static /mnt/init/bin
ln -s /mnt/init/bin/cryptsetup.static /mnt/init/bin/cryptsetup
ln -s /mnt/init/bin/dmsetup.static /mnt/init/bin/dmsetup
cp /lib/modules/2.6.21.5/kernel/crypto/aes.ko /mnt/init/lib/modules/2.6.21.5/kernel/crypto
cp /lib/modules/2.6.21.5/kernel/crypto/sha256.ko /mnt/init/lib/modules/2.6.21.5/kernel/crypto
umount /mnt/init
gzip initrd

Da notare che prima di fare l’umount della fase precedente è necessario fare anche le variazioni allo script linuxrd presente sempre nell’initrd. Questa sotto è la diff (se ho capito come funziona diff ehehe) Sono poche modifiche come vedete
92,98c92,100
< if ! touch $CHANGESMNT 2>/dev/null; then
< echo "- can't expand changes, perhaps a read-only filesystem?"
< else
< echolog "expanding the file for changes to $EXPANDTO MB."
< echo "- this is done only the first time you run $LIVECDNAME"
< echo "- the procedure may take few minutes, wait please."
< grow_changes "$CHANGESMNT" "$EXPANDTO" verbose
---
> if [ "$(cmdline_parameter cryptosave)" = "" ]; then # no expand for cryptosave atm
> if ! touch $CHANGESMNT 2>/dev/null; then
> echo "- can't expand changes, perhaps a read-only filesystem?"
> else
> echolog "expanding the file for changes to $EXPANDTO MB."
> echo "- this is done only the first time you run $LIVECDNAME"
> echo "- the procedure may take few minutes, wait please."
> grow_changes "$CHANGESMNT" "$EXPANDTO" verbose
> fi
102c104,117
< mount_device $CHANGESMNT $MEMORY # if empty or fails, mount tmpfs:
---
> # jimjams cryptosave start
> if [ "$(cmdline_parameter cryptosave)" != "" ]; then
> insmod /lib/modules/2.6.21.5/kernel/crypto/aes.ko
> insmod /lib/modules/2.6.21.5/kernel/crypto/sha256.ko
> CLOOPDEV=$(mknod_next_loop_dev)
> echo "$CLOOPDEV" "$CHANGESMNT" "$MEMORY"
> losetup "$CLOOPDEV" "$CHANGESMNT" 2>/dev/null
> cryptsetup luksOpen "$CLOOPDEV" cryptosave
> debug_shell
> mount /dev/mapper/cryptosave $MEMORY
> debug_shell
> else
> mount_device $CHANGESMNT $MEMORY # if empty or fails, mount tmpfs:
> fi

A questo punto ho aggiunto in syslinux.sfg una entry per il boot che utilizza il sistema crittografato. Notate il nuovo cheatcode cryptosave, senza il quale non viene usato il cryptsetup….

LABEL crypto
MENU LABEL Slax Crypto
KERNEL /boot/vmlinuz
APPEND vga=769 initrd=/boot/initrdc.gz ramdisk_size=6999 root=/dev/ram0 rw cryptosave changes=slax/cryptosave.dat autoexec=xconf;kdm

Beh come vi dicevo è per ora un esperimento, ma sembra funzionare 🙂

Annunci

2 commenti (+aggiungi il tuo?)

  1. Antonio
    Set 03, 2007 @ 13:08:03

    Bravo Mario per questo dettagliatissimo post sulla crittografia che purtroppo mi era sfuggito nei giorni estivi. Complimenti!
    Ciao,
    Antonio

    Rispondi

  2. Mario
    Set 04, 2007 @ 09:39:20

    lo sto usando ormai da tre settimane e funziona bene, e’ incredibile come sia affidabile linux per i file system, in questo caso ce ne sono almeno tre in layer e non si rompe niente ehehe non riesco a crederci…

    Rispondi

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger hanno fatto clic su Mi Piace per questo: