Pacman 4 et la signature de paquets

Pacman 4.0 vient de passer de [testing] à [core] sur archlinux. Cette version apporte beaucoup de nouveautés mais surtout la signature des paquets.

Avertissement: si vous ne savez pas ce qu ’est gpg ou le principe de signature, allez lire ceci, un peu vieux mais toujours aussi accessible et valable.

L ’idée est de garantir, via la signature, que le paquet que l ’on télécharge a réellement été créé par le développeur et qu ’il n ’y a pas eu modification (pour insérer une backdoor au milieu par exemple). Seulement on ne veut pas importer la clef publique de chaque développeur et la signer, ça serait inefficace et il faudrait les vérifier une à une si l ’on voulait être sûr de sa validité (ce que franchement, personne ne fera). GPG utilise un système de web of trust pour la gestion des clefs qui revient plus ou moins à les amis de mes amis sont mes amis, vous ferrez confiance à une clef si elle a été signée par quelqu ’un à qui vous faites confiance.

Archlinux possède plusieurs catégories de personnes dans la communauté : les développeurs (responsables pour [core] et [extra]), les utilisateurs de confiance (responsables pour [community]) et les master-keys. Pour qu ’une clef soit acceptée, elle doit avoir été signée par au moins 3 des 5 master-keys. Chaque master possède un certificat de révocation pour la clef d ’un autre master. Ainsi aucune de ces 5 autorités de confiance n ’a un pouvoir absolu.

Pacman implémente donc désormais cette fonction de signature des paquets pour une sécurité accrue (et ça c ’est bien). Si votre pacman est bien configuré au départ, ça ne changera quasi rien pour vous. Les seules différences seront lorsqu ’il y aura un problème de sécurité (et vous serez alors content d ’avoir configuré pacman somme toute). Pour faire une comparaison avec les autres packages manager, les autres implémentent d ’habitude la vérification avec gpgv, qui suppose que toutes les clefs publiques importées dans votre keyring sont de confiance (bof) tandis que gpgme, utilisé dans pacman, supporte complètement le web of trust, si important pour ce genre de système. Les attaques les plus populaires sur les packages manager ont été empêchées avec, en plus, la signature des bases de données, la rétention de mise à jour sur des dépôts malicieux ou les flux de données sans fin (qui visiblement étaient possibles avant).

Par défaut la vérification des signatures est désactivé sur arch pour ne pas forcer à configurer le tout mais nous allons régler ça !

D ’abord assurez vous que vous possédez bien la version 4 de pacman avec un simple pacman -Qs ^pacman$. Une fois fait (mettez à jour sinon, pacman -Rtt pour les paquets en conflits style package-query), commencez par générer les trousseaux de clefs nécessaires avec pacman-key --init, vous possédez maintenant une jolie clef de 2048bits.

Ouvrez maintenant le fichier /etc/pacman.conf (après merge avec pacman.conf.new généré à la mise à jour) et réglez les paramètres SigLevel pour chaque dépot. Ce dernier vaut par défaut Never, on a le choix entre deux valeurs acceptables Optional et Requiered. La première veut dire vérifiez la signature si présente, acceptez sans signature s ’il n ’y en a pas. Si ce paramètre est acceptable pour la transition, on ne veut pas le garder et le changer dès que possible pour Required (obliger la vérification). Par défaut, une clef ne sera acceptée que si on la juge de confiance (autorité de confiance a signé le certificat par exemple), on ne va pas changer ça mais si jamais vous vouliez le faire (pour une raison x ou y), rajoutez TrustAll sur la même ligne (à la place du TrustedOnly sous-entendu).

Attention, tous les dépôts ne sont pas encore entièrement signés ! Pacman 4 est stable mais il reste quelques détails pratiques sous arch pour assurer que tout est bien fait. Tous les paquets de [core] sont signés mais pas tous dans [extra] ou [community] et, de plus, les bases de données de ces trois dépôts ne sont pas non plus signées. En attendant que ce soit fait, on va donc être un peu moins difficile. Toujours dans pacman.conf, mettez Optional en global et pour les dépôts PackageRequired, Optional et Optional respectivement pour [core], [extra] et [community].

Si vous essayez de télécharger un paquet maintenant, cela vous sera refusé car vous ne faites pas confiance aux clefs gpg utilisées.

(Je la refuse car je n ’ai pas envie de devoir faire ça un par un pour chaque développeur…)

Pour régler ceci, on va importer les clefs nécessaires. Si vous me faites confiance (attention il y a un piège), vous pouvez exécuter le script suivant (en tant que root).

Ceci va importer les 5 master-keys nécessaires dans votre keyring et leur donner la confiance marginal (3 signatures marginales sont requises pour faire confiance à une clef). Cependant, il est conseillé d ’aller vérifier chaque signature sur la page des mester-keys et de vérifier les fingerprints (pacman-key --finger des clefs. Bien sûr ça ne garantit pas que la page d ’archlinux ai été hackée mais ça réduit déjà le risque.

Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
Ionu? Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8

Malheureusement on y est pas encore. Vous avez ainsi les master-keys qui sont bien importantes mais il vous faut encore importer les clefs des développeurs et des trusted users. Cela se fait rapidement via

Notez que ce code ne fait qu ’importer les clefs, on ne les signe pas. Tout l’intérêt du wot est justement de ne pas devoir signer les clefs des développeurs, si une clef d ’un attaquant s ’est glissé dans cette liste, ce n ’est pas grave car elle n ’aura pas été signée par les master-keys. Lorsque l ’on télécharge un paquet, pacman vérifiera qui a signé le paquet, s ’il se trouve dans notre keyring et est valable (3 marginal). Si ces conditions ne sont pas remplies, vous recevrez une erreur et il faudra y regarder. Cas 1: un nouveau développeur ou un possédant une nouvelle clef, vous pouvez l ’importer, si elle est signée par 3 master-keys, ça passera. Cas 2: un attaquant a modifié une signature, importer la clef, elle sera refusée car invalide. De temps en temps (particulièrement si une mise à jour à échouée), vous pouvez rafraichir la base de donnée des clef via pacman-key —refresh-key.

Et vous voila avec un pacman bien sécurisé à l’abri des attaques principales sur la distribution de paquets ! Suivez bien l ’actualité archlinux pour savoir quand demander la signature de base de donnée et passer de Optional à Requiered partout (bon par contre pour aur, on est pas prêt d ’y arriver). J ’espère que ça vous a été utile !

[Source]

CC XKCD