Les référentiels RPM volumineux et populaires sont généralement répliqués dans le monde entier. Les projets et les entreprises fournissant les forfaits utilisent des réseaux de distribution de contenu (CDN) et des sites miroirs pour mettre leurs forfaits à la disposition des consommateurs. Pour de nombreux projets open source, cela inclut l'hébergement par des bénévoles. Pour détecter et éviter les packages de remplacement malveillants, les propriétaires de packages peuvent signer les fichiers de package et les consommateurs peuvent vérifier ces signatures.
Bien que GPG puisse signer n'importe quel fichier, la vérification manuelle des signatures de packages n'est pas évolutive pour les administrateurs système. Le format RPM a une zone spécifiquement réservée pour contenir une signature de l'en-tête et de la charge utile. Le rpm L'utilitaire utilise des clés GPG pour signer les packages et sa propre collection de clés publiques importées pour vérifier les packages. YUM et DNF utilisent des fichiers de configuration de référentiel pour fournir des pointeurs vers les emplacements de clés publiques GPG et aider à importer les clés afin que RPM puisse vérifier les packages.
Pour cet article, j'utiliserai des clés et des packages d'EPEL. La clé publique est incluse dans un package RPM, qui configure également le yum repo . Pour certains projets, la clé peut également être disponible directement à partir d'un site Web source.
L'utilitaire rpm a sa propre gestion des clés
Depuis le rpm L'utilitaire dispose de sa propre gestion des clés, il n'est pas nécessaire d'importer les clés publiques GPG dans votre trousseau de clés GPG personnel. En fait, vous ne pouvez pas simplement vérifier le fichier avec gpg commandes car la signature ne correspond pas à l'intégralité du fichier .rpm. Au lieu de cela, la signature est uniquement associée aux parties critiques du package.
Exécutez la commande suivante pour utiliser rpm pour vérifier un paquet :
$ rpm -K epel-release-latest-8.noarch.rpm
epel-release-latest-8.noarch.rpm: digests SIGNATURES NOT OK
Dans ce cas, le message "SIGNATURES NOT OK" s'affiche car la clé n'a pas encore été importée pour RPM. Le comportement par défaut de rpm est de vérifier la signature des packages lors de toute installation ou de vérifier les interactions. Si cela n'est pas possible, parce que le package n'est pas signé ou que la clé publique n'est pas disponible, vous devrez peut-être spécifier le --nogpgcheck option pour ignorer cette étape.
Si vous avez accès à la clé publique GPG, vous pouvez utiliser la commande suivante pour importer manuellement une clé :
$ rpm --import RPM-GPG-KEY-EPEL-8 Étant donné que les métadonnées de la clé sont stockées dans la base de données RPM, vous pouvez interroger et supprimer des clés de la même manière que n'importe quel package.
Utilisez la commande suivante pour lister les clés :
$ rpm -qa gpg-pubkey*
gpg-pubkey-7fac5991-4615767f
gpg-pubkey-2f86d6a1-5cf7cefb Utilisez cette commande pour obtenir les informations sur une clé :
$ rpm -qi gpg-pubkey-2f86d6a1-5cf7cefb
Name : gpg-pubkey
Version : 2f86d6a1
Release : 5cf7cefb
Architecture: (none)
Install Date: Mon 01 Jun 2020 12:14:38 PM EDT
Group : Public Keys
Size : 0
License : pubkey
Signature : (none)
Source RPM : (none)
Build Date : Wed 05 Jun 2019 10:17:31 AM EDT
Build Host : localhost
Relocations : (not relocatable)
Packager : Fedora EPEL (8) <[email protected]>
Summary : gpg(Fedora EPEL (8) <[email protected]>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.14.2 (NSS-3)
...omitted... La commande suivante permet de supprimer une clé :
$ sudo rpm -e gpg-pubkey-2f86d6a1-5cf7cefb
Plus d'options pour la gestion des clés sont décrites dans la page de manuel incluse avec le rpmkey paquet.
YUM et DNF peuvent ajouter des clés à la base de données RPM
D'autres gestionnaires de packages facilitent encore la gestion des clés. YUM et DNF utilisent des fichiers de configuration dans /etc/yum.repos.d pour spécifier une URL pour la clé GPG utilisée pour vérifier les packages dans ce référentiel. Les utilitaires peuvent alors importer la clé si elle n'est pas déjà disponible pour vérification.
Dans le yum repo fichier de configuration, la ligne gpgcheck=1 indique que la vérification GPG doit être effectuée pour tous les packages de ce référentiel. Il s'agit d'une valeur booléenne qui peut être modifiée dans la configuration ou remplacée temporairement sur la ligne de commande avec le --nogpgcheck option.
Si la clé publique GPG n'a pas encore été importée dans RPM lorsqu'une installation de paquet commence, alors le yum (ou dnf ) peut lancer une importation de la clé. Le gpgkey=URI ligne spécifie la source de la clé à importer. Cette source peut être n'importe quel URI, y compris un fichier local ou un lien Web distant. Le yum ou dnf l'utilitaire s'arrêtera et demandera une confirmation pour importer la clé après avoir montré l'ID de la clé et l'empreinte digitale.
warning: /var/cache/dnf/epel-fafd94c310c51e1e/packages/zsh-syntax-highlighting-0.7.1-1.el8.noarch.rpm: Header V3 RSA/SHA256 Signature, key ID 2f86d6a1: NOKEY
Extra Packages for Enterprise Linux 8 - x86_64 1.6 MB/s | 1.6 kB 00:00
Importing GPG key 0x2F86D6A1:
Userid : "Fedora EPEL (8) <[email protected]>"
Fingerprint: 94E2 79EB 8D8F 25B2 1810 ADF1 21EA 45AB 2F86 D6A1
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
Is this ok [y/N]: y La clé est ajoutée à RPM, puis la vérification et l'installation du package se poursuivent.
Préparez-vous à signer un colis
Si vous créez et distribuez vos propres fichiers de package RPM, vous pouvez signer ces packages avec le rpmsign utilitaire.
La première étape consiste à créer une paire de clés GPG pour la signature. Assurez-vous également d'exporter et de partager la clé publique. Pour les packages qui seront distribués publiquement, il est judicieux d'utiliser une nouvelle paire de clés et un trousseau de clés dans un emplacement partagé. De plus, utilisez le --full-gen-key puis choisissez de créer une clé de signature uniquement au lieu de la clé par défaut, qui crée à la fois une clé de signature et une clé de chiffrement.
$ gpg --keyring /shared/rpm/.gpg --no-default-keyring --full-gen-key Même si une seule personne utilise la clé pour signer les packages, créez une paire de clés distincte à utiliser pour la signature. N'utilisez pas la même clé pour d'autres tâches quotidiennes telles que le chiffrement des e-mails personnels.
Ensuite, nous devons installer le rpm-sign package et configurez un rpmmacros fichier spécifiant la clé à utiliser. Le rpm-sign le paquet inclut une page de manuel pour rpmsign qui décrit le processus. Notez que le nom du package comporte un tiret qui ne fait pas partie du nom de la commande.
$ sudo yum install rpm-sign
$ man rpmsign
Les commandes RPM obtiennent leur configuration de plusieurs rpmmacros des dossiers. Il existe un fichier par défaut avec de nombreux exemples situés dans /usr/lib/rpm/macros . Si plusieurs personnes sont responsables de la signature des packages à l'aide de la même clé, placez un fichier de configuration central dans /etc/rpm/macros emplacement. Enfin, pour une personne spécifique signant les packages, le ~/.rpmmacros de l'utilisateur le fichier peut être configuré pour pointer vers la bonne clé GPG.
L'entrée minimale pour les rpmmacros fichier est de spécifier le nom de la clé. Vous pouvez utiliser un nom ou l'ID de clé. Obtenez l'ID de la clé avec le gpg --list-keys commande.
Astuce :Exécutez le rpmsign commande avant de définir le gpg_name variable et le message affichera le format.
$ rpmsign --addsign my-custom-package.rpm
You must set "%_gpg_name" in your macro file
En plus du nom de la clé, si le trousseau de clés est autre que l'utilisateur par défaut ~/.gnupg répertoire, utilisez le gpg_path variable pour définir l'emplacement. Cette valeur sera la même que celle utilisée avec le --keyring lors de la création de la clé.
Des options supplémentaires sont disponibles si la syntaxe binaire ou de commande GPG nécessite quelque chose au-delà des valeurs par défaut attendues.
Signer et publier des packages
Vous êtes maintenant prêt à signer le ou les packages. Selon le rpmsign page de manuel, le --addsign et --resign les commandes sont interchangeables. Les deux remplaceront la partie signature d'un fichier de package RPM par les informations actuelles.
La commande suivante est un exemple d'utilisation de --addsign drapeau :
$ rpmsign --addsign myprod-2.x86_64.rpm myprod-libs-2.x86_64.rpm
Anciennes versions de rpmbuild inclus un --sign option qui pourrait signer le paquet pendant le processus de construction si les clés GPG et rpmmacro les fichiers ont été configurés correctement. Le --sign l'option est désormais obsolète au profit de l'étape distincte d'utilisation de rpmsign . Cette approche encourage un construire, tester, signer, publier flux de travail.
Enfin, mettez les packages et la clé publique GPG à la disposition des clients. Une option consiste à imiter le projet EPEL et à créer un fichier RPM qui inclut la clé publique GPG et un ou plusieurs yum repo fichiers pointant vers l'emplacement des packages signés. Pour les organisations hébergeant des packages sur un serveur Red Hat Satellite, commencez par télécharger la clé publique GPG, puis affectez cette clé au produit ou au référentiel qui contient les packages signés. Tous les packages d'un référentiel doivent être signés avec la même clé. C'est une raison courante pour les administrateurs Satellite de démissionner des packages avant de les télécharger.
Conclusion
Maintenant que vous en savez plus sur la gestion des packages RPM avec GPG, vous pouvez mieux comprendre comment travailler avec rpm , yum , et dnf .
Pour en savoir plus, consultez Sécurisation des clés de signature RPM et les guides d'administration et de gestion de contenu dans la documentation de Red Hat Satellite.
[ Vous voulez en savoir plus sur la sécurité ? Consultez la liste de vérification de la sécurité informatique et de la conformité. ]