pacman (Français)/Package signing (Français)
Un paquet peut devenir malveillant (nous considérons que les sources originales sont sûres) soit intentionnellement, soit involontairement. Dans le premier cas, l'empaqueteur prépare le paquet (en modifiant les sources, en ajoutant des scripts, en modifiant les scripts de construction) avec l'intention de nuire au système ou aux données de l'utilisateur. Dans le second cas, l'empaqueteur, par erreur ou omission, crée le paquet qui, s'il est installé, met le système de l'utilisateur en danger.
Un paquet malveillant peut entrer dans l'univers des paquets lorsque l'empaqueteur le fournit directement ou le place dans un dépôt ou un miroir légitime. Le niveau de menace dépend ici de ce que le logiciel contenu dans le paquet peut faire et de la popularité du paquet. La première qualité peut être déterminée par une inspection minutieuse du paquet et de son contenu (ainsi que par l'exécution du logiciel dans un environnement de test). La seconde peut être estimée en se basant sur les statistiques de téléchargement (en supposant que le paquet téléchargé est le paquet installé).
Ainsi, pour déterminer si les paquets sont authentiques, pacman utilise les clés GnuPG dans un modèle de toile de confiance («web of trust»). Les clés de signature principales actuelles se trouvent ici. Au moins trois de ces clés de signature principales sont utilisées pour signer les clés du développeur et de l'utilisateur de confiance. Elles sont ensuite utilisées pour signer leurs paquets. Chaque utilisateur possède également une clé PGP unique, qui est générée lorsque vous configurez pacman-key. C'est ce réseau de confiance qui relie la clé de l'utilisateur aux clés maîtresses.
Exemples de réseaux de confiance :
- Paquets personnalisés : Paquets créés et signés avec une clé locale.
- Paquets non officiels : Paquets faits et signés par un développeur. Ensuite, une clé locale était utilisée pour signer la clé du développeur.
- Paquets officiels : paquets réalisés et signés par un développeur. La clé du développeur a été signée par les clés maîtresses d'Arch Linux. Vous avez utilisé votre clé pour signer les clés maîtresses, et vous leur faites confiance pour se porter garant des développeurs.
Configuration
Configuration de pacman
L'option SigLevel dans /etc/pacman.conf détermine le niveau de confiance requis pour installer un paquet avec pacman -S. Pour une explication détaillée de SigLevel, consultez pacman.conf(5) § PACKAGE AND DATABASE SIGNATURE CHECKING, et les commentaires du fichier. On peut définir la vérification des signatures globalement ou par dépôt. Si SigLevel est défini globalement dans la section [options], tous les paquets installés avec pacman -S devront être signés. Avec le paramètre LocalFileSigLevel du fichier par défaut pacman.conf, tous les paquets que vous construisez et installez avec pacman -U, n'auront pas besoin d'être signés avec makepkg.
Required est défini, alors DatabaseOptional doit également être défini.Pour les paquets distants, la configuration par défaut ne prendra en charge que l'installation de paquets signés par des clés de confiance :
/etc/pacman.conf
SigLevel = Required DatabaseOptional
TrustedOnly est un paramètre compilé par défaut dans pacman. La configuration par défaut est identique à l'utilisation de l'option globale de :
SigLevel = Required DatabaseOptional TrustedOnly
Ce qui précède peut également être réalisé au niveau du dépôt, plus bas dans la configuration, par exemple :
[core] SigLevel = PackageRequired Include = /etc/pacman.d/mirrorlist
ajoute explicitement la vérification de la signature pour les paquets du dépôt, mais n'exige pas que la base de données soit signée. Optional ici désactiverait un Required global pour ce dépôt.
TrustAll existe à des fins de débogage et permet de faire confiance très facilement à des clés qui n'ont pas été vérifiées. Vous devriez utiliser TrustedOnly pour tous les dépôts officiels.Initialisation du trousseau de clés
Pour initialiser le trousseau de clés de pacman, exécutez :
# pacman-key --init
L'initialisation du porte-clés nécessite de l'entropie. Pour générer de l'entropie, déplacez votre souris, tapez des caractères aléatoires sur le clavier ou lancez une activité sur disque (par exemple dans une autre console en exécutant ls -R / ou find / -name foo ou dd if=/dev/sda8 of=/dev/tty7). Si votre système ne dispose pas déjà d'une entropie suffisante, cette étape peut prendre des heures ; si vous générez activement de l'entropie, elle se terminera beaucoup plus rapidement.
Le caractère aléatoire créé est utilisé pour initialiser le trousseau de clés (/etc/pacman.d/gnupg) et la clé de signature GPG de votre système.
pacman-key --init sur un ordinateur qui ne génère pas beaucoup d'entropie (par exemple, un serveur sans tête), la génération de la clé peut prendre beaucoup de temps. Pour générer de la pseudo-entropie, installez haveged ou rng-tools sur la machine cible et démarrez le service correspondant avant d'exécuter pacman-key --init.Gestion du trousseau
Vérification des clés maîtresses
La configuration initiale des clés est réalisée en utilisant :
# pacman-key --populate archlinux
Prenez le temps de vérifier les Clés de signature maîtresses lorsque vous y êtes invité car elles sont utilisées pour co-signer (et donc faire confiance) aux clés de tous les autres paquets.
Les clés PGP sont trop grandes (2048 bits ou plus) pour que les humains puissent travailler avec, elles sont donc généralement hachées pour créer une empreinte digitale de 40 chiffres hexadécimaux qui peut être utilisée pour vérifier à la main que deux clés sont identiques. Les huit derniers chiffres de l'empreinte digitale servent de nom à la clé, appelé " ID de clé (court) " (les seize derniers chiffres de l'empreinte digitale seraient l'" ID de clé long ").
Ajout de clés de développeur
Les clés officielles de développeur et de Trusted Users (TU) sont signées par les clés maîtresses, vous n'avez donc pas besoin d'utiliser pacman-key pour les signer vous-même. Lorsque pacman rencontre une clé qu'il ne reconnaît pas, il vous demandera de la télécharger depuis un keyserver configuré dans /etc/pacman.d/gnupg/gpg.conf. (ou en utilisant l'option --keyserver sur la ligne de commande). Wikipedia maintient une liste de serveurs de clés.
Une fois que vous avez téléchargé une clé de développeur, vous n'aurez pas à la télécharger à nouveau, et elle peut être utilisée pour vérifier tout autre paquet signé par ce développeur.
pacman-key --refresh-keys (en tant que root). Lors de l'exécution de --refresh-keys, votre clé locale sera également recherchée sur le serveur de clés distant, et vous recevrez un message indiquant qu'elle n'a pas été trouvée. Il n'y a pas lieu de s'en inquiéter.Ajout de clés non officielles
Cette méthode peut être utilisée pour ajouter une clé au trousseau de clés pacman, ou pour activer des dépôts signés dépôts d'utilisateurs non officiels.
Tout d'abord, obtenez l'ID de la clé. (keyid) de son propriétaire. Ensuite, ajoutez-la au trousseau en utilisant l'une des deux méthodes suivantes :
- Si la clé est trouvée sur un serveur de clés, importez-la avec :
# pacman-key --recv-keys keyid
- Si un lien vers un fichier de clé est fourni, téléchargez-le et exécutez :
# pacman-key --add /path/to/downloaded/keyfile
Il est recommandé de vérifier l'empreinte digitale, comme pour toute clé principale ou toute autre clé que vous allez signer :
$ pacman-key --finger keyid
Enfin, vous devez signer localement la clé importée :
# pacman-key --lsign-key keyid
Vous avez maintenant confiance en cette clé pour signer les paquets.
Débogage avec gpg
Pour des raisons de débogage, vous pouvez accéder au trousseau de clés de pacman directement avec gpg, par exemple :
# gpg --homedir /etc/pacman.d/gnupg --list-keys
Trucs et astuces
Mettre le système à jour régulièrement
La mise à jour régulière du système via Pacman (Français)#Mise à jour des paquets permet d'éviter la plupart des erreurs de signature. Si un retard est inévitable et que la mise à jour du système est retardée pendant une période prolongée, synchronisez manuellement la base de données des paquets et mettez à jour le paquet archlinux-keyring avant la mise à jour du système :
# pacman -Sy archlinux-keyring && pacman -Su
Cette commande n'est pas considérée comme entraînant des mises à jour partielles puisqu'elle synchronise la base de données des paquets et met à jour le paquet keyring en premier. Les deux doivent être traités juste avant de commencer la mise à jour du système pour s'assurer que les signatures de tous les paquets mis à jour peuvent être correctement vérifiées.
Mise à jour régulière de l'heure du système
Lorsque l'heure du système est défectueuse, les clés de signature peuvent être considérées comme expirées (ou invalides) et la vérification des signatures des paquets échouera. Synchronisez régulièrement l'horloge du système en utilisant le daemon Network Time Protocol.
Dépannage
Erreurs de signature invalide
pacman-key dépend de l'heure du système. Si l'horloge de votre système n'est pas synchronisée, l'installation/mise à jour du système peut échouer avec :
error: PackageName: signature from "User <[email protected]>" is invalid error: failed to commit transaction (invalid or corrupted package (PGP signature)) Errors occurred, no packages were upgraded.
Si vous utilisez ntpd, corrigez l'heure du système (en tant que root) avec ntpd -qg suivi de hwclock -w.
D'autres clients NTP peuvent être utilisés. Consultez synchronisation du temps.
Si la correction de l'horloge système ne résout pas le problème, essayez l'une des approches suivantes :
Suppression de paquets du cache
Certains paquets peuvent être corrompus ou non signés, ce qui provoque l'échec. Supprimez chaque paquet incriminé du cache système rm /var/cache/pacman/pkg/pkgname afin qu'il soit fraîchement téléchargé, ou nettoyez tout le cache.
Réinitialisation de toutes les clés
Supprimez ou réinitialisez toutes les clés installées sur votre système en supprimant le répertoire /etc/pacman.d/gnupg (en tant que root) et en réexécutant pacman-key --init suivi de pacman-key --populate archlinux pour réinstaller les clés par défaut.
Désactiver la vérification des signatures
Si vous n'êtes pas concerné par la signature des paquets, vous pouvez désactiver complètement la vérification des signatures PGP. Éditez /etc/pacman.conf et pour obtenir les lignes suivante sous [options] :
SigLevel = Never #LocalFileSigLevel = Optional #RemoteFileSigLevel = Required
Vous devez commenter tous les paramètres SigLevel spécifiques au dépôt car ils remplacent les paramètres globaux. Il n'y aura pas de vérification de signature, ce qui était le comportement avant pacman 4. Si vous faites cela, vous n'avez pas besoin de configurer un trousseau de clés avec pacman-key. Vous pouvez changer ces options plus tard si vous décidez d'activer la vérification des paquets.
Impossible d'importer des clés
Il y a plusieurs sources possibles de ce problème :
- Un paquet archlinux-keyring périmé.
- Une date incorrecte.
- Votre FAI a bloqué le port utilisé pour importer les clés PGP.
- Votre cache pacman contient des copies de paquets non signés provenant de tentatives précédentes.
-
dirmngrn'est pas correctement configuré - Vous n'avez pas effectué de mise à jour depuis longtemps et gpg/pacman ne le gère pas bien.
Vous pouvez être bloqué à cause d'un paquet archlinux-keyring périmé lors d'une synchronisation de mise à jour.
Vous trouverez ci-dessous quelques solutions qui pourraient fonctionner selon votre cas.
Mettre à jour le système
Vérifiez si une mise à jour du système peut résoudre le problème en premier.
Changer le serveur de clés
Si vous pensez que quelque chose ne fonctionne pas correctement avec le serveur de clés, vous pouvez essayer de passer au serveur de clés d'Ubuntu. Pour cela, éditez /etc/pacman.d/gnupg/gpg.conf et changez la ligne keyserver en :
keyserver hkp://keyserver.ubuntu.com
Nettoyer les paquets mis en cache
Si vous pensez que votre cache de pacman à /var/cache/pacman/pkg/ contient des paquets non signés, essayez de nettoyer le cache manuellement ou exécutez :
# pacman -Sc
qui supprime tous les paquets en cache qui n'ont pas été installés.
La signature est de confiance inconnue
Parfois, en exécutant pacman -Syu, vous pouvez rencontrer cette erreur :
error: package-name: signature from "packager" is unknown trust
Cela se produit parce que la clé du packager utilisée dans le paquet package-name n'est pas présente et/ou n'est pas fiable dans la base de données gpg locale pacman-key. Pacman ne semble pas toujours être capable de vérifier si la clé a été reçue et marquée comme fiable avant de continuer. Cela peut également être dû au fait qu'une clé a expiré depuis qu'elle a été ajoutée à votre trousseau de clés.
Compensez en :
- Rafraîchissant vos clés avec
pacman-key --refresh-keys, ou - signant manuellement la clé non fiable localement, ou
- réinitialisant toutes les clés, ou
- Définissant temporairement
SigLevelàTrustAll(non recommandé).
Mise à jour des clés via un proxy
Afin d'utiliser un proxy lors de la mise à jour des clés, l'option honor-http-proxy doit être définie à la fois dans /etc/gnupg/dirmngr.conf et /etc/pacman.d/gnupg/dirmngr.conf. Consultez GnuPG#Use a keyserver pour plus d'informations.
honor-http-proxy et échoue, un redémarrage peut résoudre le problèmePaquets malveillants
Il n'y a aucun moyen d'empêcher les empaqueteurs de forger intentionnellement des paquets qui peuvent faire de mauvaises choses au système de l'utilisateur et de les fournir sur leurs propres dépôts. Il existe cependant un moyen d'inciter les utilisateurs à être plus prudents lorsqu'ils téléchargent des paquets en dehors des dépôts officiels, car un empaqueteur malveillant devra convaincre les utilisateurs de télécharger son paquet. Il fait la publicité d'un logiciel riche en fonctionnalités qui offre "sécurité, vitesse, facilité d'utilisation", absent des dépôts officiels. Une chance de contrer ces efforts est d'éduquer les utilisateurs à n'utiliser les paquets en dehors des dépôts officiels que si cela est absolument nécessaire (au moins jusqu'à ce qu'un moyen de prévenir les dommages potentiellement causés par ces logiciels ne soit pas conçu au niveau du système).
Les paquets dangereux peuvent également être injectés au niveau du miroir. Rendre ce niveau plus sûr est dans les mains des administrateurs de miroirs principalement, mais il y a aussi une chose ou deux qu'Arch peut faire pour les aider. Les paquets téléchargés peuvent être vérifiés de la même manière qu'ils le seraient sur la machine de l'utilisateur. Cela demandera un peu de puissance de traitement du côté du serveur mais, espérons-le, assez peu pour le faire.
Enfin, les paquets peuvent être signés et leurs signatures vérifiées automatiquement, ce qui, en liaison avec la base de données fournie des empaqueteurs de confiance, réduira la possibilité d'installer un paquet dangereux provenant d'une source non fiable.
Arch Linux a une base d'utilisateurs relativement petite et éduquée, ce qui en fait une cible peu probable d'attaques malveillantes basées sur des paquets, mais cela ne signifie pas que les lacunes évidentes en matière de sécurité ne doivent pas être comblées, surtout lorsqu'on parle de sécurité des paquets.