Journal CryptoFS ?

Posté par (page perso) .
Tags : aucun
0
8
nov.
2004
Salut mon journal,

Habitué d'utiliser cryptoloop, (losetup) pour créer et monter mes partitions cryptées, un ami, ancien de Linux, m'a dit que cela présentait des dangers importants de corruption de données...

Dans le doute, je cherche quels systèmes alternatifs à cryptoloop, fiables et libre (bien sur) existent pour faire un système de fichiers crypté, si possible root compris ( root = / ) et si possible qui marche avec debian sarge (même s'il faut recompiler un noyau custom ou des packages maison ;) )

Journal, Ô mon journal, aurais-tu une idée ?


PS: Cette recherche fait écho à la saisie des disques durs de Indymedia par le FBI. Le but serait de faire un nouveau service pour un hébergeur mutualisé bien connu : proposer des / cryptés partout ;)
  • # cryptoloop est mort

    Posté par . Évalué à 3.

    vive dm-crypt.

    http://www.ibiblio.org/pub/Linux/docs/HOWTO/Cryptoloop-HOWTO(...)
      IMPORTANT: Cryptoloop has been marked deprecated in the latest 2.6 kernel.
      This means that it will no longer be maintained actively. The successor to
      Cryptoloop will be [http://www.saout.de/misc/dm-crypt/(...)] dm-crypt. Dm-crypt is
      available in the main kernel since 2.6.4. Cryptoloop will still be available
      in the main kernel for a long time, but dm-crypt will be the method of choice
      for disk encryption in the future. Dm-crypt is based on the device mapper and
      offers pretty much the same functionality as Cryptoloop. It is still very new
      and there are no easy-to-use userspace tools available yet. Dm-crypt is
      considered to be much cleaner code than Cryptoloop, but there are some
      important differences. For example, creating an ecrypted filesystem within a
      file will still require to go through a loop device, but this support is
      still in development.
    • [^] # Re: cryptoloop est mort

      Posté par (page perso) . Évalué à 2.

      oui, kernel 2.6.8.1 (le 2.6.9 a un trou de mémoire, 2 kernel panic en 2 jours sur une machine de test... )

      dm_crypt ? pas d'outils en cli ? bon, c'est l'occasion ou jamais d'aider à avoir un zoli outil propre pour configurer ce bouzin ?

      Merci à vous les geeks.
      • [^] # Re: cryptoloop est mort

        Posté par . Évalué à 1.

        > le 2.6.9 a un trou de mémoire, 2 kernel panic en 2 jours sur une machine de test...

        Les noyaux vanilla ne sont pas fait pour être exempt de tout défaut car moins testé que les noyaux des distributions.
        FC3 est sorti avec Linux 2.6.9. Le noyau (avec les patchs Fedora) est utilisé depuis le 3/11 sans gros problème (il y a un problème avec les imprimantes réseau lorsqu'on utilise un firewall. Un workaround existe).
        Depuis le passage en 2.6.9 il y a eu plusieurs fix :
        rpm -q --chancelog :
          * lun nov 01 2004 Dave Jones <davej@redhat.com>

          - Fix memory leak on x86-64 in mixed 32/64 mode. (#132947)
          - Yet another USB card reader for the whitelist. (#137722)

          * ven oct 29 2004 Dave Jones <davej@redhat.com>

          - Fix raid5 oops (#127862)
          - Stop E820 BIOS entries being corrupted by EDID info. (#137510)

          * jeu oct 28 2004 Dave Jones <davej@redhat.com>

          - Remove the possibility of some false OOM kills. (#131251)
          - Add more USB card readers to SCSI whitelist (#131546)
          - Disable CONFIG_SCHED_SMT for iseries.

          * mer oct 27 2004 Dave Jones <davej@redhat.com>

          - Reenable ISA NIC support (#136569)

          * mar oct 26 2004 Dave Jones <davej@redhat.com>

          - Reenable Initio 9100U(W) SCSI driver. (#137153)

          * lun oct 25 2004 Dave Jones <davej@redhat.com>

          - Add another USB card reader to SCSI whitelist (#132923)

          * ven oct 22 2004 Dave Jones <davej@redhat.com>

          - Fix PPC NUMA (#130716).
          - Fix autoraid for S390 (#123842/#130339)
          - Selected bits from 2.6.9-ac3
          - Fix syncppp/async ppp problems with new hangup
          - Fix broken parport_pc unload
          - Stop i8xx_tco making some boxes reboot on load
          - Fix cpia/module tools deadlock
          - Security fix for smbfs leak/overrun

          * jeu oct 21 2004 Dave Jones <davej@redhat.com>

          - Misc security fixes from 2.6.9-ac2

          * mer oct 20 2004 Dave Jones <davej@redhat.com>

          - Fix ia64 module loading. (#136365)
          - Enable discontigmem for PPC64
          - Disable a bunch of useless PPC config options
          - Enable PACK_STACK on s390.

          * mar oct 19 2004 Dave Jones <davej@redhat.com>

          - Fix NFS badness (#132726)
          - Drop bogus USB workaround. (#131127)

          * lun oct 18 2004 Dave Jones <davej@redhat.com>

          - Rebase to 2.6.9


        Comme tu le vois, il y a 15 jours de debuggage. Ici, ça marche nickel.
    • [^] # Re: cryptoloop est mort

      Posté par . Évalué à 1.

      A noter quand même quelques problèmes de sécurité dans dm-crypt dans l'état actuel, problèmes qui devraient être réglés d'ici quelques temps, néanmoins:
      http://clemens.endorphin.org/LinuxHDEncSettings(...)
  • # dmcrypt ?

    Posté par . Évalué à 1.

    si tu as un kernel 2.6
  • # EncFS

    Posté par . Évalué à 2.

    http://arg0.net/users/vgough/encfs.html(...)

    Il parait que c'est assez costaud en ce qui concerne la méthode de cryptage et que c'est correct niveau vitesse. J'ai pas testé.
  • # ?

    Posté par (page perso) . Évalué à 2.

    PS: Cette recherche fait écho à la saisie des disques durs de Indymedia par le FBI. Le but serait de faire un nouveau service pour un hébergeur mutualisé bien connu : proposer des / cryptés partout ;)

    La loi ne t'obligerait pas a fournir les clé de chiffrement avec la saisie des disques?
    • [^] # Re: ?

      Posté par . Évalué à 2.

      Dans ce cas il faut utiliser BestCrypt... (http://linuxfr.org/~calandoa/15270.html(...)).
      C'est pas libre, mais les sources sont fournis.

      Par ailleurs, comment est il possible d'avoir un fs chiffré à partir de la racine? Comment le boot loader peut il alors charger le noyau? En passant par une première partition claire, puis en en remontant une chiffrée à la racine?
      • [^] # Re: pivot_root / initrd & co

        Posté par (page perso) . Évalué à 2.

        Oui, en utilisant une partition de 20 Mo contenant juste le noyau, point, qui montera ensuite le / encrypté.

        On peut aussi utiliser un / temporaire contenant juste les outils de montage de partition crypté puis utilise pivot_root pour remonter / sur la partition cryptée.

        Je ne sais pas encore ce dont aura besoin dm-crypt pour pouvoir monter / encrypté. (juste le noyau ou un / minimal avec des binaires de montage comme cryptsetup)
        • [^] # Re: pivot_root / initrd & co

          Posté par (page perso) . Évalué à 2.

          L'utilisation d'un initrd est probablement plus aproprié (cf /usr/src/linux/Documentation/initrd.txt ou un truc comme ça).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: ?

      Posté par . Évalué à 3.

      La loi ne t'obligerait pas a fournir les clé de chiffrement avec la saisie des disques?

      Seulement sur demande d'un juge d'instruction.

      Dans le cas d'Indymedia, les disques auraient plus ou moins été "empruntés" par le FBI sans qu'un motif réel d'infraction ne soit établi, ou en tout cas sans que les propriétaires des disques n'en soient clairement informés.

      C'est contre ce genre d'abus qu'un FS chiffré te protège.
      • [^] # Re: ?

        Posté par . Évalué à 0.

        Dans le cas d'Indymedia, les disques auraient plus ou moins été "empruntés" par le FBI sans qu'un motif réel d'infraction ne soit établi, ou en tout cas sans que les propriétaires des disques n'en soient clairement informés.
        C'est contre ce genre d'abus qu'un FS chiffré te protège.


        Sans vouloir vous démoraliser, si le FBI a vraiment besoin d'accéder à vos données, qu'elles soient chiffrées ou non, ils ont à leur disposition de quoi casser rapidement n'importe quel système de chiffrement.

        Bref, mis à part que les données seront "secrètes" quelques heures de plus (le temps de transiter vers le centre adéquat), je ne vois pas l'avantage, si ce n'est que la garde à vue risque d'être un peu plus longue (je serais tenté de dire proportionnellement plus longue au temps nécessaire pour accéder aux données).

        Pour moi le chiffrement des données, c'est surtout pour éviter de perdre des secrets personnels et/ou industriels lors d'un cambriolage ou d'un piratage, voire de la perte d'une machine ou d'un média.
        • [^] # Re: ?

          Posté par . Évalué à 2.


          Sans vouloir vous démoraliser, si le FBI a vraiment besoin d'accéder à vos données, qu'elles soient chiffrées ou non, ils ont à leur disposition de quoi casser rapidement n'importe quel système de chiffrement.


          Enorme :-D

          Sans rire tu penses vraiment que le FBI a les moyens de casser du chiffrement 256 bits ? J'ai l'impression que tu n'as aucune idee de l'ordre de grandeur. Avec l'integralite de toutes les machines construite jusqu'a aujourd'hui et mise en parallele, tu mettrais plusieurs centaines (milliers ?) d'annees avant de pouvoir acceder a leur contenu. Sans compter un autre effet interressant, faire de l'analyse statistique sur un systeme de fichiers, c'est loin d'etre la meme chose que de le faire sur du texte. Il y a de grande chance que tu es enormement de faux positif. Franchement, je ne me fais pas de soucis pour la securite des donnees.

          PS: Il y a que dans les films que l'on sait casser un chiffrement de 1024 bits de tete...

          PS2: L'ordre de grandeur pourrait peut-etre etre diminuer un peu avec un ordinateur quantique. Mais on en est encore tres loin.
          • [^] # Re: casser de la crypto 256Bits AES

            Posté par (page perso) . Évalué à 2.

            Salut,

            J'ajoute à cela que si le FBI à envie de casser mon FS crypté en AES256, on va se retrouver dans une position "niveau de besoin" vs. "moyens mis en oeuvre".

            En effet, dans le cas d'indymedia, je ne sais pas s'ils auraient été jusqu'à un bruteforce d'une partition cryptée si celle-ci avait été cryptée ? En gros, le besoin d'information qu'ils avaient était-il suffisemment important pour justifier de mettre X millions d'heures CPU sur cette affaire ? et oui, ... La seule chose à craindre en fait dans cette situation est que le type qui a la passphrase se fasse enlever et qu'on lui fasse cracher le morceau ;( ...

            Je pense donc être suffisemment bien protégé avec AES256 ... reste à couper la clé en 2 ou 3 :)
          • [^] # Re: ?

            Posté par . Évalué à 2.

            Euh... ces ordres de grandeur c'est pour la force brute. S'ils connaissent une faille de la méthode de crypto, il n'est pas impossible qu'ils n'aient besoin que de quelques secondes même sur une petite machine. "Si".

            Ceci dit il est intéressant de regarder leurs contributions aux mises au point des standard de crypto. Si je me souviens bien, il y a quelques années, ils ont demandé une petite modification sur un truc proposé ; un peu après on a découvert une nouvelle méthode d'attaque des systèmes de crypto, contre laquelle la modification était une très bonne protection.

            Snark
          • [^] # test

            Posté par . Évalué à 2.

            C'est bizarre, ça fait 2 fois que j'essaye de répondre à ce commentaire, et ma réponse n'apparaît toujours pas. Je suis pourtant certain (en tout cas pour le deuxième post) d'avoir vérifier-valider mon commentaire.

            Ce message n'est qu'un test pour vérifier, il n'a aucun intérêt, c'est potentiellement ma 3ème réponse au commentaire au dessus.
  • # hébergement distant et chiffrement = pas bon ménage

    Posté par . Évalué à 2.

    PS: Cette recherche fait écho à la saisie des disques durs de Indymedia par le FBI. Le but serait de faire un nouveau service pour un hébergeur mutualisé bien connu : proposer des / cryptés partout ;)

    Il y a un truc que je ne comprends pas : pour avoir un / chiffré, il faut bien fournir la clé au boot, donc :

    - soit elle est stocké en clair sur le serveur (disquette, clé usb ...),
    - soit un opérateur tape le mot de passe sur la console.

    Dans le premier cas ça ne sert à rien de chiffrer : celui qui saisit les serveurs saisit aussi les clés et il a accès à tout.

    Dans le second cas ça suppose que le client puisse taper son mot de passe au démarrage, donc qu'il se déplace dans les locaux de l'hébergeur après chaque reboot, programmé ou pas !

    Est ce que ça ne risque pas d'être un chouïa lourd à gérer ?
    • [^] # Re: hébergement distant et chiffrement = pas bon ménage

      Posté par (page perso) . Évalué à 2.

      non, pas lourd à gérer car :

      - nous avons un KVM-IP pour accéder aux console à distance ( http://cuc.fr/transdonnees/kvm/067160.jpg(...) )
      - oui, on tape le mot de passe à chaque reboot, mais
      * sous linux, on ne reboote pas souvent (sauf faille majeure de noyau, mais là on planifie le reboot ;) )
      * l'architecture load-balancée de cet hébergeur permet de rebooter les serveurs un par un sans interrompre le service ;)

      Donc, oui, / crypté (sauf le noyau lui-même dans une petite partition non cryptée) et saisie des mots de passes de partitions au démarrage.

      Pour les aspects juridiques, c'est en effet contre les abus de pouvoir de gens comme rackspace que nous nous prémunissons (nous ne sommes pas chez eux, mais c'est chez rackspace UK que les serveurs d'indymedia ont été saisis, à la demande du FBI (cherchez l'erreur ...) )
      • [^] # Re: hébergement distant et chiffrement = pas bon ménage

        Posté par . Évalué à 1.

        nous avons un KVM-IP pour accéder aux console à distance ( http://cuc.fr/transdonnees/kvm/067160.jpg(...(...)) )
        - oui, on tape le mot de passe à chaque reboot,


        La première fois, les flics se feront avoir et embarqueront un disque indéchiffrable.

        La seconde fois, ils se pointeront avec une machine espion à 2 balles qu'ils brancheront entre le KVM et le serveur puis vous obligeront à envoyer le mail automatique "Cher client, suite à un probème d'onduleur votre serveur s'est arrêté, merci de vous logguer bla bla bla ...". Ils attendront ensuite tranquillement une heure, un jour ou une semaine que le client se connecte et remonte la partition, puis ils repartiront avec les disques et le mot de passe en clair.

        Sans un contrôle physique de l'intégrité du serveur *avant* de saisir le moindre mot de passe, le client ne peut jamais être sûr de ne pas s'être connecté sur un leurre.

        Pour les aspects juridiques, c'est en effet contre les abus de pouvoir de gens comme rackspace que nous nous prémunissons

        On est bien d'accord, mais si l'hébergeur est de mauvaise foi le client l'aura dans l'os.
  • # Les partitions de données seules?

    Posté par . Évalué à 4.

    Je vais sûrement dire une çonnerie, mais quel est l'intérêt de chiffrer tout y compris /, /usr/, etc..) au lieu de chiffrer juste le swap et les partitions de données (/home, /var et swap) ?
    • [^] # Re: Les partitions de données seules?

      Posté par (page perso) . Évalué à 2.

      La garantie qu'il ne sortiront RIEN de la machine, ni même la petite requete qui trainerait sur /root/.mysql_history ou encore le fait que l'on utilise un binaire du logiciel "toto" ayant telle ou telle faille, bref, non-disclosure totale pour ces gens là tant qu'ils n'ont pas notre accord.

      De toute manière, ca ne coute pas plus cher car les binaires / conf sont en cache en ram rapidement sur nos serveurs (1Go de ram mini) et ne sont jamais relus sur le disque.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.