Comment l'authenticité des paquets Debian est-elle garantie?


8

Quels systèmes et processus de sécurité sont en place pour empêcher des tiers malveillants de pirater / compromettre la sécurité du code dans les miroirs Debian, ou pour vérifier que les paquets que nous recevons sont bien ceux que les responsables pensent qu'ils sont?

Réponses:


14

Vérification des packages

Le contenu des miroirs est signé à l'aide de clés PGP, directement ou indirectement. À partir de la "racine" d'une distribution Debian:

  • Release, signé avec une signature détachée dans Release.gpg, contient les hachages (MD5, SHA1, SHA256) de tous les index de packages et hachages d'installation ( InReleasecombine désormais les deux);
  • les indices de paquet ( par exemple , binary-amd64) contiennent les hash (MD5 et SHA256) des paquets.

Les hachages et les signatures sont vérifiés par des outils tels que l' apt-getutilisation de clés PGP stockées sur le système (gérées par apt-key). Donc, tant que le système de réception est sain, par défaut aucun paquet ne peut être installé à partir des archives Debian s'il n'a pas été signé (indirectement) par la clé PGP de l'archive. Les intrus sur les miroirs ne pourraient pas remplacer les binaires s'ils n'avaient pas également le contrôle de la clé PGP appropriée.

Contrôle des miroirs

Cela signifie que compromettre l'archive n'est pas suffisant pour compromettre réellement les systèmes des utilisateurs finaux; vous devez également compromettre une clé PGP à laquelle ces systèmes font déjà confiance. (Un corollaire à cela est que l'ajout d'une clé à un système Debian n'est pas quelque chose à prendre à la légère.) Cela répond dans une certaine mesure à votre première question, car la sécurité des archives n'a pas tellement d'importance. Néanmoins, les systèmes critiques (où la signature a lieu) sont strictement surveillés et supervisés, et très peu de personnes y ont accès.

Attentes du responsable

S'assurer que les packages sont «en fait ceux que les responsables pensent qu'ils sont» est un peu plus complexe. Voici le chemin emprunté par un package:

  • le paquet est préparé par un responsable et signé avec une clé dans le trousseau de clés Debian ( c'est-à - dire une clé appartenant à un développeur Debian téléchargeant, ou un mainteneur Debian, téléchargée sur le serveur de trousseaux Debian et fusionnée par l'équipe de maintenance des trousseaux);
  • le package signé est téléchargé dans l'archive, où il est vérifié (entre autres, les clés utilisées doivent être dans le trousseau de clés actuel et ne doivent pas avoir expiré, les signatures doivent être valides, et si le package a été signé par un DM, que DM doit avoir les autorisations appropriées pour le package);
  • tous les binaires téléchargés sont poussés vers l'archive finale tels quels (je simplifie un peu ici, mais c'est l'effet);
  • tous les binaires manquants sont construits par un buildd et signés par la clé PGP du buildd, et poussés vers l'archive finale (qui sait quelles clés buildd sont valides et vérifie les fichiers par rapport à ceux-ci);
  • toutes ces mises à jour sont finalement envoyées au réseau miroir, avec les mises à jour d'index appropriées (qui sont signées comme décrit ci-dessus).

Si le responsable télécharge des fichiers binaires avec la source du package, ce sont les fichiers qui finissent par être servis (pour le moment). Étant donné que le téléchargement de fichiers binaires est désormais facultatif, il est de plus en plus courant de les ignorer, et les fichiers binaires téléchargés seront finalement supprimés. (Cela a toujours été le cas dans Ubuntu.) Le fait que les autres binaires correspondent aux attentes du responsable dépend du réseau buildd; les buildds sont donc aussi des systèmes critiques, sous étroite surveillance et avec peu d'accès humain. Puisque tous les artefacts sont signés, il est toujours possible de vérifier l'intégrité des fichiers: d'abord contre la clé du responsable, puis contre les clés des buildds, et enfin contre la clé de l'archive.

Comme indiqué par plugwash , les signatures originales ne sont pas disponibles sur les miroirs, et tout DD peut télécharger un binaire manquant. Les signatures originales peuvent être récupérées dans les archives debian-devel-changes .

En résumé , bien que le système actuel ne soit pas parfait, il offre une traçabilité pour tous les fichiers que vous pouvez télécharger à partir des miroirs. Il y a un certain nombre d'efforts pour améliorer la situation: versions reproductibles (qui permettront une vérification indépendante de la correspondance des binaires avec la source publiée), suppression des binaires fournis par le responsable ...


Admirablement complet, mais vous auriez également pu raisonnablement dire à l'affiche de s'en aller et de lire la documentation. :-)
Faheem Mitha

@FaheemMitha J'ai hésité, mais quelle documentation? Il y a wiki.debian.org/SecureApt mais il ne couvre pas tout ... Assembler tout cela est assez complexe, à moins qu'il y ait une autre documentation que je ne connais pas!
Stephen Kitt

Les systèmes d'exploitation Debian que les utilisateurs exécutent ont-ils donc des clés PGP publiques pré-intégrées - qui sont couplées aux clés privées sur les systèmes critiques (là où la signature a lieu) - et apt-getvérifient les packages en utilisant ces clés locales pré-intégrées, car il leur fait confiance?
the_velour_fog

1
@the_velour_fog oui, c'est (presque) vrai; les clés publiques sont expédiées dans le debian-archive-keyringcolis. apt-getvérifie les Releasefichiers à l'aide de ces clés et les packages à l'aide des hachages contenus dans les fichiers Releaseet Packages.
Stephen Kitt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.