Un noyau 2.4.0-crypto en RPM binaires pour Mandrake 7.2 !

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
11
jan.
2001
Mandriva
Bien que ce ne soit pas des RPM officiellement supportés par MandrakeSoft, ça reste une première dans le monde de la crypto et des OS libres (à part OpenBSD ?).

Un militant de la crypto libre a patché la version "Cooker" des sources 2.4.0 pour Mandrake 7.2 et y a ajouté la crypto du noyau "Kerneli". Concrètement, ça veut dire que sans avoir besoin de tout recompiler vous avez un noyau avec support crypto pour créer et monter des containers chiffrés (l'équivalent de ce que les Windoziens possèdent avec des logiciels comme Scramdisk ou PGPdisk).

Maintenant, il faut souhaiter que MandrakeSoft et les autres distributions emboîtent le pas et fournissent des kernel-crypto pour chaque version du noyau.

PS : il semble que l'auteur des RPM cherche des miroirs FTP.

Aller plus loin

  • # RPM dispos aussi sur FTP

    Posté par  . Évalué à 0.

  • # RPM dispos aussi sur FTP

    Posté par  . Évalué à -1.

  • # Excusez-moi

    Posté par  . Évalué à 0.

    mais à quoi çà sert ?
    Je ne suis pas un féru de cryptoggraphie/mystère/secret ...
    • [^] # Re: Excusez-moi

      Posté par  (site web personnel) . Évalué à 1.

      Oui, a quoi ça sert des RPM du noyau ? C'est pour ceux qui n'ont pas tar ?
      • [^] # Re: Excusez-moi

        Posté par  . Évalué à 1.

        Ca sert à ceux qui n'utilisent pas des vraies ditributions comme Debian ou Slackware ... Oups, j'ai oublié de mettre des balises <troll> ;-)

        Non, plus sérieusement, il s'agit de noyaux précompilés et mis en paquet RPM. Ca permet donc d'installer plus facilement le noyau quand on a une config plutôt standard et quand on a peur du mot <<compiler>>.

        De toutes façons, je pense que la meilleure solution reste de compiler sois-même son noyau (et d'utiliser une Debian ou Slack ;-)). Les performances s'en ressentent souvent.
        • [^] # Re: Excusez-moi

          Posté par  . Évalué à 0.

          > Ca sert à ceux qui n'utilisent pas des vraies ditributions comme Debian ou Slackware

          </troll>Et ils sont nombreux à ne pas utiliser slack</troll>
        • [^] # Re: Excusez-moi

          Posté par  . Évalué à 0.

          > Ca sert à ceux qui n'utilisent pas des vraies ditributions comme Debian ou Slackware

          </troll>Et ils sont nombreux à ne pas utiliser slack</troll>
          • [^] # Re: Excusez-moi

            Posté par  . Évalué à 0.

            Désolé d'avoir posté deux fois, quand j'ai cliqué sur le bouton "Ajouter un commentaire", j'ai eu ce message :
            "Vous ne pouvez pas répondre à une news fantôme."
            • [^] # Re: Excusez-moi

              Posté par  . Évalué à 0.

              Ah! voila du troll utile. :)
              Une news fantôme, c'est DaTrollFrenchPage par exemple (666).
              Ca va permettre de regarder ce qui se passe.
              Merci,
              -- fred L
        • [^] # Re: Excusez-moi

          Posté par  . Évalué à 0.

          Ah bon, Debian n'a pas de debs des noyaux compilés ?
          • [^] # Re: Excusez-moi

            Posté par  . Évalué à 1.

            Si, mais il y a aussi des debs des sources du noyau. Je me rends compte que je n'ai pas été très clair sur le coup-là ...
    • [^] # Re: Excusez-moi

      Posté par  . Évalué à 1.

      Ce genre de noyau est en mesure de lire et d'écrire sur des partitions qui sont encryptées.
      Il est alors impossible (== très difficile) de lire le contenu depuis un autre système (comme par exemple fenêtres, avec le soft qui va bien pour lire les partitions ext2 (désolé, je ne connais pas le nom de ce soft, je n'utilise pas fenêtres)), du moins sans la clef ...

      Ca évite aussi les cas où un petit malin utilise une disquette ou CD de boot autre ou passe outre le lancement classique avec LILO (init=/bin/sh ou un truc du genre). Mais dans ce cas, je pense plus que c'est l'admin qui est à blamer (il est possible de ne pas autoriser le boot depuis autre chose que le dur, ainsi que de mettre un accès restreint aux commandes d'administration de LILO).

      Enfin, ça évite de se faire voler le disque pour exploiter le contenu ... Sisi, j'ai vu ça comme argument une fois ...
      • [^] # Bon argument au contraire

        Posté par  (site web personnel) . Évalué à 1.

        > Enfin, ça évite de se faire voler le disque pour exploiter le contenu ... Sisi, j'ai vu ça comme argument une fois ...

        Eh bien même si ça t'amuses, c'est un des meileurs arguments pour utiliser cette fonctionnalité du noyau. En effet, tu demanderas à une société ou à une administration s'ils sont contents de savoir que leurs données commerciales ou administratives sont dans la nature lorsqu'ils se font voler des machines dans leurs locaux.

        Ces mêmes fonctions sont utilisées classiquement sur des portables Win pour éviter la perte de données commerciales en cas de vol.

        On peut citer le cas de vol de 2 portables des services secrets anglais qui avaient fait beaucoup de bruit il y a quelques mois car leurs données n'étaient pas cryptées sur le disque.

        Perso, même si je bosse sur une MDK depuis longtemps, le noyau est bien la dernière chose que j'installerai via un RPM (à part pour l'install...). La compil via le tar.gz et les patchs me semble préférable (on a jamais les mêmes options que le voisin...)
        • [^] # Re: Bon argument au contraire

          Posté par  . Évalué à 1.

          Bof !

          Si une entreprise n'a pas envie de se faire voler, ce n'est pas difficile de verouiller les boitiers. Tous les bons boitiers possèdent des anneaux qui une fois cadenassés empêchent l'ouverture. De plus, on peut aussi mettre un chaîne au cadenas pour pas que la machine puisse sortir de la pièce. Il est aussi possible de mettre la machine dans une pièce surveillée.

          Sinon, pour les portables, le principe est de pouvoir utiliser le portable quand tu es en déplacement. Donc, tu as aussi la clef sur toi. Donc ce n'est pas parce que les données sont cryptée qu'on ne peut pas les lire, puisqu'il suffit alors de chercher un petit peu pour trouver la clef. Ah, au fait, un des "vols" chez les Anglais était en fait un oubli : l'agent secret l'avait oublié dans le train ...

          A mon avis, la seule raison valable pour crypter les données de cette manière, c'est lorsqu'il existe un autre système sur la machine (et qu'il serait alors possible de faire une lecture bas-niveau depuis ce système).

          Enfin, tout à fait d'accord pour les noyaux précompilés : il manque toujours quelque chose, et ils sont d'une lourdeur dingue.
  • # Kerneli n'est pas comparable a Openbsd !

    Posté par  . Évalué à 0.

Suivre le flux des commentaires

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