Menu
EtoileAbonnementRSS
jeuxvideo.com  /  Tous les forums  /  Forum principal Informatique  /  Forum Linux  / 

Topic LVM Chiffré et RAM ?

Sujet résolu : LVM Chiffré et RAM ?

12
Page suivanteFin
[Soft]Ware
[Soft]Ware
MP
15 septembre 2020 à 19:52:42

Salut :ok:

Contexte :
J'ai un serveur qui tourne sous FreeNAS et qui permet d'héberger des machines virtuelles (hyperviseur Bhyve).
Je voulais installer un petit Debian Buster 10.5 pour faire des petits tests.
J'ai mis 768Mo de RAM au début (pour éviter l'installation en low memory mod qui est assez chiant, en attendant de mettre du SWAP), et je voulais baisser ensuite à 384Mo (je suis pas sûr que ce soit vraiment une bonne idée mais je voulais au moins essayer). :ok:

Pour le partitionnement, j'ai choisi du LVM Chiffré.
ça s'installe, ça boot, tout va bien.
Un petit reboot, il me demande ma passphrase pour débloquer le volume, ça passe, tout va bien.

Je shutdown, et je baisse la RAM à 384Mo.

Je redémarre, et là, surprise, ma passphrase est incorrecte ! Je suis pourtant sûr à 100% de ce que j'ai mis.

Je rééteins, je repasse la RAM à 768Mo, je redémarre, rentre ma passphrase et là ça fonctionne !

J'ai réessayé une 2eme fois pour être sûr :hap:
Et bien sûr, changer de quantité de RAM est quelque chose que j'ai déjà fait sans problème auparavant, mais sans LVM.

Et donc quoi, j'imagine que la quantité de RAM est utilisée dans le calcul du hashé du mot de passe :( :question:

Comment est gérée la passphrase par LVM ? J'imagine que ce n'est pas le PAM puisque c'est avant le démarrage du système :(

En soi j'ai pas de vrai problème, je peux refaire mon installation en mode low memory, ou même à la limite laisser 768Mo... Mais j'aimerais comprendre :hap:

Donc si y'en a qui savent des choses... Je vous écoute :ok:

:merci:

LornMalvo
LornMalvo
MP
16 septembre 2020 à 13:05:31

Et donc quoi, j'imagine que la quantité de RAM est utilisée dans le calcul du hashé du mot de passe :( :question:

Normalement non, ça n'a rien à voir avec la mémoire vive, mais je me trompe peut-être.

Alors, truc tout bête, qui m'est déjà arrivé, le clavier était passé en QWERTY, donc mot de passe incorrect.

Sinon avec cryptsetup, tu as essayé de changer la passphrase ?

Message édité le 16 septembre 2020 à 13:07:57 par LornMalvo
[Soft]Ware
[Soft]Ware
MP
16 septembre 2020 à 14:23:25

Alors, truc tout bête, qui m'est déjà arrivé, le clavier était passé en QWERTY, donc mot de passe incorrect.

Non, c'est pas ça le problème.
Enfin, oui le clavier est effectivement en QWERTY, mais ça je le savais déjà, et j'ai testé en QWERTY comme en AZERTY, le problème reste le même.
Et de toute façon, avec la quantité de RAM originale, ça fonctionne.

Sinon avec cryptsetup, tu as essayé de changer la passphrase ?

Je peux pas le faire quand j'ai 384Mo de RAM puisque je peux pas accéder au système, le disque étant chiffré... :(
Mais avec les 768Mo de RAM, donc quand ça fonctionne, oui j'ai effectivement essayé de changer la passphrase. J'ai mis un truc tout simple sans chiffre ni caractères spéciaux et qui s'écrit de la même façon en AZERTY ou en QWERTY. Même résultat.

[Soft]Ware
[Soft]Ware
MP
16 septembre 2020 à 14:46:37

Ah par contre j'ai essayé avec 512Mo de RAM et j'ai un résultat différent :
https://image.noelshack.com/fichiers/2020/38/3/1600259196-76743fdcc7d7acfe8b933b843376a1c3.png

Là il me dit plus seulement que le mot de passe est incorrect, mais aussi que j'ai pas assez de RAM !
C'est quand même ballot que j'ai pas ce message avec 384Mo de RAM :hap: J'imagine qu'il n'avait pas assez de RAM pour me prévenir qu'il n'avait pas assez de RAM... :rire:

La config minimale annoncée pour Debian demande pourtant 128Mo de RAM (sans interface graphique), mais c'est sans doute sans LVM et/ou sans chiffrement :(

Par ailleurs je me rends compte que le SWAP ne peut pas être utilisé à ce moment là, puisque la partition de SWAP a été créée par l'assistant à l'installation en LVM, donc c'est dans la partition chiffrée, donc tant que c'est pas déchiffré, le SWAP n'est logiquement pas accessible :hap:

Du coup j'imagine que je devrais faire une partition LVM d'un côté qui serait elle chiffrée, et à côté une partition SWAP plus classique :(

[Soft]Ware
[Soft]Ware
MP
16 septembre 2020 à 14:55:21

D'ailleurs j'avais pas fait gaffe mais j'étais allé voir la config minimale de Debian Jessie :hap:

Pour Debian Buster, c'est 256Mo le minimum
https://www.debian.org/releases/buster/amd64/ch03s04.fr.html

Donc je suis pas si large que ça :(

[Soft]Ware
[Soft]Ware
MP
16 septembre 2020 à 15:36:31

Du coup je suis bloqué :
https://www.noelshack.com/2020-38-3-1600263263-2abe6d8a6ebd905c67c550610bcc5718.png

Je peux pas créer de SWAP à l'extérieur du volume chiffré, et effectivement c'est logique, ça a beau jouer le rôle de RAM, ça reste de l'espace disque, donc non effacé à l'extinction de la machine :(

Donc ou bien je fais une machine avec un peu plus de RAM, ou bien je ne chiffre pas mon disque :(

godrik
godrik
MP
16 septembre 2020 à 17:06:40

tu pourrais envisager avoir une swap pour booter et changer de swap une fois LVM initialise. Ca te permettrait de remettre a 0 la swap non chiffre.
La machine sous freenas est a toi? Si oui, ca pourrait etre plus simple de laisser freenas s'occuper du chiffrement et laisser la VM debian avec un LVM non chiffree.

[Soft]Ware
[Soft]Ware
MP
17 septembre 2020 à 22:37:51

tu pourrais envisager avoir une swap pour booter et changer de swap une fois LVM initialise. Ca te permettrait de remettre a 0 la swap non chiffre.

Ah ouais ? Tu connais la procédure à suivre ? Parce que là je vois pas bien :(

J'ai tenté une nouvelle installation (avec 384MB de RAM) :
https://www.noelshack.com/2020-38-4-1600371726-57690977927892263612ca66c399d28a.png

Pas moyen de continuer, il refuse d'utiliser ma partition SWAP non chiffrée.
Si je supprime la partition SWAP on connaît la suite, il ne pourra pas démarrer (pas assez de RAM pour déchiffrer).

Du coup j'ai relancé l'installation mais avec 768MB de RAM, j'ai fait tout pareil que le screen précédent, mais je n'ai pas activée le swap non chiffré (la partition existe mais non utilisée).

Donc ensuite l'idée c'est de créer une partition swap dans la partition vide (jusque là ça devrait aller), et ensuite de faire un changement automatique du swap au démarrage... Et là je suis pas trop sûr de comment faire ?!

La création de la partition swap avec mkswap ok c'est facile.

Ensuite je dois ajouter ce nouveau swap dans le fstab. Je prends la ligne correspondante au swap déjà existant et je change juste le chemin de la partition.

Maintenant je redémarre, sans toucher à la RAM. Ça démarre normalement, le disque est correctement déchiffré. Je vois bien que mes 2 partitions SWAP sont activées.

Maintenant j'éteins, je diminue la RAM, et redémarre. Eh bien j'ai à nouveau le même problème, il refuse de déchiffrer la partition. J'imagine que le swap non chiffré n'est pas encore monté. Mais je ne sais pas comment lui spécifier de le monter en premier ?
Voici mon fstab :

/dev/sda3 none            swap    sw,pri=9              0       0
/dev/mapper/DebianCA--vg-LVM_root /               ext4    errors=remount-ro 0       1
UUID=6e16892a-6307-4c58-af4c-bc44fa0abb16 /boot           ext2    defaults        0       2
UUID=977C-9529  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/DebianCA--vg-LVM_swap none            swap    sw,pri=-2              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

La seule chose que j'ai modifié c'est la première ligne ainsi que l'option pri=x pour les deux swap. Mais je ne suis pas sûr de comprendre l'intérêt de cette option ? Elle n'apparaît pas dans le manuel fstab.
Mais je retrouve ces priorités avec la commande swapon -s. J'imagine que c'est la priorité d'utilisation des partitions lorsque des données sont mises en swap, et rien à voir avec le fstab ?
Alors comment je lui spécifie de monter mon swap non chiffré en premier ? Est-ce que c'est ne serais-ce que possible ?

Et puis ensuite, comment je désactive le SWAP non chiffré une fois le système démarré ?
swapoff devrait être la solution, mais je ne vois rien dans le man qui me garantisse que la partition sera effacée ?
Et à quel moment je devrais exécuter cette commande ? Il faudrait le faire le plus tôt possible, mais après le déchiffrement de la partition bien sûr :( A quel endroit du système je devrais spécifier ça ?

La machine sous freenas est a toi? Si oui, ca pourrait etre plus simple de laisser freenas s'occuper du chiffrement et laisser la VM debian avec un LVM non chiffree.

Oui c'est à moi.
Mais j'ai pas de réelle utilité à chiffrer ça, y'aura rien d'important dessus.
Le but c'est surtout de maîtriser au mieux Debian, faut juste voir ça comme un exercice :oui:

godrik
godrik
MP
18 septembre 2020 à 01:40:30

J'ai envie de dire que je ferais comme partout. Je rajouterais deux targets dans le boot sequence. Un qui monte la swap non chiffre et qui vient avant le montage lvm dans la sequence de boot, et un qui swapoff et qui vient apres le montage de la swap plus grosse.

Mais fondamentalement, je pense qu'il te faut plus de RAM pour faire du LVM chiffre.

J'imagine que tu as vu l'option --pbkdf-memory de crypt-setup?

[Soft]Ware
[Soft]Ware
MP
20 septembre 2020 à 18:34:07

Ouais, le fstab c'était pas une super idée, puisqu'il se trouve dans la partition chiffrée... :hap:
Donc effectivement ça change rien et c'est totalement logique.

Alors le boot sequence pour le coup je maîtrise pas du tout, du tout, du tout... :hap:
Bon logiquement je vais devoir travailler dans le /boot qui est la seule partition non chiffrée, et qui contient justement le boot sequence si je ne m'abuse. Et plus précisément c'est le grub que je devrais personnaliser :(
Pour le moment je sais pas encore comment je vais faire ça, j'ai pas trop trouvée de documentation satisfaisante :( (mais j'ai encore que peu cherché).

Ouais ouais, plus de RAM ça j'ai bien compris :hap: J'aimerais bien réussir ce petit défi quand même :rire:

Et non j'ai pas du tout vu cette option de cryptsetup !
Mais alors qu'est-ce que ça change fondamentalement ? L'utilisation CPU sera plus importante pour déchiffrer tout ça, et donc un temps de déchiffrement plus élevé, mais c'est tout ? Pas de dégradation du chiffrement ?
Mais s'il n'y a pas de dégradation du chiffrement, alors pourquoi la fonction ne s'adapte pas directement à la quantité de mémoire disponible ?

godrik
godrik
MP
20 septembre 2020 à 22:14:09

En vrai, je ne sais pas. Ke n'ai jamais regarde comment crypt_setup fonctionne. Mais j'ai vu dans plusieurs article que par default l'encryption utilise par default brule en gros 500MB de ram. Ca a l'air consistent avec le probleme que tu as.

Et en effet, je pense que reduire l'espace de pdkdf utilise va diminuer la securite de l'encyption obtenu. Il faudrait regarder ce que fait le systeme plus en detail pour pouvoir savoir quoi faire. J'ai l'impression en lisant ca ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924560 ) que crypt-setup se configure en fonction de l'espace memoire disponible a l'installation.

L1-Heisenberg
L1-Heisenberg
MP
20 septembre 2020 à 23:33:28

Si ton cryptsetup utilise par défaut luks2, ton algo de dérivation de clé est sûrement argon2id (et il a un besoin en RAM défini au moment de la création du volume, déterminé automatiquement en fonction de la RAM installée)

Grey-Kangaroo
Grey-Kangaroo
MP
21 septembre 2020 à 19:36:46

Salut.

Pourquoi tu ne chiffre pas ton serveur ou alors l'emplacement où sont stockés tes VMs ?

Cela me semble beaucoup plus simple comme approche... et au final cela empêchera d'accéder à tes données.

[Soft]Ware
[Soft]Ware
MP
27 septembre 2020 à 15:13:45

Bon j'ai plus de temps à y consacrer, je vais laisser avec 768Mo de RAM :noel:

Le 21 septembre 2020 à 19:36:46 Grey-Kangaroo a écrit :
Salut.

Pourquoi tu ne chiffre pas ton serveur ou alors l'emplacement où sont stockés tes VMs ?

Cela me semble beaucoup plus simple comme approche... et au final cela empêchera d'accéder à tes données.

C'est déjà chiffré :noel:
Mais le but c'est surtout la manipulation du truc, pas d'avoir réellement du chiffrement, parce que y'a rien d'important dessus finalement.

L1-Heisenberg
L1-Heisenberg
MP
27 septembre 2020 à 17:23:40

Le 27 septembre 2020 à 15:13:45 [Soft]Ware a écrit :
Bon j'ai plus de temps à y consacrer, je vais laisser avec 768Mo de RAM :noel:

Le 21 septembre 2020 à 19:36:46 Grey-Kangaroo a écrit :
Salut.

Pourquoi tu ne chiffre pas ton serveur ou alors l'emplacement où sont stockés tes VMs ?

Cela me semble beaucoup plus simple comme approche... et au final cela empêchera d'accéder à tes données.

C'est déjà chiffré :noel:
Mais le but c'est surtout la manipulation du truc, pas d'avoir réellement du chiffrement, parce que y'a rien d'important dessus finalement.

Je t'ai dit, si t'es en argon2id (ou n'importe quel algo de dérivation de clé qui utilise de la RAM) c'est normal et c'est à toi de le définir au moment de la création du volume ou en créant une nouvelle clé (cryptsetup luksDump /dev/sdxx pour check)

Sinon j'imagine que ça doit pas être trop compliqué de configurer ton initramfs pour swap sur une partition (non-encryptée du coup)

[Soft]Ware
[Soft]Ware
MP
27 septembre 2020 à 18:56:41

Bon bah problème résolu :fete:

sudo cryptsetup luksDump /dev/sda4

ça me donne des informations sur les algos utilisés, notamment :

Key:        512 bits
Priority:   normal
Cipher:     aes-xts-plain64
Cipher key: 512 bits
PBKDF:      argon2i
Time cost:  5
Memory:     375822
Threads:    1

Du coup j'ai utilisé cryptsetup-reencrypt
https://www.systutorials.com/docs/linux/man/8-cryptsetup-reencrypt/

J'ai monté le disque sur une autre machine, puisque forcément le volume ne doit pas être ouvert pour pouvoir travailler dessus (il est totalement verrouillé et inaccessible pendant l'opération).

Et puis j'ai refait le chiffrement :
sudo cryptsetup-reencrypt --pbkdf argon2id --pbkdf-memory 13107 /dev/sdb4
Donc il a écrit sur l'intégralité du volume, heureusement c'est que 7Go et sur SSD donc ça a pris à peine 3 minutes.

Si je refais la commande de toute à l'heure :

sudo cryptsetup luksDump /dev/sda4
Key:        512 bits
Priority:   normal
Cipher:     aes-xts-plain64
Cipher key: 512 bits
PBKDF:      argon2id
Time cost:  199
Memory:     13107
Threads:    1

On voit que la mémoire a été effectivement diminuée, par contre le coût en temps a été multiplié par presque 40... :rire:
Mais en pratique ça se voit pas vraiment, ça prend largement moins de 5 secondes :ok:

Et donc maintenant je peux reboot avec 384Mo de RAM et ça fonctionne très bien :content:

Message édité le 27 septembre 2020 à 19:00:24 par [Soft]Ware
bladelores
bladelores
MP
28 septembre 2020 à 08:29:45

Et y'avait pas besoin d'utiliser reencrypt tu pouvais juste utiliser un nouveau keyslot et supprimer l'ancien

[Soft]Ware
[Soft]Ware
MP
28 septembre 2020 à 15:31:10

Le 28 septembre 2020 à 08:29:45 bladelores a écrit :
Et y'avait pas besoin d'utiliser reencrypt tu pouvais juste utiliser un nouveau keyslot et supprimer l'ancien

Ouais, j'ai douté de ça, après avoir utilisé reencrypt... :hap:

godrik
godrik
MP
28 septembre 2020 à 17:03:13

Est ce que quelqu'un peut clarifier si le changement du montant de mémoire utilisée impacte la qualité du chiffrement?

bladelores
bladelores
MP
28 septembre 2020 à 18:45:56

Le 28 septembre 2020 à 17:03:13 godrik a écrit :
Est ce que quelqu'un peut clarifier si le changement du montant de mémoire utilisée impacte la qualité du chiffrement?

Oui, c'est un facteur parmi d'autres (parallélisme et time cost) qui aide à complexifier l'attaque par bruteforce par des ASICs

Du coup évidemment il suffit qu'un keyslot faible existe pour compromettre tout le chiffrement

12
Page suivanteFin
Répondre
Prévisu
?
Victime de harcèlement en ligne : comment réagir ?