Debian Live

Living in Debian

L'altro giorno, gironzolando al centro commerciale, così per passare il tempo, ho visto le nuove chiavette USB in svendita e tra i maialini e i pupazzetti di varia natura, ho trovato chiavette da decine di Giga a prezzi veramente stracciati.

Sarà per deformazione professionale, o perché il primo hard disk che vidi nella mia vita, era di 20Mb e costava come un'automobile, che tutte le volte che mi cade l'occhio su una chiavetta USB o una Micro-Sd da decine di Gb, incomincio a fantasticare sulle incredibili possibilità che un tale dispositivo potrebbe darci con il sistema operativo giusto.

Un paio di anni fa realizzai con Ubuntu un live su chiavetta che usavo per collegarmi alla mia banca dai computer con Windows, poi Ubuntu lentamente si è trasformata in tutt'altro e io sono migrato a Debian che per altro è molto pulita ... ma qui ho dovuto scontrarmi con l'amara realtà.

Tools come Casper e UCK da queste parti ce li si può scordare, così, come tutti i tecnici per bene, sono  andato ad indagare Googlando qui e là per cercare come realizzarsi un Live Cd della più famosa distribuzione e l'impatto è stato traumatico, visto il gran numero di specchi e di persone che cercavano di arrampicarvisi, per spiegare l'inspiegabile.

live-build

Per fortuna, da qualche anno a questa parte c'è un nuovo orizzonte per la realizzazione di Live Debian, ovviamente è un insieme di script e si chiama live-build.

Per usarlo si deve partire da una distribuzione Debian e installarlo sulla stessa e qui iniziano diverse difficoltà.

Capita infatti che insieme a live-build, vi siano una serie di altri pacchetti dello stesso tipo, come live-config che sono "usati" ma non "installati".

Infatti i pacchetti aggiuntivi, benché abbiano il nome di comandi che sono interni a live-build, saranno installati direttamente sulla macchina che andremo a fare e cioè, per intenderci noi lanceremo i comandi da live build e in particolare il comando "lb" con i vari parametri, e gli script di cui si compone scaricheranno i giusti pacchetti, come quelli per la gestione del boot e li installeranno sulla live che faremo, nella giusta versione.

Detto questo vediamo come si può procedere.

Innanzi tutto iniziamo a diventare root della macchina su cui operiamo che è la scelta migliore, quindi diamo su.

Diventati root, se non l'abbiamo ancora fatto, installiamo il pacchetto che ci serve e cioè live-build.

Poi con particolare attenzione dobbiamo creare una cartella live dentro la directory /root ed entrarci. Riporto qui di seguito la possibile sequenza dei comandi da eseguire, anche se ovvia :

$ su
# apt-get install live-build
# cd
# mkdir /root/live
# cd /root/live

ok ? Perfetto, ora che siete in live e in perfetta forma, possiamo dare il : grande comando che tutti vogliamo sapere e cioè :

# lb config -a i386 --binary-filesystem fat32 --distribution wheezy --debian-installer false --archive-areas "main contrib non-free" --package-lists xfce  --interactive shell -b hdd

Nonostante il comando sia intuitivo e non necessiti spiegazioni ( ovviamente scherzo), diamo un dettaglio delle singole opzioni :

• lb config è il comando che si compone di lb e di config come prima opzione. Questo comando provvederà a lanciare la configurazione, nella cartella corrente, cioè live.
• -a i386 è l'opzione che imposta l'architettura. Allo stato attuale è meglio che la live sia compatibile con le macchine a 32 bit, invece che quelle a 64, visto che il nostro obiettivo è quella di farla girare sul maggior numero possibile di macchine.
• --binary-filesystem fat32, ci dice che scegliamo la fat32 come File System, perché vogliamo fare una chiavetta USB e non un obsoleto e lento DVD.
• --distribution wheezy . Ed ecco che nella live, possiamo scegliere subito quale distribuzione installare e non passare per l'installazione standard. Ricordo che in questo momento wheezy è ancora in testing , e se si scaricano le immagini standard dal sito, c'è la squeeze.
• --debian-installer false , significa che non stiamo facendo una chiavetta di installazione ma una live, quindi non ci servono cartelle coi pacchetti o live installer.
• --archive-areas "main contrib non-free" , ci dice i repositories di riferimento, quelli cioè a cui attingeremo, in questo caso li ho messi tutti, perché come ho spiegato, ci sono parecchi casi in cui potrebbero servirci i drivers closed per il nostro hardware. Premetto che dal punto di vista della sicurezza non è il massimo, e lascio alle scelte personali.
• --package-lists xfce. Questo parametro merita un discorso a parte. Infatti nelle vecchie versioni dello script lb,c'era un altro parametro e cioè --packages che ora non funziona più o per lo meno secondo il puro stile Debian funziona a giorni alterni, a seconda della versione dello script e io suggerisco di non usarlo. Per quanto riguarda il nome che c'è dopo package-lists, le varie liste dovreste trovarle in  /usr/share/live/build/package-lists e c'è riportato il profilo base del sistema.
• --interactive shell , questa è una opzione importantissima perché ci permetterà di personalizzare la live come piace a noi. Similmente a quanto fa UCK ci permetterà infatti di accedere al sistema e alla gestione dei pacchetti da un prompt di shell, direttamente durante la realizzazione della live stessa.
• -b hdd, definisce e forza la tipologia del dispositivo da realizzare ad hdd, che significa esclusivamente "immagine binaria per disco esterno" o file .img.

Il comando terminerà subito o quasi, ma si sarà preoccupato di costruire alcune cartelle all'interno della nostra live. Non resta che lanciare il comando fondamentale per costruire il tutto e cioè :

# lb build

e attendere un poco fino al prompt interattivo.

Il Prompt Interattivo

Ad un certo punto dell'esecuzione di lb build, che proseguirà a installare e configurare varie cose, appariranno tre righe :

P: Begin interactive build...
P: Pausing build: starting interactive shell...
(live)root@<hostname>:/#

Qui non siamo più nella nostra macchina, ma siamo già nel nuovo sistema operativo che stiamo installando. Ciò è possibile grazie al famoso chroot, uno dei comandi che i sistemisti arditi, amano di più.

Il chroot è eseguito automaticamente nella cartella che ora è /root/live/chroot e dove ha sede il sistema che stiamo costruendo ed è da qui che possiamo costruire tutto il resto.

Customizing

La prima cosa da fare è individuare un set di pacchetti adatti all'occasione.

Io procederò a realizzare una distribuzione con "Persistenza Parziale" e file system cryptato.

File System Criptato ?

Si, e il motivo è evidente. Dobbiamo tenere conto che la Memory Stick in qualsiasi forma essa sia, si può perdere molto più facilmente di un PC o la si può lasciare su un tavolo ed è quindi sempre opportuno criptarne i contenuti, specialmente se questo è facile come con Linux. Per questo introdurremo il pacchetto cryptosetup che useremo sul resto dello spazio a disposizione nella chiavetta.

 

 La lista dei pacchetti

Teniamo in considerazione che stiamo parlando di una live, quindi non potremo né aggiungere né aggiornare pacchetti dopo l'installazione.

Se in futuro avremo bisogno di qualche cosa, potremo in piccola parte rimediare col meccanismo della persistenza parziale (che vedremo) e poi ce la potremo annotare per la prossima riscrittura della chiavetta.

Visto che nel file di configurazione generale ho indicato xfce, adatto o inadatto a più o meno tutte le macchine, ho scelto la seguente lista dei pacchetti.

# apt-get install cryptsetup icedove iceweasel enigmail ffmpeg vlc mplayer mozilla-plugin-gnash libreoffice evince cpufreqd firmware-linux-nonfree wicd xfce4-terminal

ma voi potete fare come preferite, e lasciare che il comando poi faccia il suo corso.

Con lo stesso sistema possiamo configurare intere parti della nostra live ed in particolare implementare la persistenza parziale.

 

Persistenza Parziale

Nel mondo delle Live Linux ci sono quelle persistenti e quelle non persistenti.

Le prime usano come home per l'utente o per l'intero sistema un spazio opportunamente configurato sulla chiavetta. Personalmente non apprezzo molto questa soluzione, per due motivi :

1. La flash è un tipo di memoria a scritture limitate e pensare che mentre navigo, la cache del mio browser tortura lentamente la mia chiavetta mi da fastidio.
2. Uno dei motivi per cui prediligo una chiavetta ad un computer è che i dati che lasciano tracce come le cronologie di navigazione, i cookies, e la stessa cache, spariscono per sempre quando spengo la macchina.

Il secondo tipo di live, perdono tutto e hanno i seguenti difetti :

1. Ti obbligano a salvare ciò che non vuoi perdere sulla parte rimanente della chiavetta o su cloud ed è una operazione come minimo fastidiosa ma può diventare addirittura drammatica se hai fretta e non te lo ricordi.
2. La cosa più importante è che, con questo sistema, ogni modifica sarà persa per sempre e ciò non è una cosa buona, specialmente se vogliamo cambiare qualcosa senza rifare tutto da capo.

Per ovviare a questo inconveniente personalmente ho sempre seguito una terza strada che è quella che ho definito della "persistenza parziale" che assomiglia molto ad una live del secondo tipo (cioè senza persistenza) ma ha tre features fondamentali :

1. Monta automaticamente il resto della chiavetta che di solito è un file system sicuro e codificato, come parte integrante di quello corrente, lasciando uno spazio per aggiungere comandi e dati.
2. È in grado di eseguire uno script presente su questo file system che a sua volta può lanciare altri processi, creare links e modificare il sistema in base al contenuto della sua parte volatile. 
3. I link simbolici lanciati da questo script, con i giusti permessi, consentono anche di inserire nella home dell'utente ( che nelle live si chiama user ), una cartella persistente "Documents" scrivibile, o sostituire la cartella contenente la posta, le password di Firefox , e in generale tutto ciò che vogliamo tenere, direttamente sulla parte persistente della chiavetta e il bello è che tutto questo lo possiamo fare dinamicamente in un secondo momento. 

Implementare il tutto

Premesso che il file system,  userà cryptosetup e quindi sarà codificato, dobbiamo sceglierne il tipo.

Usando un file system che sfugge al sistema degli inodes, tipo fat32, troveremo diverse limitazioni, specialmente per quanto concerne links e files speciali.

Usando invece una normale struttura tipo ext3/ext4, che sono journalized , aumenteremo a dismisura la quantità di scritture sulla nostra povera chiavetta.

Andremo quindi ad usare un ext2 che provvederemo a far controllare dal sistema alla ripartenza, mediante l'apposita opzione in fstab.

A questo punto dobbiamo editare il file  /etc/crypttab che è l'impostazione del cryptosetup ma prima ci serve un UUID che useremo per il disco, sia durante questa fase, sia ancora più avanti per formattare la parte rimanente della chiavetta.

Lanciamo quindi il comando :

# uuidgen

che ci darà l'UUID nella classica forma Linux : 

XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Teniamo da parte questo valore che nelle nostre spiegazioni chiameremo <UUID> , conservandolo per esempio in una schermata di un editor di testo in un'altra finestra.

A questo punto si dovrà editare il file /etc/crypttab e inserirvi qualcosa tipo :

# <target name>    <source device>        <key file>    <options>
encrypted    UUID=<UUID>    none    luks

dove <UUID> è appunto quel valore.

Ora editiamo /etc/fstab che è vuota e scriviamo :

/dev/mapper/encrypted  /ext   ext2    noatime  0       1

Creiamo il punto di mount :

# mkdir /ext

E abbiamo così terminato le modifiche al sistema live per poter gestire il file system criptato, poi vedremo il dettaglio di come creare la partizione relativa.

La richiesta per "system.init"

Posto che ext sarà il punto di mount del file system codificato e residente nella seconda partizione che faremo nella chiavetta, chiederemo di lanciare al sistema (a livello root) un semplice script, ivi residente e che potremo modificare a nostro piacimento :

Il posto migliore dove lanciare questo script in modo che sia eseguito al boot è /etc/rc.local e quindi si può editare lo script in questo modo :

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

( . /ext/system.init )
exit 0

Teniamo in considerazione che nelle nuove versioni di Debian l'esecuzione degli script di partenza è parallela e quindi questo sarà eseguito parallelamente e non sequenzialmente al caricamento della parte grafica, ciò comporterà alcuni vantaggi e svantaggi.

Ora comunque terminiamo con un semplice :

# exit

e il sistema costruirà l'immagine del disco che ci serve.

Trasferimento su USB Dongle

Per il trasferimento su USB, abbiamo bisogno di una chiavetta USB che cancelleremo completamente e abbiamo bisogno assolutamente di individuare come si chiama il device fisico su cui è montata.

Se il computer su cui stiamo facendo le prove ha un solo disco, di solito questo si identifica in /dev/sda, per cui è pensabile che la chiavetta vada ad occupare /dev/sdb, come sulla mia macchina.

Per aumentarne la certezza è buona norma usare il comando :

# cat /proc/partitions

8        0  312581242 sda

...
11       0    1048578 sr0

che ci fornisce un elenco di tutti i dischi presenti sul computer in quel momento, con le relative partizioni.

Dopo avere inserito la chiavetta sacrificale (cioè che sarà cancellata) dovremmo vedere apparire almeno sdb ed eventualmente una o più partizioni sdb1,sdb2 ....

8       16    3922944 sdb
8       17     425952 sdb1

quella sarà la nostra chiavetta dal punto di vista fisico. A noi le partizioni non interessano perché le riscriveremo con un disk dump.

La chiavetta si identifica facilmente, anche perché il numerino che c'è prima del device è il numero di settori da 1K, in questo caso circa 4 milioni cioè 4 Giga.

Per intenderci, la chiamerò <device>, che nel mio caso è appunto /dev/sdb , mentre indicando <device>1, <device>2 ecc... , indicherò le singole partizioni /dev/sdb1, /dev/sdb2 eccetera. Voi le sostituirete col device che avete trovato.

Attenzione perché di solito quando inserite la chiavetta a desktop attivo, questa ha la buona abitudine di apparire sul desktop stesso. La mossa giusta è non rimuoverla con il desktop, altrimenti rischia di sparire dal sistema ma smontare singolarmente le varie partizioni da linea di comando e cioè, visto che avete già aperto un terminale dare :

# umount <device>1...n

ossia :

# umount /dev/sdb1
# umount /dev/sdb2
...

e se avete centrato la chiavetta, le iconcine dovrebbero sparire dal vostro desktop, così avrete una ulteriore conferma di quale sia il vostro <device>.

Se tutto è andato bene, nella cartella live, troveremo ora un file piuttosto voluminoso e chiamato binary.img dell'ordine di qualche centinaio di megabytes, a seconda dei pacchetti che avete installato.

Quello è il file che dovremo copiare fisicamente e questa operazione va svolta come ho già detto, CON LA MASSIMA ATTENZIONE !!!, perché se sbagliate device, porterà inevitabilmente alla cancellazione del disco sbagliato, con tutte le conseguenze del caso.

Per farlo useremo il famigerato disk dump dd , che penso sia il comando più pericoloso che abbiamo a disposizione nel sistema, visto che da solo può far saltare l'intero contenuto del disco, senza possibilità di recupero.

Noi operiamo in questo modo, dalla cartella live :

# dd if=binary.img of=<device>

cioè eseguiamo un dump fisico dell'immagine sul device che nel mio caso è /dev/sdb come ho già più volte detto (non indicate alcuna partizione ma il device generico).

Ci vorrà un pochino e se avete una chiavetta con il LED, vedrete anche la lucina lampeggiare.

Cryptosetup

Dopo l'operazione di trasferimento, è il momento di creare la famosa partizione codificata, quindi rimuovete la chiavetta e reinseritela.

Dovreste vedere apparire sul computer un disco chiamato : "DEBIAN_LIVE" che dovrete smontare sempre da linea di comando, dovrebbe essere la partizione 1 e quindi date :

# umount <device>1

che nel mio caso è umount /dev/sdb1.

Fatto sparire dal file system il mount del dispositivo, possiamo usare il comando cfdisk, in questo modo :

# cfdisk <device>

cfdisk, è un programma scritto con le curses, e quindi sarà a pieno schermo terminale in formato testo e quindi relativamente facile da usare, non sto a spiegare come funziona nel dettaglio visto che, se avete resistito fino a qui, probabilmente per voi non sarà un problema.

Dovreste vedere la partizione 1 che è una fat32, come avete indicato precedentemente. Andate quindi sullo spazio libero e create una nuova partizione 2, che occupi tutto lo spazio restante a partire dall'inizio e indicando come tipologia del file system il formato ext2 ma non create alcun file system.

Le nuove versioni di cfdisk richiedono il "Commit" prima del Quit , per convalidare le modifiche, fate pure.

Ora, anche senza riavviare se date il famoso comando :

# cat /proc/partitions

dovreste vedere oltre che il device anche due partizioni, cioè nel mio caso /dev/sdb, /dev/sdb1 e /dev/sdb2.

Dopo aver creato la partizione, bisogna prima formattarla in modo codificato e poi mettevi il file system ext2,

Alcuni suggeriscono di introdurre il comando opzionale :

# dd if=/dev/urandom of=<device>2 

Che sostituisce ai tranquilli bytes pre-formattati, della nostra chiavetta, una sequenza casuale di valori, allo scopo di rendere indistinguibili i blocchi codificati dal "background" e aumentarne così la sicurezza. Se volete fate pure ma ricordate che cryptosetup usa per lo meno CBC a differenza del vecchio EBC, quindi è molto meno sensibile agli attacchi sui patterns. Se invece non avete capito di cosa sto parlando, lasciate perdere e state tranquilli.

L'operazione suddetta comunque è lunghetta e occupa parecchi minuti anche su chiavette di piccole dimensioni.

Ora, comunque, è il momento di ripescare l'UUID che avevate salvato nell'editor e inserirlo nel seguente comando :

# cryptsetup luksFormat <device>2 --uuid="<UUID>"

quindi seguire le indicazioni.

Vi verrà chiesta una password che sarà la password unica della chiavetta.

Attenzione perché se la dimenticate, non ci sarà più alcun modo di accedere ai vostri dati, visto che per fortuna non è salvata da nessuna parte.

A questo punto "apriamo" il device in questo modo :

# cryptsetup luksOpen <device>2 encrypted

e poi, dopo avere dato la password per sbloccare il device, creiamo il file system ext2  con :

# mkfs.ext2 /dev/mapper/encrypted

e infine chiudiamo con :

# cryptsetup luksClose encrypted

e dovremmo avere terminato.

Riavviamo la macchina e facciamo boot dalla chiavetta.

Nota : Poiché tutte le volte che rifacciamo la procedura, dal primo disk dump , dobbiamo cancellare l'intero contenuto della chiavetta, per eventuali aggiornamenti, consiglio : per prima cosa di aprire il file system codificato ( dovrebbe bastare inserirla su una macchina con Linux e attendere la richiesta del computer ),  poi salvare il tutto in un bel tar col preserve dei permessi e quindi richiudere per poi ricostruire tutto in seguito, montando temporaneamente il file system ed espandendovi il tar prima di chiudere con luksClose.

Aggiustare /ext

Una volta fatto ripartire il sistema, il boot si fermerà ad un certo punto chiedendoci di inserire una password, che sarà quella che abbiamo inserito per il file system codificato, da montare automaticamente in /ext.

Se tutto va bene entrando nella cartella /ext dovremmo trovare la famosa "lost+found".

Ora possiamo diventare root, con sudo bash  (senza password) e iniziare a modificare.

Entriamo nella cartella /ext ed eseguiamo :

# cd /ext
# mkdir bin etc lib sbin share init var

Per creare un po` di cartelle. 

Poi c'è lo script /ext/system.init che può essere realizzato sullo stile del "profile" così :

#!/bin/sh
for i in /ext/init/*
do
 ( . $i )
done

in questo modo ogni script inserito nella cartella init, sarà eseguito e attingendo alle varie informazioni, contenute nelle altre cartelle montate sotto /ext, potrà modificare a piacimento il sistema all'atto dello startup.

Varie ed eventuali 

Una delle cose che faccio fare al mio sistema quando riparte, è quello di ripristinare nella cartella /home/user, un tar dell'intero contenuto della mia user e alcuni links, in modo che il sistema riparta, non nello stato di default con l'orribile "ratto" di xfce , ma in modo esteticamente più accettabile ( per quanto possibile).

Mettendo alcune voci .desktop in .local/share/applications ho poi arricchito i menù con programmi che stanno in /ext/bin e il .profile, fa in modo che tali directory siano anche nel PATH.

Ho anche uno script che installa il pacchetto " tor ", preso direttamente dal sito, e aggiornato di volta in volta nella parte scrivibile, estraendo semplicemente il tar e giochicchiando con processi e iptables, per vincolare la connessione di rete all'exclusivo passaggio dal proxy.

Di fatto una distribuzione volatile, con i dati criptati e tor , non è proprio identica a quell'affascinante progetto del famoso romando di Cory Doctorow e denominato Paranoid Linux ma è comunque un sistema più che decente, perché sta su una chiavetta, non mantiene memoria di ciò che fate a meno che non lo vogliate e lo potete portare sempre con voi in un portachiavi.

In ogni caso potremo fare tutte le modifiche che vogliamo, sia dinamicamente che in ulteriori versioni, creare le live utili per la diagnostica anche di Windows ( c'è un apposito package list per questo detto : debian-forensics ) o accedere ai vari clouds (anche in questo caso troviamo una package list detta : ubuntu-cloud ) .

Una volta che abbiamo capito come funziona, il tutto diventa facile.

Aggiornamento

 

Xfce Forensics

Tra i packages a disposizione, c'è debian-forensics, una comoda distribuzione per l'analisi dei problemi del disco e altre cose divertenti.

Come variazione sul tema, anche per spiegare come agire nel caso non si voglia il file system codificato, realizzerò una xfce-forensics , facilmente applicabile ad ogni computer e utile per eseguire qualsiasi tipo di operazione di copia e controllo anche della rete.

Fino al Prompt

La procedura iniziale è esattamente la stessa, con il solito comando lb config che installa xfce :

# lb config -a i386 --binary-filesystem fat32 --distribution wheezy --debian-installer false --archive-areas "main contrib non-free" --package-lists xfce  --interactive shell -b hdd

e il conseguente :

lb build 

fino al famoso prompt.

Ciò che cambia è la lista dei pacchetti che per far le cose in grande diventa :

# apt-get install cryptsetup-bin encfs zenity icedove iceweasel enigmail ffmpeg vlc mplayer mozilla-plugin-gnash libreoffice evince cpufreqd firmware-linux-nonfree wicd xfce4-terminal python ext3grep galleta gpart wireshark tcpdump  grokevt memdump missidentify myrescue pasco reglookup scrounge-ntfs sleuthkit ssdeep tableau-parm unhide wipe aesfix aeskeyfind afflib-tools chaosreader ed2k-hash guymager ewf-tools libguytools2 libphash0 md5deep nasty pipebench recoverdm rifiuti rifiuti2 safecopy shed drbl parted gparted sleuthkit system-tools-backends nfdump-flow-tools dff dcfldd autopsy dc3dd scalpel vinetto hfsplus iproute iptables nmap iptraf discover harden-remoteaudit doscan ssh

così dovrebbe bastare  ;)  per un buon rescue-disk, utile in caso di backup e crash di sistema, anche per andare ad indagare sulle possibili cause e recuperare dati fisicamente dal disco.

Unencrypted File System

Nel caso della xfce-forensics e in molti altri casi, è scomodo dover inserire la password all'inizio, specie se si tratta di una chiavetta diagnostica, dove la partizione in più ci serve solo per comodità e non per tenerci dati privati.

Dunque la scelta più ovvia è non usare il cryptosetup , infatti nella lista dei pacchetti c'è solo la versione bin che ci serve per accedere ai dati, senza gli script di partenza e la procedura ovviamente cambia.

Infatti qui non abbiamo più la /etc/crypttab che di fatto costruiva un device virtuale sul nostro device fisico, ma agiamo direttamente su /etc/fstab indicando il device fisico  :

/etc/fstab :

UUID=<UUID>  /ext   ext2    noatime  0       1

a questo punto, alla fine della procedura quando creeremo il file system ext2, invece di usare cryptosetup format .... ,  andremo direttamente a creare il file system con il codice UUID corretto in questo modo :

# mkfs.ext2 <device>2 -U "<UUID>"

Con questo trucco, analogamente a come accadeva prima, alla ripartenza il sistema cercherà il device in base all'UUID e lo monterà in automatico di conseguenza, solo che questa volta non dovrà essere prima decifrato e non sarà richiesta alcuna password.

Due parole finali sull'UUID

È importante comprendere l'importanza dell'UUID, che spiega anche il motivo della sua introduzione nel mondo Linux, avvenuta col proliferare di dischi e unità aggiuntive.

Se usassimo il device fisico in base alle caratteristiche del portatile su cui andiamo ad inserire la chiavetta, ad esempio /dev/sdb , ci troveremmo in serie difficoltà non solo su altre macchine con un numero di dischi diverso, ma anche sullo stesso portatile, aggiungendo per esempio temporaneamente un disco esterno USB che ci va ad occupare sdb. Sia chiaro che esistono metodi alternativi, tipo andare a vedere dalla mtab il device fisico della chiavetta ma questo è per me un buon sistema, anche perché fa tutto in automatico.

Nel caso del file system codificato, il sistema è anche piuttosto sicuro, visto che l'eventuale spoofing, dell'UUID del disco richiederebbe anche di conoscere la password del volume che l'utente sta inserendo, mentre nel caso di un file system in chiaro è relativamente facile ma non serve a nulla, dato l'utilizzo dell'oggetto in se.