[Chiffrement] : comment chiffrer un root post-installation

Maknho · 19-03-2021 17:31:24

Bonjour à tous,

j'ai déplacé le root d'une carte micro-SD à un SSD que j'espère plus résistant. Mais lors de la manip (https://forum.armbian.com/topic/593-nand-sata-install-script/ ) j'ai oublié de préalablement chiffrer mon disque SSD devant accueillir le root.

Est-ce que vous avez en tête la bonne méthodo pour chiffrer ce disque et faire qu'au reboot grub trouve bien la nouvelle partition chiffrée.

Mais peut-être que je psychote pour rien et que c'est très simple ?

D'avance merci bcp pour vos lumières !

EDIT : je sens que ça me ramène vers une réponse de raleur sur un autre post https://debian-facile.org/viewtopic.php?id=29276 :
" il faut mettre à jour l'UUID dans le fichier crypttab de l'initramfs (dans /conf/conf.d/ il me semble)."

Bon il faut que je comprenne ça

Dernière modification par Maknho (20-03-2021 17:00:50)

raleur · 20-03-2021 19:18:40

Maknho a écrit :

j'ai oublié de préalablement chiffrer mon disque SSD devant accueillir le root.

Il est possible de chiffrer une partition non chiffrée sans perdre les données avec cryptsetup-reencrypt. Mais je n'ai jamais essayé. Bien lire la page de manuel.
Si tu as la carte SD d'origine, je pense qu'il sera plus simple, sûr et rapide de recommencer.

Concernant GRUB, est-ce que le contenu de /boot est intégré à la racine ou dans une partition séparée non chiffrée ?
Si partition /boot séparée non chiffrée, va-t-elle rester sur la carte SD ou être déplacée sur le SSD aussi ?

Maknho · 20-03-2021 22:35:52

Bonjour raleur, merci pour ta réponse,

Si tu as la carte SD d'origine, je pense qu'il sera plus simple, sûr et rapide de recommencer.

Oui je l'ai. OK je vais recommencer.

Concernant GRUB, est-ce que le contenu de /boot est intégré à la racine ou dans une partition séparée non chiffrée ?

Le /boot est dans une partition séparée non chiffrée.

Si partition /boot séparée non chiffrée, va-t-elle rester sur la carte SD ou être déplacée sur le SSD aussi ?

Je compte la laisser sur la carte SD.

Dernière modification par Maknho (20-03-2021 22:39:49)

raleur · 20-03-2021 22:59:51

Donc pas d'impact direct sur GRUB.
Après la copie de la racine dans le nouveau volume chiffré, il faudra le cas échéant modifier les fichiers suivants :

- /etc/fstab avec le nom du nouveau volume chiffré /dev/mapper/xxx pour le montage de la racine.

- /etc/crypttab avec le nom du nouveau volume chiffré xxx et l'UUID de son conteneur LUKS (affiché par blkid)

- Le fichier crypttab de l'initramfs avec les mêmes informations. Pour cela l'initramfs doit être reconstruit avec update-initramfs dans un chroot sur le nouveau volume chiffré racine.

- Le fichier /boot/grub/grub.cfg avec le nom du volume chiffré /dev/mapper/xxx dans le paramètre root= des lignes de commande "linux". Le fichier peut être modifié manuellement ou reconstruit automatiquement avec update-grub dans un chroot sur le nouveau volume chiffré racine.

Dernière modification par raleur (20-03-2021 23:00:45)

Maknho · 21-03-2021 09:36:30

OK. Merci raleur. Ca a l'air plus simple que ce qui est indiqué ici (https://forum.armbian.com/topic/15618-f … his-topic/) même si j'appréhende, du fait des mes compétences limitées, la partie chroot

Bonne journée et merci

Dernière modification par Maknho (21-03-2021 09:48:59)

raleur · 21-03-2021 11:17:12

Le chroot peut peut-être être évité de deux façons.

1) Donner au nouveau conteneur LUKS le même UUID que l'ancien (et changer celui de l'ancien avant de redémarrer pour ne pas créer de doublon).
Pour changer l'UUID d'un conteneur LUKS :

cryptsetup luksUUID --uuid "nouvel-uuid" /dev/"partition-luks"

L'UUID de l'ancien conteneur LUKS peut être affiché avec blkid.
Un nouvel UUID peut être généré pour l'ancien conteneur LUKS avec la commande uuidgen du paquet uuid-runtime.

2) Dans l'ancien système, avant la copie de la racine dans le nouveau volume chiffré,
- ajouter le nouveau volume chiffré à /etc/crypttab avec l'option "initramfs" pour qu'il soit ouvert par l'initramfs
- reconstruire les initramfs de tous les noyaux. avec

update-initramfs -u -k all

Après la copie de la racine,
- mettre le nom du nouveau volume chiffré à la place de l'ancien dans le nouveau fichier /etc/fstab
- dans /boot/grub/grub.cfg, remplacer le nom de l'ancien volume chiffré par le nouveau
Au redémarrage, l'initramfs demandera les passphrases pour ouvrir les deux volumes chiffrés.
Après avoir redémarré et vérifié que la racine est le nouveau volume chiffré, on peut retirer l'ancien volume chiffré et l'option "initramfs" devenue superflue du nouveau volume chiffré et exécuter à nouveau update-initramfs comme ci-dessus.

Dernière modification par raleur (21-03-2021 14:14:39)

Maknho · 21-03-2021 14:00:19

Merci bcp raleur.

Je tente l'option 1) : même UUID

raleur · 21-03-2021 14:12:21

Du coup il n'est pas nécessaire de modifier les fichiers fstab, crypttab, grub.cfg ni les initramfs.

Maknho · 21-03-2021 15:44:24

Tu as bien fait de préciser

Merci.

Donc assez simplement :

1) je formate en ext4 une "nouvelle" partition et je la chiffre avec LUKS (en l’espèce je fais le test sur une clef USB de même taille que le SSD où il y a la partition root actuelle non chiffrée et si le test est conclusif je ferai une image de cette clef USB que je restaurerai sur le disque SSD) ;

2) je récupère avec blkid l'UUID de "l'ancienne" partition root ; celle non chiffrée sur le SSD ;

3) je change l'UUID du conteneur LUKS (c'est à dire /dev/sdc1, par exemple, et pas /dev/mapper/xxxx qui est le volume chiffré, c'est-à-dire le contenu si j'ai bien compris) avec l'UUID récupéré en 2) avec la commande :

cryptsetup luksUUID --uuid "nouvel-uuid" /dev/"partition-luks"

=> bon jusque là c'est fait.

4) je copie la racine dans le nouveau volume chiffré.

Et c'est tout...je peux alors :
- éteindre le serveur ;
- échanger le SSD par la clef USB de test ;
- voir si ça redémarre bien avec le root dans le nouveau volume chiffré ;
- et si oui, sauvegarder une image de la clef USB de test et la restaurer sur le SSD.

2 questions :

a) pour les points 1), 2) et 3) ai-je bien compris (nt sur la question de l'identification du conteneur luks, ce que raleur tu as, me semble-t-il, indiqué dans la commande comme "partition-luks")

b) Pour le point 4, est-ce que cette copie nécessite des précautions particulières (démontage ? cp ? dd ? rsync ?) ?

Ma source pour la partition racine peut-être :
- soit le disque dur SSD (celui qui contient la partition root non chiffrée) actuellement actif (en prod) sur mon serveur (odroid N2). Mais alors sans doute que je devrais arrêter le serveur ?
- soit une carte SD (non active, "de sauvegarde") où j'avais restauré une image de sauvegarde que j'avais préalablement faite du disque dur SSD

Donc plus précisément pour la question b), quelle est la source permettant la commande la plus simple et robuste (gestion des éventuelles erreurs...) pour la copie de la racine et quelle est celle-ci ?

Merci++

Dernière modification par Maknho (21-03-2021 20:55:01)

raleur · 22-03-2021 14:17:33

1) D'abord on formate la partition en conteneur chiffré avec LUKS, et ensuite on ouvre le volume chiffré résultant et on le formate.

2) Il faut récupérer l'UUID de l'ancienne partition chiffrée sur la carte SD. Il doit être encore dans le fichier /etc/crypttab de la racine chiffrée.

Mais en disant qu'il n'y aurait pas de fichier à modifier, j'étais parti du principe que le contenu de la carte SD était inchangé et que la machine utilisait encore la racine chiffrée qui est dedans. Si tu as déjà reconfiguré GRUB et l'initramfs pour utiliser la racine non chiffrée du SSD, alors c'est différent.
Pour bien voir où tu en es, tu peux poster le contenu de /etc/fstab, /etc/crypptab, /proc/cmdline et la sortie de blkid et lsblk.

Dernière modification par raleur (22-03-2021 14:17:49)

Maknho · 22-03-2021 14:52:36

Bonjour raleur,

D'abord on formate la partition en conteneur chiffré avec LUKS, et ensuite on ouvre le volume chiffré résultant et on le formate.

OK

Il faut récupérer l'UUID de l'ancienne partition chiffrée sur la carte SD

La carte SD qui accueillait avant root+boot n'était pas chiffré

Pour bien voir où tu en es, tu peux poster le contenu de /etc/fstab, /etc/crypptab, /proc/cmdline et la sortie de blkid et lsblk.

1) /etc/fstab

# <file system> <mount point> <type> <options> <dump> <pass>
tmpfs /tmp tmpfs defaults,nosuid 0 0
UUID=1aba25e8-b646-437b-86c0-2615b9793d57 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1
/media/mmcboot/boot /boot none bind 0 0
UUID=04ed28e5-3444-45b4-a03a-fae2f7c24154 / ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1

2) /etc/crypptab

# <target name> <source device> <key file> <options>

=> apparemment vide

3) /proc/cmdline

root=UUID=04ed28e5-3444-45b4-a03a-fae2f7c24154 rootwait rootfstype=ext4 console=ttyAML0,115200n8 console=tty1 loglevel=1 no_console_suspend fsck.repair=yes net.$

4) blkid

/dev/mmcblk0p1: UUID="1aba25e8-b646-437b-86c0-2615b9793d57" TYPE="ext4" PARTUUID="0419cee1-01"
/dev/sdb1: UUID="8f475bc1-1a82-407d-82a1-7a7f5c61bce6" TYPE="crypto_LUKS" PARTUUID="da277591-1542-4401-904e-37cec709085c"
/dev/sda1: UUID="04ed28e5-3444-45b4-a03a-fae2f7c24154" TYPE="ext4" PARTUUID="1860049b-01"
/dev/zram0: UUID="ef2c0000-c5ed-4267-b114-462e4216815b" TYPE="swap"
/dev/zram1: LABEL="log2ram" UUID="114f54a2-603a-4b7a-9142-cdb00e67ae3c" TYPE="ext4"
/dev/sdc1: UUID="326e90de-5f4a-491b-baeb-1841af890d76" TYPE="crypto_LUKS" PARTUUID="b234d51e-01"
/dev/mapper/2to_serveur: LABEL="xxx_2To_serve" UUID="e3f17213-ca9e-47aa-9162-8b106e1d38db" TYPE="ext4"
/dev/mapper/5to_serveur_Esra: LABEL="5to_xxx_serveur" UUID="625e2909-5a3f-4548-a100-38269c2669a9" TYPE="ext4"

5) lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232.9G 0 disk
└─sda1 8:1 0 232.4G 0 part /
sdb 8:16 0 4.6T 0 disk
└─sdb1 8:17 0 4.6T 0 part
└─5to_serveur_xxx 251:1 0 4.6T 0 crypt /net/5to_serveur_xxx
sdc 8:32 0 1.8T 0 disk
└─sdc1 8:33 0 1.8T 0 part
└─2to_serveur 251:0 0 1.8T 0 crypt /net/2to_serveur
mmcblk0 179:0 0 238.8G 0 disk
└─mmcblk0p1 179:1 0 236.1G 0 part /media/mmcboot
zram0 252:0 0 1.8G 0 disk [SWAP]
zram1 252:1 0 50M 0 disk /var/log

EDIT : question principale : comment est-il possible simplement de chiffrer sda1 ?
question subsidiaire : est-ce aller au bout de la logique (et utile d'un point de vue sécurité) de mettre le boot sur sda1, et de le chiffrer aussi ? Est-ce ardu ?

Dernière modification par Maknho (22-03-2021 17:20:58)

raleur · 23-03-2021 21:49:18

Maknho a écrit :

La carte SD qui accueillait avant root+boot n'était pas chiffré

J'avais mal compris et je pensais que l'installation originelle était chiffrée. Tu peux donc oublier tout ce que j'ai écrit précédemment, ce n'est pas pertinent.

crypttab est vide mais je vois qu'il y a deux volumes chifftrés ouverts (dans sdb1 et sdc1). Comment sont-ils ouverts ?

Maknho · 23-03-2021 23:12:52

Bonsoir raleur,

J'avais mal compris et je pensais que l'installation originelle était chiffrée. Tu peux donc oublier tout ce que j'ai écrit précédemment, ce n'est pas pertinent.

OK. J'oublie

crypttab est vide mais je vois qu'il y a deux volumes chifftrés ouverts (dans sdb1 et sdc1). Comment sont-ils ouverts ?

Avec les commandes suivantes au démarrage du serveur :
a) cryptsetup luksOpen /dev/sdc1 2to_serveur
=> MDP
b) cryptsetup luksOpen /dev/sdb1 5to_serveur_xxx
=> MDP

Ce sont deux disques externes branchés en USB

Dernière modification par Maknho (23-03-2021 23:22:45)

raleur · 24-03-2021 21:44:32

Pour transférer la racine dans un volume chiffré, il va falloir
- créer le conteneur LUKS avec cryptsetup
- afficher l'UUID du conteneur LUKS avec blkid
- ajouter la correspondance entre celui-ci et le volume chiffré dans /etc/crypttab, du style :

root_crypt UUID=uuid-du-conteneur-luks none luks,initramfs

pour que le volume chiffré soit /dev/mapper/root_crypt
- vérifier que le volume chiffré est bien ouvert avec

cryptdisks-start root_crypt

- le formater en ext4
- le monter sur un point de montage temporaire comme /mnt
- installer le paquet cryptsetup-initramfs
- reconstruire les initramfs de tous les noyaux présents avec

update-initramfs -u -k all

- monter / en bind sur un autre point de montage temporaire pour la débarrasser de tous ses montages
- copier le contenu de la racine "nue" dans le volume chiffré
- éditer /boot/grub/grub.cfg
- dupliquer l'entrée de menu principale de la section 10_linux
- modifier son intitulé en ajoutant "(LUKS)" par exemple pour la différencier de l'originale
- remplacer root=UUID=04ed28e5-3444-45b4-a03a-fae2f7c24154 dans sa commande "linux" par root=/dev/mapper/root_crypt
- redémarrer et sélectionner cette entrée dans le menu de GRUB
- vérifier si le système démarre correctement et monte le volume chiffré comme racine
- si tout va bien,
- faire la même modification que dans /boot/grub/grub.cfg dans /etc/fstab
- regénérer grub.cfg avec update-grub

Questions pour ma curiosité :

Il y a une raison particulière pour avoir monté la partition de la carte SD sur /media/mmcboot et fait un montage en bind de ce répertoire sur /boot au lieu de la monter directement sur /boot ? C'était ainsi à l'origine ou bien ça l'est devenu lors du déplacement de la racine ?

D'autre part la partition occupe tout l'espace de la carte SD ; est-ce l'ancienne partition racine ou bien l'ancienne partition racine a été supprimée et la partition de boot a été agrandie ?

Est-ce que zram est vraiment plus adapté que tmpfs pour /var/log ? Normalement les anciens logs sont déjà compressés par logrotate, donc zram ne fait rien gagner avec eux.

Maknho · 26-03-2021 12:42:12

Bonjour raleur,

merci pour ta réponse très complète et précise.

monter / en bind sur un autre point de montage temporaire pour la débarrasser de tous ses montages

Je ne comprends pas vraiment ce que veut dire monter la "racine" en bind ?

Il y a une raison particulière pour avoir monté la partition de la carte SD sur /media/mmcboot et fait un montage en bind de ce répertoire sur /boot au lieu de la monter directement sur /boot ? C'était ainsi à l'origine ou bien ça l'est devenu lors du déplacement de la racine ?

Je ne connais pas la raison mais je pense que c'était comme ça à l'origine dès l'installation de Armbian (l'OS) sur la carte SD.

D'autre part la partition occupe tout l'espace de la carte SD ; est-ce l'ancienne partition racine ou bien l'ancienne partition racine a été supprimée et la partition de boot a été agrandie ?

Je ne sais pas j'ai juste suivi la procédure de transfert avec nand-sata-install indiqué ici (https://forum.armbian.com/topic/593-nand-sata-install-script/ )

Est-ce que zram est vraiment plus adapté que tmpfs pour /var/log ? Normalement les anciens logs sont déjà compressés par logrotate, donc zram ne fait rien gagner avec eux.

Trop technique pour moi je suis confus de ne pouvoir te répondre.
Je me demande même comment fonctionne vraiment la zram (https://doc.ubuntu-fr.org/zram). Est-ce que la seule ressource utilisée par la zram est la RAM sans interaction avec la carte SD ?

raleur · 26-03-2021 22:11:17

Maknho a écrit :

Je ne comprends pas vraiment ce que veut dire monter la "racine" en bind ?

Pourtant on voit dans /etc/fstab que tu l'as fait pour la partition de boot qui est d'abord montée sur /media/mmcboot, puis ce répertoire est monté en bind sur /boot. Mais apparemment ce n'est pas de ton initiative. Cf. l'option "bind" de /etc/fstab ou l'option --bind de mount. Exemple :

mount --bind / /mnt

Et tu verras dans /mnt tout le contenu de la racine sans ce qui est monté sur /boot, /media, /proc, /sys, /tmp. /var/log, etc. (et ce qui est éventuellement caché sous ces montages devient visible).

Maknho a écrit :

Est-ce que la seule ressource utilisée par la zram est la RAM sans interaction avec la carte SD ?

Oui, sauf si l'occupation mémoire des zram repousse d'autres données dans le swap de la carte SD s'il y en a ou hors du cache de fichiers.

Debian-facile

#1 19-03-2021 17:31:24

[Chiffrement] : comment chiffrer un root post-installation

#2 20-03-2021 19:18:40

Re : [Chiffrement] : comment chiffrer un root post-installation

#3 20-03-2021 22:35:52

Re : [Chiffrement] : comment chiffrer un root post-installation

#4 20-03-2021 22:59:51

Re : [Chiffrement] : comment chiffrer un root post-installation

#5 21-03-2021 09:36:30

Re : [Chiffrement] : comment chiffrer un root post-installation

#6 21-03-2021 11:17:12

Re : [Chiffrement] : comment chiffrer un root post-installation

#7 21-03-2021 14:00:19

Re : [Chiffrement] : comment chiffrer un root post-installation

#8 21-03-2021 14:12:21

Re : [Chiffrement] : comment chiffrer un root post-installation

#9 21-03-2021 15:44:24

Re : [Chiffrement] : comment chiffrer un root post-installation

#10 22-03-2021 14:17:33

Re : [Chiffrement] : comment chiffrer un root post-installation

#11 22-03-2021 14:52:36

Re : [Chiffrement] : comment chiffrer un root post-installation

#12 23-03-2021 21:49:18

Re : [Chiffrement] : comment chiffrer un root post-installation

#13 23-03-2021 23:12:52

Re : [Chiffrement] : comment chiffrer un root post-installation

#14 24-03-2021 21:44:32

Re : [Chiffrement] : comment chiffrer un root post-installation

#15 26-03-2021 12:42:12

Re : [Chiffrement] : comment chiffrer un root post-installation

#16 26-03-2021 22:11:17

Re : [Chiffrement] : comment chiffrer un root post-installation

Pied de page des forums