Vous n'êtes pas identifié(e).
A quel moment exactement ? Le seul moment critique, c'est lors de la saisie de la passphrase de chiffrement.
Au moment où l'installateur copie des données aléatoires
Après l'avoir fait deux trois fois, sauter cette étape (facultative et inutile si deja fait non ?) m'a permis d'être plus détendu dans mes tatonnements, vu que je perdais moins de temps à chaque essai de nouveau schéma de partition !
Dernière modification par Maknho (06-06-2020 08:19:07)
Hors ligne
Raleur remarquera que je continue de mal nommer les volumes
En effet. Pas besoin de mettre GV ou VL dans les noms des VG et LV, ni de répéter le nom du VG dans les noms des LV.
/dev/TJP/home ou /dev/mapper/TJP-home (ce sont des alias), tu ne trouves pas que ce serait mieux (plus court et plus lisible) que /dev/GV_TJP/VL_home_TJP ou /dev/mapper/GV_TJP-VL_home_TJP ?
Je trouve aussi que tu n'as pas laissé beaucoup d'espace libre dans le VG (40 Go sur 1 To).
j'ai utilisé les commandes pvscan et lvscan mais est-ce qu'il y aurait une commande plus large me permettant de voir aussi les deux partitions non chiffrés (/boot et EFI) ?
Une vue synthétique de tous les périphériques bloc (disques, partitions, volumes logiques...) peut être affichée par lsblk.
Au moment où l'installateur copie des données aléatoires
Alors le seul effet de la frappe clavier est d'augmenter l'entropie du système, qui est utilisée pour générer des nombres aléatoires.
Il vaut mieux montrer que raconter.
Hors ligne
tient il y a vgrename et lvrename
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
En ligne
Il vaut mieux montrer que raconter.
Hors ligne
Une vue synthétique de tous les périphériques bloc (disques, partitions, volumes logiques...) peut être affichée par lsblk.
Oui c'est effectivement une vue comme cela que je recherchais : Thxs !
Résultat concernant mon HDD 1TO :
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 571M 0 part /boot/efi
├─sda2 8:2 0 764M 0 part /boot
└─sda3 8:3 0 930,2G 0 part
└─sda3_crypt 254:0 0 930,2G 0 crypt
├─GV_TJP-VL_swap_TJP 254:1 0 7,5G 0 lvm [SWAP]
├─GV_TJP-VL_root_TJP 254:2 0 139,7G 0 lvm /
└─GV_TJP-VL_home_TJP 254:3 0 745,1G 0 lvm /home
sr0 11:0 1 1024M 0 rom
Mais systemd risque de ne pas aimer lors de l'arrêt, quand il va vouloir arrêter les unités .mount et .swap qu'il a créées automatiquement avec les anciens noms des volumes.
Bon je garde mes noms de volume alors s'il n'y a pas de limite de longueur (comme dans windows où arrive vite le "nom de fichier trop long") et que le seul désagrément est la lisibilité ?
Je trouve aussi que tu n'as pas laissé beaucoup d'espace libre dans le VG (40 Go sur 1 To).
C'est peu, en effet. Mais je garde toujours l'avantage que tu indiquais dans un autre post ("tant qu'il y a de l'espace libre dans le VG qu'on peut agrandir en ajoutant une partition, un disque…" cf https://debian-facile.org/doc:systeme:lvm) si j'ajoute des disques durs, n'est-ce pas ?
Alors le seul effet de la frappe clavier est d'augmenter l'entropie du système, qui est utilisée pour générer des nombres aléatoires.
Je pensais que cet étape était une étape d'écriture de données aléatoires, préalable au chiffrement, afin d'être bien certain qu'il soit impossible, d'une manière ou d'une autre, de récupérer des vieilles données (effacées mais toujours présentes sur le disque).
Et donc je me disais qu'à force d'installer et de réinstaller depuis deux jours et après avoir fait 3 fois cette étape d'inscription de données aléatoire intégralement, je pouvais à la 4ème, 5ème...etc. réinstallations me passer de cette étape mes veilles données n'étant plus là depuis longtemps.
Mais peut-être que je me trompe (encore ) ?
"Augmenter l'entropie du système" => est-ce que tu pourrais raleur expliciter un peu, s'il-te-plait ?
"qui est utilisée pour générer des nombres aléatoires" => les nombres aléatoires qui seront écrits sur le disque à chiffrer pour être sûr qu'il n'y ait plus de vieilles données (un peu comme le logiciel eraser sur windows ?)
Hors ligne
Bon je garde mes noms de volume alors s'il n'y a pas de limite de longueur
Il doit bien y avoir une limite de longueur mais je ne la connais pas et tu dois en être loin. C'est juste une question de lisibilité (je trouve que c'est important, c'est pourquoi j'ai insisté).
tant qu'il y a de l'espace libre dans le VG qu'on peut agrandir en ajoutant une partition, un disque…
En principe, oui. Mais d'une part c'est dommage de devoir agrandir le VG, surtout en ajoutant un disque (composant matériel : encombrement, consommation, dissipation thermique, risque de panne...), juste parce que tu as alloué trop d'espace à un des volumes au détriment d'un autre.
D'autre part, le chiffrement complique les choses. Logiquement, le PV supplémentaire doit être chiffré lui aussi, avec une passphrase. Comme le VG contient la racine et le swap, il doit être activé par l'initramfs (la partie du système chargée par GRUB immédiatement après le noyau et responsable de la reprise après hibernation et du montage de la racine). L'initramfs demandera de taper les passhprases des deux volumes chiffrés, même si elles sont identiques. Pas très pratique.
Pour éviter ce désagrément, une solution parmi d'autres consiste à faire un "sandwitch" (empilement) LVM-chiffrement-LVM. Mais il faut le prévoir à l'installation. Le principe est le suivant :
- La première couche LVM utilise des partitions ou disques non chiffrés comme PV et contient un volume logique qui occupe tout l'espace du VG. Ce LV est utilisé pour créer un volume chiffré. Le volume chiffré résultant est utilisé comme PV par un second VG qui contient les LV "normaux" (racine, swap, home...).
- Pour agrandir l'espace disponible on ajoute un PV au VG non chiffré (vgextend), on agrandit le LV non chiffré (lvextend) puis le volume chiffré résultant (cryptsetup resize) et enfin le PV qu'il contient (pvresize), ce qui ajoute l'espace supplémentaire au VG chiffré.
Je pensais que cet étape était une étape d'écriture de données aléatoires, préalable au chiffrement, afin d'être bien certain qu'il soit impossible, d'une manière ou d'une autre, de récupérer des vieilles données (effacées mais toujours présentes sur le disque).
Oui, mais ce n'est pas le seul but de cette opération, sinon on pourrait aussi bien se contenter d'écrire des zéros au lieu de données aléatoires.
L'autre but est de rendre les blocs dans lesquels des données chiffrées ont été écrites indiscernables des autres (ce qui permettrait à un attaquant de se concentrer sur eux). C'est un peu comme les protocoles de transmission sécurisés qui transmettent des données aléatoires quand il n'y a pas de données chiffrées à transmettre, afin qu'un observateur ne puisse même pas savoir quand des données chiffrées sont transmises.
Et donc je me disais qu'à force d'installer et de réinstaller depuis deux jours et après avoir fait 3 fois cette étape d'inscription de données aléatoire intégralement, je pouvais à la 4ème, 5ème...etc. réinstallations me passer de cette étape mes veilles données n'étant plus là depuis longtemps.
Après la première écriture Il ne reste plus de données non chiffrées mais il peut rester l'en-tête LUKS d'un volume chiffrés créé par la suite. Cet en-tête contient la clé de chiffrement (elle-même chiffrée) du volume chiffré, qui pourrait potentiellement permettre de déchiffrer d'anciennes données chiffrées non effacées. Dans ton cas ce n'est pas bien gênant puisque tu n'as fait que des installations successives sans stocker de données. En toute rigueur il faudrait donc au moins effacer le début de la partition chiffrée qui contient l'en-tête LUKS.
"Augmenter l'entropie du système" => est-ce que tu pourrais raleur expliciter un peu, s'il-te-plait ?
L'entropie, c'est en quelque sorte la quantité de hasard disponible pour le système. En l'absence d'un vrai générateur pseudo-aléatoire matériel, le système se base sur diverses sources de hasard comme des événements aléatoires (ou du moins difficilement prévisibles), ce qui inclut les frappes clavier ou les mouvements de la souris. Pour écrire des données aléatoires sur le disque, on a besoin de générer ces données, ce qui consomme une certaine quantité de hasard. Si le système ne dispose pas assez d'entropie, il peut bloquer en attendant d'en avoir accumulé suffisament, ce qui peut se produire en tapant au clavier ou en bougeant la souris (si le pilote de la souris est chargé), ou bien se replier sur une source de hasard de moindre qualité (moins aléatoire).
Dernière modification par raleur (06-06-2020 12:35:31)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne