The wikis are now using the new authentication system.
If you did not migrate your account yet, visit https://idp-portal-info.suse.com/

Secure Installation Sources

Aller à : navigation, rechercher
Acroread.png Cet article est à relire !

Cette page demande à être relue pour correction. Si vous pouvez y participer, merci de le faire en accord avec le Guide stylistique openSUSE.
Si vous cherchez quelque chose à faire, regardez les autres Pages à relire.

Confiance dans les sources d'installation

Vous pouvez obtenir les médias d'installation ou des dépôts d'installation en ligne pour SUSE Linux depuis de nombreux miroirs publics, et de nombreux sites offrent des paquetages supplémentaires comme source d'installation. Cela accroît significativement l'extensibilité du projet OpenSUSE.

Mais il y a aussi un risque accru avec ces sources: comment savoir que les sources sont complètes et ne contiennent pas de code malicieux  ?

A partir de la version 10.1, ceci a été adressé en utilisant une combinaison de signatures cryptographiques et de sommes de contrôle.

Voici un bref aperçu du concept de signature des paquetages et des métadonnées pour SUSE Linux 10.1+:

Des signatures GPG pour signer les fichiers les plus critiques dans le dépôt/les sources d'installation. We use detached GPG signatures to sign the most important metadata files in an installation source/repository. There are two flavors of installation sources that are addressed:

Sources d'installation "habituelles" de SUSE

Ce sont les sources des CDs et DVDs. Elles sont aussi appelées "sources YaST", bien que YaST supporte d'autres types de sources. Il y a 2 points d'entrée :

Le fichier "media.1/products"

Ce fichier liste les répertoires absolus (depuis la racine de l'arbre des sources) vers les produits sur le media. C'est intéressant pour les media avec plusieurs produits mais il n'y a habituellement qu'une seule ligne :

   / SUSE-Linux-Enterprise-Desktop 10

Ce fichier sera signé avec une clé SUSE pour tous les produits venant de Novell. La clé publique (GPG) pour cette clé qui peut être utilisée pour vérifier la signature est stockée dans le fichier "products.key" par commodité.

Cette clé sera aussi importée depuis initrd (l'image amorçable initiale de Linux qui exécutée au démarrage à partir des media). Généralement, YaST le saura suag pour les versions Beta. La clé (susceptible de changer) est actuellement sur les media dans le fichier

   /gpg-pubkey-9c800aca-40d8063e.asc

La signature pour le fichier "products" est dans le fichier "products.asc".

Quand YaST trouve une source d'installation, il vérifie si le fichier "products" est présent, et vérifie si le fichier est signé avec une clé connue. Si ce n'est pas la cas, où si la clé n'est pas digne de confiance, l'usager sera interrogé pour savoir s'il faut poursuivre les opérations.

Le fichier "products" est signé afin que personne ne puisse ajouter de produits à une source d'installation.

Le fichier "content"

Pour chaque produit, il y a un fichier "content". S'il n'y a pas de fichier "products", le fichier "content" de la racine des sources est utilisé.

Le fichier "content" est signé de la même manière que "products". Un fichier "content.key" contient la signature publique pour valider le fichier. (ce n'est pas nécessairement la même clé que dans"products.key").

Par rapport aux fichiers "content" d'anciennes versions, il y a deux clés additionnelles :

   META SHA1 08579e4b28287d6aedd954098b64c6bb49d17367 packages
   KEY SHA1 a108c6aab19fe604fa98ef299cdce6e6ba275f09 gpg-pubkey-0dfb3188-41ed929b.asc

Les clés META sont ajoutées pour tous les fichiers dans le répertoire référencé par la clé DESCRDIR, Par example :

   DESCRDIR suse/setup/descr

Avant que YaST utilise un fichier de DESCRDIR, il va vérifier l'entrée dans le fichier "content". Cette entrée est actuellement une somme de contrôle SHA1 suivie par le nom de paquetage. Elle pourrait changer pour une somme de contrôle SHA256.

Les entrées KEY listent toutees les clés que YaST doit importer du media. Ces clés peuvent être utilisés pour vérifier les signatures des RPM et des métadonnées et seront stockées dans la base de données des RPM afin de pouvoir être utilisées avec rpm --checksig pour la vérification des paquetages.

YaST fait confiance à ces entrées KEY car cette liste est dans un fichier qui a été signé par la clé initiale qui est autorisée par défaut par initrd.

La prochaine étape est le fichier "packages" dans DESCRDIR.

Si vous êtes familer avec sa syntaxe, vous verres qu'une nouvelle balise a été ajoutée après la balise "Pkg:". Voici un example des deux premières lignes pour le noyau par défaut. lines of the entry for the default kernel:

   =Pkg: kernel-default 2.6.16 13 i586
   =Cks: SHA1 8c8eb2b605e1d626c22bea8dd0c3b05885432b16

Ici encore, nous avons une somme de contrôle SHA1.

Par conséquent, il y a une chaîne complète de confiance depuis la clé initiale (que vous devez vérifier par vous même si vous n'avez pas confiance dans le merdia) jusqu'aux paquetages finaux en passant par les fichiers "product" et "contents. Cette chaîne assure que tous les fichiers font partie de l'installation et n'ont pas été modifiés.

Au niveau du paquetage, vous pouvez éventuellement faire un rpm --checksig supplémentaire.

Ajouter ses clés cryptographiques

YaST va automatiquement trouver les clés sur les media d'installation supplémentaires et proposer de les importer.

Le cas où vous souhaitez faire vos propre CDs d´installation est particulièrement intéressant. Quand l'installation démarre, la base de données des rpm n'est pas encore disponible pour importer des clés. Par conséquent, l'import n'est pas proposé.

Pour avoir vos clés publiques acceptées, il faut les mettre avec les clés principales. Elles peuvent être trouvées dans le "initial ramdisk" aussi connu sous le nom de "initrd" qui contient d'habitude /linxrc et les modules du noyau qui sont chargés avant de monter rootfs.

Ces initrds peuvent être trouvés sur le media dans /boot/architecture/loader/initrd (pour x86 et x86_64) ou dans /suseboot/initrd32 / initrd64 pour les PowerPC.

Pour ajouter une nouvelle clé digne de confiance à initrd, faîtes (en supposant que $initrd pointe vers votre initrd):

   gunzip <$initrd >$initrd.uncomp
   gpg --export -u $keyid > gpg-$keyid.gpg
   echo "gpg-$keyid.gpg" | cpio -o -H newc -A -F $initrd.uncomp
   gzip --best <$initrd.uncomp >$initrd
   rm $initrd.uncomp gpg-$keyid.gpg

Cela va décompresser le fichier initrd, ajouter la clé publique et le recompresser. Faîtes cela pour chacun des initrds situés sur le media (il peut y en avoir plusieurs.).

Le format "repomd" ou "YUM"

Le même concept de base est utilisé. Le fichier initial est "repomd.xml", qui est aussi signé avec une clé GPGdans "repomd.xml.asc".

Habituellement, les dépôts repomd sont utilisés pour les mises à jour et les paquetages supplémentaires. Par conséquent, les clés sont déjà connues du système. Mais vous pouvez placer la clé GPG publique pour signer "repomd.xml.asc" à côté de "repomd.xml.key".

Dans le cas où vous utilisez une nouvelle clé pour le dépôt qui n'est pas encore dans le RPM keyring, l'usager devra décider s'il accepte la clé avant que le dépôt soit enregistré.

Dans le fichier repomd.xml et tous les fichiers référencés à partir de lui, une basise <checksum> s'assure encore une fois que les sources sont cohérentes. Voici un example :

   
   <location href="repodata/patches.xml"/>
   <checksum type="sha">90ac427749079973d044a9398d6749f5f008</checksum>
   <timestamp>1144088097</timestamp>
   <open-checksum type="sha">90ac4044a9398d6749f5f008</open-checksum>
   

repomd utilise ces sommes de contrôle par défaut. La seule chose ajoutée est la signature du fichier "repomd.xml".

C'est très simple à faire:

      cd <repository directory>
      createrepo .
      gpg -a --detach-sign repodata/repomd.xml

Vous pouvez aussi utiliser -b au lieu de --detach-sign (plus court!).

Pour fournir votre clé GPG directement avec la source:

      gpg -a --export <your key id> > repodata/repomd.xml.key