Newsgroup: it.comp.os.linux.sys
Titolo: Cifrare disco con dati

Ciao a tutti,
Mi trovo nella situazione di dover cifrare questo disco:
 
########################################################
# fdisk -l
 
Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 93ECAF00-2F50-46CD-9141-C15EB4D5AE01
 
Device         Start       End   Sectors   Size Type
/dev/sda1       2048   1050623   1048576   512M EFI System
/dev/sda2    1050624 960442367 959391744 457,5G Linux filesystem
/dev/sda3  960442368 976771071  16328704   7,8G Linux swap
########################################################
Ovviamente la partizione 

Scusate l'invio di prima, ho appena scoperto che con pan ctrl+s invia 
anzichè salvare :D Dicevo...

Ovviamente la partizione da cifrare è /dev/sda2, formattata con ext4.
Devo per copiare tutto su un device esterno, cifrare, e poi ricopiare 
indietro? Oppure c'è qualche tool che fa tutto a caldo?
 
Avendo un unica partizione con dentro tutto (boot, grub, ecc) posso avere 
qualche tipo di problema?
 
La partizione EFI potrebbe darmi qualche rogna?
 
Grazie
g4b0

 La partizione EFI potrebbe darmi qualche rogna?
 
Non le da sempre?
 
In generale non credo sia semplice, ma e` possibile,
fare le cose "a caldo".
A braccio credo che sia necessario re-installare tutto,
ma, di nuovo, potrei sbagliarmi.
 
bye,
 
-- 
 
piergiorgio


/dev/sda2 e' la root partition per cui occorrono accorgimenti particolari
Visto che normalmente ha poco senso cifrare la root partition (anche se 
e' possibile) restringi la partizione,crei un altra partizione che la 
monti in /home e cifra quella
E' comunque sempre meglio tenere la /home separata dalla root
 

 meglio tenere la /home separata dalla root
 
Soluzione interessante. Anche perchè in effetti con qualche accorgimento 
riesco a portare l'utilizzo del disco < 50%, per cui dovrei riuscire a 
fare tutto senza movimentare troppi dati.
 
Faccio qualche prova con un mount point di test, poi passo alla home. 
 
Qualche suggerimento su come procedere, magari per far si che la dir 
venga decifrata in fase di login da Gnome? 
 
Ulteriore complicazione: ho due utenti sulla macchina, con relative pwd 
di accesso. Sarà possibile che entrambi riescano a decifrare?
 
Grazie

 ma, di nuovo, potrei sbagliarmi.
 
Provo a seguire la via suggerita da enoquick, in effetti avere la root 
cifrata non mi da alcun valore aggiunto. Già che ci sono vedo anche se ha 
senso splittare altre partizioni oltre alla /home
 
g4b0

 indietro? Oppure c'è qualche tool che fa tutto a caldo?
 
Essendo una partizione ext4, puoi provare questo:
 
https://wiki.archlinux.org/index.php/Ext4#Using_file-based_encryption
 
 
Enrico

 Visto che normalmente ha poco senso cifrare la root partition
 
I log in chiaro? Meglio spostarli in memoria in ambiente desktop ?
 
Parlo di eliminare ogni possibilita di risalire all'uso della macchina in caso di perdita/sottrazione.
 
Giulia
 

 
 
Dipende dal grado di sicurezza che si vuole ottenere
Se si lavora come agente segreto per la CIA o qualcun altro magari si 
vuole cifrare anche la root partition
Per un comune utente di solito basta proteggere  i propri dati,i log di 
sistema sono irrilevanti nel caso in cui vengano sottratti.
E' comunque sempre possibile fare una altra partizione (cifrata) e 
montarla in /var



La pwd della partizione criptata viene richiesta al mount ,quindi e' per 
tutti gli utenti
Se vuoi che ogni utente abbia la propria pwd di mount fai piu 
partizioni,una per ogni utente (ma a quel punto andrei su lvm per comodita)
 
 
 
Qui ha una guida (in italiano) per ubuntu,ma dovrebbe valere per 
qualunque distro
 
https://ubuntista.wordpress.com/2007/08/18/criptare-una-partizione-in-ubuntu/
 
 
 

 
https://ubuntista.wordpress.com/2007/08/18/criptare-una-partizione-in-
 
ubuntu/
 
Molto interessante, grazie per il link. Speravo che la passphrase fosse 
sostituibile con quella dell'utente di sistema, in modo da fare tutto al 
login, ma temo che non sia possibile... o forse si? Magari qualcosa di 
integrato con Gnome :)
 
g4b0


Molto interessante, però mi sa che non fa al mio caso:
 
"Once the encryption feature flag is enabled, kernels older than 4.1 will 
be unable to mount the filesystem."
 
# uname -a
Linux glaptop 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 
GNU/Linux
 
Grazie comunque
g4b0
 
P.S. 
È quasi ora di aggiornare sto laptop con Jessie...

 montarla in /var
 
Ma nel caso di più partizioni cifrate poi mi tocca mettere n password ad 
ogni boot?
 
g4b0

 ogni boot?
 
Sì. Di solito per ovviare si crea una partizione criptata, che poi viene usata
come PV per dei volumi LV
 
Enrico

 montarla in /var
 
...anche essere cosi`.
 
Resta il fatto che e` molto discutibile non avere
tutto, tranne /boot (ma magari anche quello), protetto.
 
Nel caso le condizioni siano piu` rilassate, si puo`
anche installare "ecryptfs" ed avere un folder,
tipicamente ~/Private, crittografato, dove si mettono
i file riservati.
 
Tra l'altro questo folder e` "sbloccato" dal password
utente ed e` diverso per ognuno.
 
bye,
 
-- 
 
piergiorgio

 In realtà vorrei solo essere un minimo compliant con il benedetto GDPR, 
 
Spiega questa cosa, perche` mi sfugge la connessione
tra "full disk encryption" e GDPR.
 
bye,
 
-- 
 
piergiorgio

 
 
Non è che ci sia una connessione diretta, ma nel caso di furto del laptop 
nella comunicazione obbligatoria del data breach fa la differenza dire 
che i dati sensibili ivi contenuti sono cifrati piuttosto che alla mercè 
di chicchessia. E forse anche eventuali sanzioni che prima o poi verranno 
tabellate potrebbero tenere conto della disk encryption, ma su questo non 
ci metterei la mano sul fuoco.
 
g4b0


A, ok. Buona idea. Ma una volta cifrata è possibile fare il resize di una 
partizione, oppure devo farmi bene i conti prima di procedere?
 
g4b0

 diverso per ognuno.
 
E questo è esattamente quello che mi servirebbe.
 
A livello di performance di sono grosse differenze tra ecryptfs ed i 
sistemi più a basso livello, tipo Cryptsetup-LUKS e e4crypt?
 

 ci metterei la mano sul fuoco.
 
Si, ma se hai un kernel 3.x, allora solo i possibili
bug si sicurezza *non* sistemati potrebbero rendere
invalido il ragionamento...
 
bye,
 
-- 
 
piergiorgio

 sistemi più a basso livello, tipo Cryptsetup-LUKS e e4crypt?
 
Ti preoccupi delle performance?
 
Se la CPU non ha istruzioni AES-NI, si arriva a
qualche decina di MB/sec o meno, in ogni caso.
 
Testano con Celeron qualcosa, senza AES-NI e SSD.
 
Senza LUKS, va quasi al massimo dell'interfaccia,
cioe` circa 250MB/sec, con LUKS va a circa 80MB/sec.
 
La differenza in prestazioni, tra LUKS e ecryptfs,
la vedrei soprattutto perche` con LUKS *tutto* deve
essere de-crittografato, ma con ecryptfs solo i file
protetti.
 
Tieni anche presente, pero`, che ecryptfs potrebbe
essere un po' debole sui metadati.
Nomi dei file, dimensione e date forse sono ancora
leggibili, non so se sia grave, questo.
 
Un'alternativa, poco testata, e` "CryFS", che e`
pensato per servizi cloud, ma funziona anche da solo.
 
bye,
 
-- 
 
piergiorgio


 
Ciao, 
confermo, anch'io ho letto la stessa cosa quando ho fatto il mio notebook.
Si dovrebbe poter arrivare fino a 8. Sarebbe bello poter fare l'unlock con 
il fingerprint reader o con una Yubikey.
 
Il mio layout al momento è questo:
 
sda               8:0    0 119,2G  0 disk  
├─sda1            8:1    0   487M  0 part  /boot/efi
├─sda2            8:2    0   954M  0 part  /boot
└─sda4            8:4    0  99,2G  0 part  
  └─sda4_crypt  254:0    0  99,2G  0 crypt 
      ├─VG01-LV01 254:1    0  38,1G  0 lvm   /
      └─VG01-SWAP 254:2    0    20G  0 lvm   [SWAP]
 
 
  --- Logical volume ---
    LV Path                /dev/VG01/LV01
    LV Name                LV01
    VG Name                VG01
    LV UUID                4UNzr8-ABG5-ke4i-0r7H-o9Rw-i9Xz-iNUxYK
    LV Write Access        read/write
    LV Creation host, time kotohira, 2017-12-21 00:41:13 +0100
    LV Status              available
    # open                 1
    LV Size                38,14 GiB
    Current LE             9765
    Segments               1
    Allocation             inherit
    Read ahead sectors     auto
    - currently set to     256
    Block device           254:1
 
  --- Logical volume ---
    LV Path                
    /dev/VG01/SWAP
    LV Name                SWAP
    VG Name                VG01
    LV UUID                Ak0Ufh-AgSt-QV4L-859D-b2LJ-s7fM-fYBqRD
    LV Write Access        read/write
    LV Creation host, time kotohira, 2017-12-27 11:00:38 +0100
    LV Status              available
    # open                 2
    LV Size                20,00 GiB
    Current LE             5120
    Segments               1
    Allocation             inherit
    Read ahead sectors     auto
    - currently set to     256
    Block device           254:2
 
Ciao
 
-- 
SysAdmin


Ti riferisci a qualcosa che potrebbe rendere decifrabile un'eventuale 
partizione cifrata oppure a vulnerabilità sfruttabili da remoto mentre la 
partizione è decifrata?
 
Se hai qualche link approfondisco volentieri...
 
g4b0

 cloud, ma funziona anche da solo.
 
Provo a dargli un'occhiata, grazie
 
g4b0

 Se hai qualche link approfondisco volentieri...
 
Non ho link al riguardo, non servono, basta
fare un ragionamento induttivo.
 
Vi sono parecchi bug di sicurezza che sono
stati sistemati nel corso dello sviluppo del
kernel (spectre?).
Alcuni hanno avuto back porting, non saprei,
pero`, fino a che versione.
Altri no e lo stesso vale per tutti i componenti
del sistema.
 
Quindi puo` facilmente essere che vi siano dei
problemi di sicurezza, nel kernel o nei componenti
che stanno attorno, le cui soluzioni sono presenti
solo in kernel, o componenti, successivi alla
versione che stai usando.
 
E` il motivo per cui si raccomanda sempre di tenere
il sistema up to date.
 
bye,
 
-- 
 
piergiorgio

 file, a patto di avere a disposizione la versione decifrata?
 
Eh?
 
No, il problema e` che se hai un file che si chiama
"dichiarazione_740_di_Mario_Rossi.pdf", questo gia`
fornisce un informazione al riguardo.
 
Non e` questione di brute force, che si applica anche
con LUKS, e` questione che varie informazioni possono
essere passate dai metadati.
 
Che questo, ripeto, sia grave o meno e` da vedersi.
 
bye,
 
-- 
 
piergiorgio

 questione che varie informazioni possono essere passate dai metadati.
 
Ecco, ma nel caso di LUKS credo che un brute force sia più oneroso 
proprio per quanto detto prima, o sbaglio?
 
g4b0
 
P.S.
Comunque non credo che nessuno sia intenzionato a perdere del tempo 
facendo brute force sui miei dati, dal punto di vista del GDPR basta 
dichiarare di avere il disco cifrato e dormo sonni tranquilli. Almeno 
questo è quanto ci ha detto il consulente pagato profumatamente, io 
personalmente mi sono disinteressato delle questioni prettamente legali.

 partizione, oppure devo farmi bene i conti prima di procedere?
 
Nì. I volumi LVM li ridimensioni senza problemi, come li ridimensioneresti se
fossero normali LV in chiaro. Il PV, essendo criptato, richiede un po' più di
lavoro, ma si ridimensiona anche lui
 
Enrico


Tnx

 date.
 
Chiaro. Però vale anche sempre la regola di non toccare quello che 
funziona!
 
Comunque ho colto la palla al balzo ed ho notato che per Jessie è 
disponibile la versione 4.17, semplicemente l'upgrade era bloccato da 
qualche preference di apt.
 
# uname -a
Linux glaptop 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 
GNU/Linux
 
Ed ora mi funziona anche il bluetooth =D
 
g4b0
 

 dove si mettono i file riservati.
 
Sto testando ecryptfs, ma mi si schianta... Ho già googlato, ma non trovo 
nessuno che abbia avuto lo stesso problema. Sembra che non riesca a 
scrivere in /dev/shm
 
# ls -ld /dev/shm
drwxrwxrwt 2 root root 360 lug 31 10:03 /dev/shm
 
 
# ecryptfs-migrate-home -u test
INFO:  Checking disk space, this may take a few moments.  Please be 
patient.
INFO:  Checking for open files in /home/test
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/
gvfs
      Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1001/
gvfs
      Output information may be incomplete.
Enter your login passphrase [test]: 
 
************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION.
  ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************
 
 
Done configuring.
 
chown: impossibile accedere a "/dev/shm/.ecryptfs-test": File o directory 
non esistente
mount: mount(2) failed: File o directory non esistente
ERROR:  Could not mount
 
 
 
Qualche suggerimento?
 
g4b0

 Ed ora mi funziona anche il bluetooth =D
 
Il che, paradossalmente, apre un buco di sicurezza... :-)
 
Ad ogni modo, se il sistema e` aggiornato, se fare LUKS e`
troppo complicato, allora credo l'unica soluzione sia un
uso cauto e coscienzioso di ecryptfs.
 
bye,
 
-- 
 
piergiorgio

 Qualche suggerimento?
 
Tu riesci a scrivere in /dev/shm come utente normale?
 
Tipo "echo 1234 > /dev/shm/test"?
 
bye,
 
-- 
 
piergiorgio

 personalmente mi sono disinteressato delle questioni prettamente legali.
 
Secondo me tu sei troppo rilassato su questa cosa.
 
La sicurezza del sistema non dipende per niente
dal fatto che sia crittografato il disco, ma da
tutta una serie di altri fattori di contorno.
 
Se la password e` "password" e viene beccata subito,
non credo che dire "il disco era crittografato" possa
salvare da una causa (qualora vi siano gli estremi e
la voglia, chiaramente).
 
Chiaro, dipende dalla voglia di rompere le scatole
che terzi parti avranno, nel caso succedano problemi.
 
bye,
 
-- 
 
piergiorgio

 non esistente
 
Tra l'altro, da me e` "/dev/shm/ecryptfs-test", cioe`
senza punto iniziale...
 
bye,
 
-- 
 
piergiorgio

 avranno, nel caso succedano problemi.
 
Ovvio. Ad oggi sul sito del garante per la privacy non sono ben chiari 
gli strumenti in mano al cittadino per rompere le balle a chi amministra 
i suoi dati. Però sto GDPR una cosa l'ha ottenuta, almeno per me: sono 
diminuite enormemente le chiamate dei rompiballe che volevano vendermi 
qualcosa, Vodafone in primis, che mi mandava circa 3-4 sms alla settimana 
da anni. Che forse non avessero tutto sto diritto di spammarmi?
 
g4b0

 
 
Si, anche se ecryptfs-migrate-home lo lancio da root con l'utente test 
non connesso, per cui non dovrebbe essere quello il problema. 
 
$ echo 1234 > /dev/shm/test
$ more /dev/shm/test 
1234
 
Potrebbe essere un problema il fatto che faccio il tutto da una shell 
all'interno di Gnome? Non so proprio che pesci pigliare, ho seguito alla 
lettera questo link [1], ma non funziona...
 
g4b0
 
 
[1] 
https://wiki.debian.org/TransparentEncryptionForHomeFolder
 
 

 
 
Che strano! Che versione di ecryptfs? SO? Io sono su una jessie con 
questo sw:
 
$ dpkg -l | grep ecryptfs
ii  ecryptfs-utils   103-5+deb8u1   amd64   ecryptfs cryptographic 
filesystem (utilities)
$ uname -a
Linux glaptop 4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 
GNU/Linux
 
g4b0

 coscienzioso di ecryptfs.
 
Credo anche io, ad oggi non posso permettermi di avere un sistema che non 
bostrappa. Anche perchè su questa macchina per qualche strano motivo non 
si riesce ad accedere al BIOS....
 
Indago ulteriormente su ecryptfs, magari partendo da quel sotto-thread in 
cui ne discutiamo.
 
g4b0
 
P.S.
Grazie per l'aiuto ed anche per la discussione, era un po' che su USENET 
non partecipavo a "tutto sto movimento" :)
 
 
 

 GNU/Linux
 
Linux lazy.lzy 4.17.9-200.fc28.x86_64 #1 SMP Mon Jul 23 21:41:29 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
 
bye,
 
-- 
 
piergiorgio

 noioso motivo dei bug fix... :-)
 
Infatti pinnando da stretch il pacchetto ecryptfs-utils ho risolto, 
l'utente 'test' ha la home cifrata :)
 
Grazie mille, ora cerco di risolvere i nuovi problemi di pinning 
introdotti...
 
g4b0
 


Ok, tutto risolto, l'utente di test funziona. Mi resta un dubbio prima di 
incasinare tutto: ho due utenti con relative home directory di 142Gb e 
77Gb. Quanto ci può mettere spannometricamente a cifrare il tutto?
 
E poi quando farò login quanto ci metterà a decifrare? Il sistema gira 
con un i5 quad core con AES, 8Gb di ram e disco SSD.
 
Non vorrei trovarmi con una macchina da aspettare 1/2 ora tutte le 
mattine al boot.
 
Ed infine: nel caso in cui rallentasse troppo, si può tornare indietro? O 
devo piallare gli utenti e crearne di nuovi, per poi recuperare tutto dal 
backup?

 mattine al boot.
 
Non so come funzioni per la crittazione fatta in seguito. Io ho il disco 
crittato dall'installazione, e al boot, a parte dover mettere la 
password di crittazione, non c'è nessun rallentamento.
 
La crittazione avviene al volo quando leggi e scrivi, e con un i5 non te 
ne accrogi nemmeno.
 
È la mia macchina di sviluppo principale, e compilo di continuo senza 
rallentamenti visibili.
 
Bye.
 


Grazie per l'info. Hai usato ecryptfs o altro?
 
g4b0
 

 Grazie per l'info. Hai usato ecryptfs o altro?
 
Onestamente non lo so, e in questo momento non ho il PC in questione 
sotto mano. Mi pare di sì. È l'installazione di default di Ubuntu.
 
Bye.
 

 /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
lrwxrwxrwx 1 test test 52 ago  2 08:57 README.txt -> /usr/share/ecryptfs-
utils/ecryptfs-mount-private.txt
 
 
g4b0

 decifrati tutti alla login?
 
La chiave di criptazione (? boh "crittazione") e`
crittografata con la password dell'utente.
 
Quindi, a meno di bug, solo conoscendo questa
si possono de-criptare i file.
Al login, c'e` un modulo PAM che usa la password
per de-criptare la chiave e montare $HOME oppure
~/Private o quello che e`.
 
Tra l'altro, se root cambia la password dell'utente,
comunque non puo` leggere i dati, perche` bisogna
sempre avere la prima, per cambiare la chiave con
la seconda.
 
bye,
 
-- 
 
piergiorgio