migration crypttab -> cryptmount

Le
Erwan David
Sur une debian lenny (testing)

J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.

Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?

Ou est-ce trop demander ?

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Kevin Denis
Le #1912561
On 2008-02-04, Erwan David

J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.

Ca doit donc etre avec les extensions LUKS.


Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?

Ou est-ce trop demander ?

Je connais mal cryptmount, mais de deux choses l'une:

Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.

A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.

A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?
--
Kevin

Erwan David
Le #1912558
Kevin Denis
On 2008-02-04, Erwan David

J'ai une partition chiffrée (par dmcrypt) qui est pour l'instant montée
au boot grace au /etc/crypttab.

Ca doit donc etre avec les extensions LUKS.


Je voudrais qu'elle soit désormais montée à la demande par
l'utilisateur, en utilisant cryptmount.
Makheureusement les doncs de cryptmount partent de 0 et documentent
comment créer la partition, en l'effaçant au passage. Existe-t-il un
moyen de faire la migration sans recopier totalement les fichiers en
clair pour les réécrire sur la partition désormais montée à l'aide de
cryptmount ?

Ou est-ce trop demander ?

Je connais mal cryptmount, mais de deux choses l'une:

Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.

A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.

A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?


parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.


Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé


Kevin Denis
Le #1912556
On 2008-02-04, Erwan David

Je connais mal cryptmount, mais de deux choses l'une:

Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.

A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.

A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?


parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.

Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise

le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)

De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout

Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)

non, le keyfile est une possibilité pas une obligation.


Il y a eu un article dans le linux mag de janvier sur tout ca.
--
Kevin



Kevin Denis
Le #1912555
On 2008-02-04, Erwan David

Je connais mal cryptmount, mais de deux choses l'une:

Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.

A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.

A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?


parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.

Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise

le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)

De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout

Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)

non, le keyfile est une possibilité pas une obligation.


--
Kevin



Erwan David
Le #1912554
Kevin Denis
On 2008-02-04, Erwan David

Je connais mal cryptmount, mais de deux choses l'une:

Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.

A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.

A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?


parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.

Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise

le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)

De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout


à tester donc, pour le prochain reboot...

Mais ça serait plus propre (vu que cette partition ne contient que des
données personnelles à l'utilisateur), que ce soit monté par
l'utilisateur.

Je ne pense pas que j'utilise LUKS, c'est une vieille versiond e
cryptsetup. Je n'ai même pas de keyfile ou autre qui semblent maintenant
de rigueur (sans être d'ailleurs vraiment documentés...)

non, le keyfile est une possibilité pas une obligation.



Ok, merci.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé




Erwan David
Le #1912553
Kevin Denis
On 2008-02-04, Erwan David

Je connais mal cryptmount, mais de deux choses l'une:

Si tu utilises cryptsetup seul, tu as des chances que cela fonctionne.
cryptmount separe la clé de chiffrement des données chiffrées.
En tripotant le fichier de conf de cryptmount et en lui donnant le
device chiffré à manger ça devrait passer.

A l'opposé, si tu utilises l'extension LUKS de cryptsetup, le device
a les clés stockées au début. Cryptmount ne parviendra (sans
doute) pas à récupérer les données chiffrées. Une solution consisterait
à sauter cet entête pour tomber sur le début du chiffré.

A part ça, pourquoi ne pas continuer avec cryptsetup et un script
sudo?


parceque la séquence de boot me demande le mot de passe et plante
ensuite si le mot de passe donné est mauvais... c'est pas extra.

Tu dois avoir moyen de tuner ce comportement. Chaque distrib utilise

le fichier /etc/crypttab selon des scripts propres. Debian propose un
moyen de plantage soft, il me semble (via nombre d'essai ou timeout)

De memoire, ca doit etre:
c_disk /dev/sda42 none luks,tries=3,timeout


à tester donc, pour le prochain reboot...

Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...

Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.

Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...

Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.

Long, mais marche (et backupe les données au passage).


--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé




Kevin Denis
Le #1912544
On 2008-02-04, Erwan David
à tester donc, pour le prochain reboot...

Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...

Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)


Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.

Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,

tu peux tenter cette solution:

Tu peux reproduire le comportement sur une machine de test, ou la
machine elle meme:
dd if=/dev/zero of=/tmp/test.img bs24k count
losetup /dev/loop0 /tmp/test.img
cryptsetup create c_test /dev/loop0
(mot de passe a saisir)
mke2fs /dev/mapper/c_test
cryptsetup remove c_test
La tu dois etre dans ton cas. Une partition chiffrée avec cryptsetup
seul. Maintenant, est-ce que cryptmount sait le digérer?

Deuxieme etape: cree toi un nouveau fichier avec cryptmount, et
rigoureusement le meme mot de passe que celui créé au dessus.
Demontes tout avec cryptmount, edites le fichier pour le faire pointer
vers /tmp/test.img au lieu de ton image créée précedemment, remontes
avec cryptmount. Conclue.

Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...

C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier

qu'il est suid root, non?

Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.

Long, mais marche (et backupe les données au passage).

Ce qui ne gache rien.

--
Kevin

Kevin Denis
Le #1912541
On 2008-02-04, Kevin Denis
à tester donc, pour le prochain reboot...

Mais le man dit "tries=3" alors que le comportement n'est pas de
demander 3 fois le mot de passe. En fait tout se passe comme si le
script prenait n'importe quel mot de passe en le croyant correct, et que
le pla,tage se faisait plus tard lors du mount...

Ca ressemble a du cryptsetup bare-metal alors. (sans LUKS, quoi)


Comment lui faire vérifier que le mot de passe est correct doit venir
des paramètres check/checkargs, etc... Il faudrait que je joue avec,
mais la machine étant en production c'est pas facile de jouer.

Dans le cas ou tu as bien une partition chiffrée avec cryptsetup seul,

tu peux tenter cette solution:

Tu peux reproduire le comportement sur une machine de test, ou la
machine elle meme:
dd if=/dev/zero of=/tmp/test.img bs24k count
losetup /dev/loop0 /tmp/test.img
cryptsetup create c_test /dev/loop0
(mot de passe a saisir)
mke2fs /dev/mapper/c_test
cryptsetup remove c_test
La tu dois etre dans ton cas. Une partition chiffrée avec cryptsetup
seul. Maintenant, est-ce que cryptmount sait le digérer?

Deuxieme etape: cree toi un nouveau fichier avec cryptmount, et
rigoureusement le meme mot de passe que celui créé au dessus.


Une precision, le mot de passe fourni a cryptsetup doit etre celui
qui est chiffré dans le fichier de cryptmount. Avec de l'aes, ca
doit se resumer a un coup de
echo "password" > fichier
openssl enc aes-256-cbc -in fichier -out key
(met un autre mot de passe)
Et c'est bien le fichier key qui doit etre donné à cryptmount

Demontes tout avec cryptmount, edites le fichier pour le faire pointer
vers /tmp/test.img au lieu de ton image créée précedemment, remontes
avec cryptmount. Conclue.

Par ailleurs le script sudo c'est crade de chez crade, et ça revient à
refaire en moins bien ce que fait cryptmount...

C'est un des arguments de cryptmount. Mais bon, je suis prêt à parier

qu'il est suid root, non?

Si ce n'est pas possible ça sera
tar cvjf|gpg du clair, démontage, refaire une partition utilisable avec
cryptmount et gpg|tar xvjf ensuite.

Long, mais marche (et backupe les données au passage).

Ce qui ne gache rien.




Publicité
Poster une réponse
Anonyme