Migrer un syst
Le
dethegeek
Bonjour,
J'ai un Debian sid sur raid 1 + LVM que je veux migrer dans un volume
chiffré. Mes recherches ne m'ont doné que des méthodes d'installation
frâiche.
Quelqu'un a t il une bonne ressource pour m'éviter de tout réinstaller
(et perdre du temps à tout reconfigurer) ?
J'ai un Debian sid sur raid 1 + LVM que je veux migrer dans un volume
chiffré. Mes recherches ne m'ont doné que des méthodes d'installation
frâiche.
Quelqu'un a t il une bonne ressource pour m'éviter de tout réinstaller
(et perdre du temps à tout reconfigurer) ?
J'imagine qu'il n'y a peut-être pas la place de tout dupliquer ;-)
Sinon, je pense en effet qu'il n'y a pas de migration possible.
D'ailleurs, quand je ré-installe mon ordinateur, je suis obligé de tout
sauvegarder au préalable (via rsync d'ailleurs), d'effectuer une
nouvelle installation et enfin de tout ré-injecter (mon home, toujours
via rsync).
L'idéal serait une solution pour reprendre une partition chiffrée lors
d'une nouvelle installation (à moins que je ne sois passé à côté de
quelque chose)...
David.
Le 23/08/2018 à 11:49, Pierre Malard a écrit :
Le jeudi 23 août 2018 à 11:49 +0200, Pierre Malard a écrit :
Si je duplique l'ancien système de fichiers vers celui qui est chiffré
ça ca ête très pénible de booter la machine. Je compte donc trouver une
procédure que je validerai au préalable. J'ai un brouillon avec une
procédure que j'ai mise au point mais il me manque un petit bout pour
que ça soit fiable (pour le moment il y a une part de tâtonnement et le
succès est aléatoire).
l'idéal é&tant de profiter d'un miroir raid ou lvm pour migrer en
douceur et continuer à booter sur la version non chiffrée en cas de
pépin de migration.
J'ai la chance d'avoir pris un réflexe: ne pas allouer tout l'espace
disque avec mes volumes logiques. De plus mes disques font 2 To et j'ai
des 4 To qui attendent la fin de l'opération pour aller dans une
machine de sauvegarde. L'espace disque n'est pas un souci.
Le jeudi 23 août 2018 à 13:59 +0200, David BERCOT a écrit :
Content-Type: multipart/alternative;
boundary="Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5"
--Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Personnellement, j’ajouterai la copie d’éventuelles ACL (-A), exclurait les inutiles dans ce cas (—exclude), afficherait les statistiques à la fin (—stats) et, histoire de mettre les points sur les « i » j’ajouterai un « / » à la fin. Ce qui donnerai après avoir copié le contenu de « /boot » sur la nouvelle partition :
# rsync -aAx --exclude="/lost+found" --exclude="/boot" —stats /partitionChiffreeMontee/
Pour les modifications suivantes j’utiliserais un chroot pour éviter les erreurs :
# mount <Device_Chiffrée> /<partitionChiffreeMontee> (je suppose queque chose comme /dev/sdbN)
# mount <Nouvelle_Partition_BOOT> /<partitionChiffreeMontee>/boot
# mount --bind /dev /<partitionChiffreeMontee>/dev
# mount --bind /dev/pts /<partitionChiffreeMontee>/dev/pts
# mount --bind /sys /<partitionChiffreeMontee>/sys
# mount -t proc /proc /<partitionChiffreeMontee>/proc
# chroot /<partitionChiffreeMontee> /bin/bash
Sur une seule ligne :
# mount --bind /dev /<partitionChiffreeMontee>/dev && mount --bind /dev/pts /<partitionChiffreeMontee>/dev/pts && mount --bind /sys /<partitionChiffreeMontee>/sys && mount -t proc /proc /<partitionChiffreeMontee>/proc && chroot /<partitionChiffreeMontee> /bin/bash
Après on peut modifier le « /etc/fstab » de la partition cryptée, les autres fichiers et lancer un « update-grub ». Si on doit retirer le disque d’origine, il faut le faire suivre d’un « grub-install <Device du disque crypté> » si on est dans un disque formaté MBR ou, pour un disque GPT auquel on aura prévu une petite partition « BIOS boot » un « update-grub —modules=part_gpt <Device du disque crypté> » (/dev/sdb je présume).
Enfin, toujours si on retire le premier disque non crypté, il faut modifier le « grub.cfg » qui ne pointera plus sur le bon disque (/dev/sda = hd0 et /dev/sdb = hd1). Si le nouveau disque crypté est sur /dev/sdb, il va prendre la place du 1er si on le retire, il va donc s’appeler /dev/sda. Il faut donc modifier cela dans le fichier « grub.cfg » :
# sed --in-place=.OLD --expression='s/hd1/hd0/g' /<Nouvelle_Partition_BOOT>/grub/grub.cfg
--
Pierre Malard
« le passé n'éclairant plus l'avenir, l'esprit marche dans les ténèbres »
Alexis de Tocqueville - Démocratie en Amérique
| _,,,---,,_
/,`.-'`' -. ;-;;,_
|,4- ) )-,_. , ( `'-'
'---''(_/--' `-'_) πr
perl -e '$_=q#: 3| 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. , ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'_): 24πr::#;y#:#n#;s#(D)(d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
--Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
</div>
<br class=""></body></html>
--Apple-Mail=_7A048FC7-8244-4BCA-9E0A-C69FBA7494B5--
--Apple-Mail=_6F7362CF-342C-4664-81E6-E170D78D3E9A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2
Comment: GPGTools - http://gpgtools.org
iQIzBAEBCgAdFiEE0KHTJ+AWKhmI+acm/pSWHuad/BgFAlt/+qMACgkQ/pSWHuad
/BgpUQ/9E/dg90OELqiDRvqcOKKQ3/TI0WmtrUPsvDa6FEjleCbj9H8YM6L+t/HF
sIb9vn2DOdFgh2/Yo4CFBqn2F67Y1QR6afoqnNexDA31xLzCcahHhbciZwlmWkM6
2KfSABSW5wDgzg8YMqVZDRmdMUBIltjBRZcIOVydGk1HwD4tzy6C0oNpXZvs8zX6
eEWd9DSKtOwsv1+bcQMe1Yo33VpcNdy4fF+OGr5Rrq/GuJ4B+T0VsSUw7z/3CDyt
SElfmemvM3xKv3nrAjENVHAqCW/wNKD4g6dx3TOgseJ60NrnjNain7ZWfn3yjpxU
Y6bXrNqeRT6VGlQXYgSDZgkf7XaSU/eRo4j0hwz1qMpQCrG/qOGvN1OW6VDxTpiN
zuRo1cEYadAlVTe9qvt3qaGg9kUiUDS8peafEHDCD4WY0yG/MSA9CnHVydwYDwjS
eJ4zmjJ4aM15H1oU5cgZBufGtZ4jf5uGmouXx6kV2lCaEsylX0KsukfypMfJWZKy
TOEwddyKHhPhiLZLatn3o7MnemyINfOT7mQ5/sQMeICR8eq9cybihP0R0w6qATqq
GWU53C9hc+z4SJcFWGM3PbHXT5URfHd0abc4IAZVJWyYfJ4S4O/BzGWvS0nwr8+e
8jHGI5y/0D9K+jJl22wLhRyNfdVVB5NuzGHEkT1GjaWLEm4LYWA =4WYE
-----END PGP SIGNATURE-----
--Apple-Mail=_6F7362CF-342C-4664-81E6-E170D78D3E9A--
Le vendredi 24 août 2018 à 14:31 +0200, Pierre Malard a écrit :
Je suis plus partisan d'un miroir lvm pour cette étape, on peut
"mirrorer", puis "splitter" le mirror en 2 lv distincts. J'ai testé.
C'est pour moi infiniment plus sûr qu'un rsync, bien que j'aime
beacuopup cet outil.
Ma difficulté réside dans la config manuelle de ceryptsetup, pour être
au plus proche d'un crytpsetup fait via une install fraiche.
et home. J'ai initialement prévu que boot soit non chiffré, mais c'est
pas une bone idée. On peut techniquement attaquer ce volume pour y
mettre un keylogger.
La bonne pratique est donc de chiffrer /boot, grub , de ce que je lis,
le gère; et vérifier avant tout déchiffrement qu'il n'y a pas de
hardware suspect sur un port USB, un clavier modifié, et autres
joyeusetés. Reste encore des failles côté bios / uefi; ça devient
vraiment de la paranoïa à ce stade, mais à force d'apprendre ce qu'il
est possible de faire pour pénétrer une forteresse numérique, je finis
par me dire qu'on ne peut que se protéger des "petits joueurs".
Cela dit il y a encore cette solution pour attaquer:
https://www.engadget.com/2008/10/20/keyboard-eavesdropping-just-got-way-easier-thanks-to-electrom/
Il s'agit d'écouter les émissions éléctromagnétiques des claviers pour
trouver les frappes. Ca peut se faire au travers d'un mur, à 20m de
distance. Pour votre gouverne...
A défaut de solution prêt à l'emploi, je vais continuer la création de
ma procédure en comparant ce que j'ai fait avec vos propositions. Je
sais que je ne suis pas très loin; je peux presque migrer à chaud, avec
une toute petite iinterruption de service (j'adore chercher la solution
qui vise à ne pas interrompre la machine ou très peu; LVM aide
énormément pour cela).
Le vendredi 24 août 2018 à 16:32 +0200, Daniel Caillibaud a écrit :
Oui. Mais la core image de GRUB (qui demande de taper la passphrase pour
déchiffrer le volume contenant /boot) reste en clair et donc vulnérable.
Si le but est de se protéger de la divulgation des données en cas de
perte ou vol de l'ordinateur, alors le chiffrement de /boot n'est pas
nécessaire, il ne contient pas de donnée sensible.
Si le but est de se protéger contre une intervention illicite sur
l'ordinateur passée inaperçue, alors le chiffrement quel qu'il soit ne
suffit pas car il reste toujours une partie en clair pour l'amorçage. Il
faut y ajouter la vérification de l'intégrité.
Le samedi 25 août 2018 à 10:11 +0200, Pascal Hambourg a écrit :
Bonne remarque. Du coup il faut un certificat pour vérifier GRUB ainsi
que /boot si elle n'est pas chiffrée. Avoir /boot chiffré permettrait
de réduire le volume de données à valider. Un système TPM aiderait.