[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]


Securing Debian Manual
Chapitre 7 - Infrastructure de sécurité Debian


7.1 L'équipe de sécurité Debian

Debian possède une équipe de sécurité, qui assure la sécurité dans la distribution stable. Assurer la sécurité veut dire suivre les failles qui surviennent dans les logiciels (en surveillant des forums comme Bugtraq ou vuln-dev) et déterminer si la distribution stable est concernée par ces failles.

L'équipe de sécurité Debian est également le point de contact pour les problèmes qui sont coordonnés par les développeurs amont ou des organisations comme le CERT, qui peuvent toucher de multiples distributeurs, c'est-à-dire quand les problèmes ne sont pas spécifiques à Debian. Le point de contact avec l'équipe de sécurité est team@security.debian.org qui n'est lu que par les membres de l'équipe de sécurité.

Les informations secrètes devraient être envoyées à la première adresse et, dans certains cas, devraient être chiffrées avec la clef du contact de l'équipe de sécurité (disponible dans le trousseau Debian).

Dès qu'un problème probable est reçu par l'équipe de sécurité, elle recherchera si la distribution stable est affectée et si c'est le cas, un correctif sera créé pour la base de code source. Ce correctif contiendra parfois un rétroportage du correctif effectué en amont (qui est habituellement en avance de plusieurs versions par rapport à la version distribuée par Debian). Après qu'un test du correctif ait été effectué, les nouveaux paquets sont préparés et publiés sur le site http://security.debian.org pour pouvoir être récupérés par apt (consultez Faire une mise à jour de sécurité, Section 4.2). En même temps, une alerte de sécurité Debian (Debian Security Advisory ou DSA) est publiée sur le site web et envoyée aux listes de diffusion publiques y compris debian-security-announce et Bugtraq.

D'autres questions souvent posées sur l'équipe de sécurité Debian peuvent être trouvées en Questions concernant l'équipe de sécurité Debian, Section 12.3.


7.2 Alertes de sécurité Debian

Les alertes de sécurité Debian (DSA) sont effectuées à chaque fois qu'une faille affectant un paquet Debian est découverte. Ces alertes, signées par l'un des membres de l'équipe de sécurité, contiennent des renseignements sur les versions touchées ainsi que l'emplacement des mises à jour. Ces informations sont :

Les DSA sont publiées sur la page principale de Debian et dans les pages de sécurité Debian. Cela ne se produit habituellement pas avant que le site web ne soit reconstruit (toutes les quatre heures), elles peuvent donc ne pas être immédiatement présentes. Le canal préféré est la liste de diffusion debian-security-announce.

Les utilisateurs intéressés peuvent, cependant (et c'est fait sur quelques portails relatifs à Debian) utiliser le flux RDF pour télécharger automatiquement les DSA sur leur bureau. Certaines applications, comme Evolution (un client de messagerie et assistant d'informations personnelles) et Multiticker (une applette GNOME) peuvent être utilisées pour récupérer les alertes automatiquement. Le flux RDF est disponible à http://www.debian.org/security/dsa.rdf.

Les DSA publiées sur le site web peuvent être mises à jour après avoir été envoyées sur les listes de diffusion publiques. Une mise à jour courante est d'ajouter des références croisées vers les bases de données des failles de sécurité. Les traductions[53] des DSA ne sont pas envoyées aux listes de diffusion de sécurité, mais elles sont directement intégrées au site web.


7.2.1 Références croisées des failles

Debian fournit une table de références croisées complète comprenant toutes les références disponibles pour toutes les alertes publiées depuis 1998. Cette table est fournie en complément de la carte des références disponible pour le CVE.

Vous remarquerez que cette table fournit des références vers des bases de données de sécurité comme Bugtraq, les alertes CERT/CC et la base de données des notes de failles US-CERT ainsi que les noms CVE (voir ci-dessous). Ces références sont fournies pour faciliter l'utilisation, mais seules les références CVE sont périodiquement vérifiées et intégrées.

Les avantages d'ajouter les références croisées vers ces bases de données de failles sont que :


7.2.2 Compatibilité CVE

Les alertes de sécurité Debian ont été déclarées comme étant compatibles CVE[54] le 24 février 2004.

Les développeurs Debian comprennent la nécessité de fournir une information précise et à jour de l'état de sécurité de la distribution Debian, permettant aux utilisateurs de gérer le risque associé aux nouvelles failles de sécurité. CVE nous permet de fournir des références standardisées qui permettent aux utilisateurs de développer un processus de gestion de sécurité avec CVE.

Le projet Common Vulnerabilities and Exposures (CVE) est maintenu par la société MITRE et fournit une liste des noms standardisés pour les failles et expositions de sécurité.

Debian estime que fournir aux utilisateurs des informations supplémentaires liées aux problèmes de sécurité qui touchent la distribution Debian est extrêmement important. L'inclusion des noms CVE dans les alertes aide les utilisateurs à associer des failles génériques avec les mises à jour spécifiques de Debian, ce qui réduit le temps passé à gérer les failles qui concernent nos utilisateurs. Cela facilite également la gestion du risque dans un environnement où sont déployés des outils de sécurité gérant CVE — comme des systèmes de détection d'intrusion d'hôte ou de réseau ou des outils de vérification de failles — qu'ils soient ou non basés sur la distribution Debian.

Debian fournit maintenant les noms CVE pour toutes les DSA publiées depuis septembre 1998. Toutes les alertes peuvent être récupérées sur le site web Debian et les annonces liées aux nouvelles failles contiennent les noms CVS quand ils sont disponibles lors de leur publication. Les alertes liées à un nom CVE donné peuvent être cherchées directement avec le système de suivi en sécurité Debian (voir ci-après).

Dans certains cas, vous pouvez ne pas trouver un nom CVE donné dans les alertes publiées par exemple parce que :


7.3 Système de suivi en sécurité

La base de donnée centralisée de ce que les équipes de sécurité Debian connaissent des vulnérabilités est le système de suivi en sécurité Debian. Elle rassemble les références de paquets, les versions vulnérables et corrigées pour chaque suite, les noms CVE, les numéros de bogue Debian, les notes de DSA et autres. Elle peut être consultée, par exemple, à l'aide du nom CVE pour voir les paquets Debian affectés ou corrigés, ou par paquet pour montrer les problèmes de sécurité non résolus. Les seuls renseignements manquants au système de suivi sont les informations confidentielles que l'équipe de sécurité reçoit sous embargo.

Le paquet debsecan utilise les renseignements du système de suivi pour signaler à l'administrateur d'un système les paquets installés vulnérables, et ceux pour lesquels des mises à jour corrigeant les problèmes de sécurité sont disponibles.


7.4 Infrastructure de construction de sécurité Debian

Comme Debian prend actuellement en charge un grand nombre d'architectures, les administrateurs se demandent parfois si une architecture donnée pourrait prendre plus de temps pour recevoir des mises à jour de sécurité qu'une autre. En fait, à part dans de rares circonstances, les mises à jour sont disponibles pour toutes les architectures en même temps.

Les paquets de l'archive de sécurité sont construits automatiquement, tout comme l'archive classique. Cependant, les mises à jour de sécurité sont un petit peu différentes des envois normaux par les responsables de paquets car, dans certains cas, avant d'être publiées, elles doivent attendre de pouvoir être plus testées, qu'une alerte soit rédigée ou attendre une semaine ou plus pour éviter de publier le défaut jusqu'à ce que tous les distributeurs aient eu une chance raisonnable de le corriger.

L'archive d'envoi de sécurité fonctionne donc de la façon suivante :

Cette procédure, auparavant réalisée à la main, a été testée et mise en place pendant l'étape de gel de Debian 3.0 Woody (juillet 2002). Grâce à cette architecture, l'équipe de sécurité a pu avoir des paquets mis à jour pour les problèmes d'Apache et d'OpenSSH pour toutes les architectures prises en charge (presque vingt) en moins d'un jour.


7.4.1 Le guide du développeur pour les mises à jour de sécurité

Les développeurs Debian qui doivent se coordonner avec l'équipe en charge de la sécurité pour corriger un problème avec leurs paquets, peuvent consulter la référence du développeur section Gestion des bogues de sécurité.


7.5 La signature de paquet dans Debian

Ce chapitre pourrait également être intitulé « comment mettre à jour et à niveau un système Debian GNU/Linux en sécurité » et mérite d'avoir son propre chapitre car c'est une partie importante de l'infrastructure de sécurité. La signature des paquets est un point important car elle évite l'altération de paquets distribués sur les miroirs et des téléchargements avec des attaques en homme au milieu (« man-in-the-middle »). Les mises à jour de logiciels automatiques sont une fonctionnalité importante, mais il est également important d'enlever les menaces de sécurité qui pourraient favoriser la propagation de chevaux de Troie et la compromission de systèmes lors des mises à jour[55].

Debian ne fournit pas de paquets signés, mais fournit un mécanisme disponible depuis Debian 4.0 Etch pour vérifier l'intégrité des paquets téléchargés[56]. Pour obtenir plus de renseignements, consultez apt sécurisé, Section 7.5.2.

Ce problème est mieux décrit dans le Strong Distribution HOWTO par V. Alex Brennen.


7.5.1 Le schéma actuel pour la vérification de paquet

Le schéma actuel pour la vérification de signatures de paquet en utilisant apt est :

En suivant la chaîne des sommes MD5, apt est capable de vérifier qu'un paquet est originaire d'une version bien spécifique. C'est moins souple que de signer chaque paquet un par un, mais ce peut être combiné également avec ce schéma (voir ci-dessous).

Ce schéma est complètement implémenté dans apt 0.6 et disponible depuis la publication de Debian 4.0. Pour obtenir plus de renseignements, consultez apt sécurisé, Section 7.5.2. Les paquets fournissant une interface à apt doivent être modifiés pour s'adapter à cette nouvelle fonctionnalité, c'est le cas d'aptitude qui a été modifié pour être adapté à ce schéma. aptitude et synaptic font partie des interfaces déjà connues pour fonctionner correctement avec cette fonctionnalité.

La signature de paquets a été abordée dans Debian depuis pas mal de temps déjà, pour plus d'informations vous pouvez lire : http://www.debian.org/News/weekly/2001/8/ et http://www.debian.org/News/weekly/2000/11/.


7.5.2 apt sécurisé

La version 0.6 d'apt, disponible depuis Debian 4.0 Etch, et les versions plus récentes, intègrent apt-secure (aussi connu sous le nom d'apt sécurisé) qui est un outil permettant à l'administrateur système de tester l'intégrité des paquets téléchargés conformément au schéma ci-dessus. Cette version contient l'outil apt-key pour ajouter de nouvelles clefs au trousseau d'apt qui ne contient par défaut que la clef actuelle de signature de l'archive Debian.

Ces modifications sont basées sur un correctif pour apt (disponible dans le bogue nº 203741) qui fournit cette implémentation.

apt sécurisé fonctionne en vérifiant la distribution à l'aide du fichier Release, conformément à Vérification par version de distribution, Section 7.5.3. Typiquement, ce processus sera transparent pour l'administrateur bien qu'il faudra intervenir chaque année [57] pour ajouter la nouvelle clef de l'archive quand elle est modifiée. Pour obtenir plus de renseignements sur les étapes qu'un administrateur doit accomplir, consultez Ajout de clef en sécurité, Section 7.5.3.7.

Cette fonctionnalité est encore en développement, donc si vous pensez avoir trouvé des bogues dans ce paquet, veuillez d'abord vérifier que vous utilisez la dernière version (car ce paquet peut évoluer beaucoup avant d'être diffusé) et si vous utilisez la dernière version, soumettez un rapport de bogue sur le paquet apt.

Plus de renseignements sont disponibles sur les pages du wiki et dans la documentation officielle : Migration vers APT 0.6 et Vérification de signature APT.


7.5.3 Vérification par version de distribution

Cette section décrit le mode de fonctionnement du mécanisme de vérification par version de distribution, elle a été écrite par Joey Hess et est également disponible dans le wiki de Debian.


7.5.3.1 Concepts de base

Voici quelque concepts de base que vous devrez comprendre pour la suite de cette section.

Une somme de contrôle est une méthode permettant de prendre un fichier et de le réduire en un nombre suffisamment petit qui identifie son contenu de façon unique. C'est beaucoup plus compliqué qu'il n'y parait de faire ça bien, et le type de sommes de contrôle le plus fréquemment utilisé, MD5, est en passe d'être cassé.

La cryptographie à clef publique est basée sur une paire de clefs: une publique et une privée. La clef publique est distribuée partout ; la clef privée doit être gardée secrète. Tous ceux qui possèdent la clef publique peuvent chiffrer un message qui ne pourra être lu que par un possesseur de la clef privée. La clef privée permet elle de signer un fichier, pas de le chiffrer. Si une clef privée est utilisée pour signer un fichier, alors tous ceux qui ont la clef publique peuvent vérifier que le fichier était signé par cette clef. Une personne ne possédant pas la clef privée ne peut pas contrefaire une telle signature.

Ces clefs sont des nombres assez grands (de 1024 à 2048 chiffres, ou plus) et pour les rendre plus facile à utiliser, ils ont un identifiant de clef, plus court (un nombre de 8 ou 16 chiffres), qui peut être utilisé pour y référer.

gpg est l'outil utilisé par apt sécurisé pour signer les fichiers et vérifier leurs signatures.

apt-key est un programme qui permet de gérer un trousseau de clefs GPG pour apt sécurisé. Le trousseau est gardé dans le fichier /etc/apt/trusted.gpg (à ne pas confondre avec le fichier /etc/apt/trustdb.gpg relatif, mais pas très intéressant). apt-key permet de montrer les clefs du trousseau, et d'ajouter ou enlever une clef.


7.5.3.2 Sommes de contrôle de Release

Une archive Debian contient un fichier Release, qui est mis à jour à chaque fois qu'un paquet de l'archive est modifié. Entre autres, le fichier Release contient les sommes MD5 d'autres fichiers de l'archives. Exemple d'extrait de fichier Release :

     MD5Sum:
      6b05b392f792ba5a436d590c129de21f            3453 Packages
      1356479a23edda7a69f24eb8d6f4a14b            1131 Packages.gz
      2a5167881adc9ad1a8864f281b1eb959            1715 Sources
      88de3533bf6e054d1799f8e49b6aed8b             658 Sources.gz

Les fichiers Release contiennent aussi des sommes de contrôle SHA-1, ce qui sera utile quand les sommes de contrôle MD5 seront complètement cassées, toutefois, apt ne les utilise pas encore.

Maintenant, à l'intérieur d'un fichier Packages, d'autres sommes de contrôle MD5 sont disponibles : une pour chaque paquet de la liste. Par exemple :

         Package: uqm
         Priority: optional
         ...
         Filename: unstable/uqm_0.4.0-1_i386.deb
         Size: 580558
         MD5sum: 864ec6157c1eea88acfef44d0f34d219

Ces deux sommes de contrôle permettent de vérifier que la copie du fichier Packages téléchargé est correcte, avec une somme de contrôle MD5 qui correspond à celle du fichier Release. Lorsqu'un paquet est téléchargé individuellement, la vérification de la somme de contrôle MD5 avec le contenu du fichier Packages est aussi possible. Si apt échoue à l'une de ces étapes, il abandonnera.

Rien de nouveau pour apt sécurisé, mais cela fournit les bases. Remarquez qu'un seul fichier n'a pas pu être vérifié par apt : le fichier Release. apt sécurisé a justement pour but de faire vérifier Release par apt avant de faire quoi que ce soit d'autre avec, et de combler ce trou, afin de rendre la chaîne de vérification complète, du paquet qui va être installé jusqu'au fournisseur du paquet.


7.5.3.3 Vérification du fichier Release

Pour vérifier le fichier Release, une signature gpg est ajoutée dans le fichier Release.gpg, distribué à ses côtés. Il ressemble à ceci[58], bien que seul gpg accède à son contenu normalement :

     -----BEGIN PGP SIGNATURE-----
     Version: GnuPG v1.4.1 (GNU/Linux)
     
     iD8DBQBCqKO1nukh8wJbxY8RAsfHAJ9hu8oGNRAl2MSmP5+z2RZb6FJ8kACfWvEx
     UBGPVc7jbHHsg78EhMBlV/U=
     =x6og
     -----END PGP SIGNATURE-----

7.5.3.4 Vérification du fichier Release.gpg par apt

apt sécurisé télécharge les fichiers Release.gpg en même temps que les fichiers Release, et s'il ne peut pas télécharger Release.gpg, ou si la signature n'est pas correcte, il se plaindra, et fera remarquer que les fichiers Packages pointés par le fichier Release, et tous les paquets contenus dedans, ne proviennent pas d'une source de confiance. Voici à quoi cela ressemble lors d'un apt-get update :

     W: Erreur de GPG : http://ftp.us.debian.org testing Release :
     Les signatures suivantes n'ont pas pu être vérifiées car la
     clé publique n'est pas disponible : NO_PUBKEY 010908312D230C5F

Remarquez que la seconde partie du grand nombre est l'identifiant de la clef qu'apt ne connaît pas, c'est-à-dire 2D230C5F ici.

Si vous ignorez cet avertissement et essayez d'installer un paquet ensuite, apt avertira de nouveau :

     ATTENTION : les paquets suivants n'ont pas été authentifiés.
       libglib-perl libgtk2-perl
     Faut-il installer ces paquets sans vérification (o/N) ?

Si vous acceptez ici, vous n'avez aucun moyen de savoir si le fichier que vous obtenez est le paquet que vous voulez installer, ou s'il s'agit d'autre chose que quelqu'un pouvant intercepter la communication avec le serveur[59] a préparé pour vous, avec une mauvaise surprise.

Remarquez que vous pouvez désactiver ces vérifications en exécutant apt avec --allow-unauthenticated.

Remarquez également que les nouvelles versions de l'installateur Debian utilisent le même mécanisme de fichier Release lors du debootstrap du système de base Debian, avant qu'apt ne soit disponible, et que l'installateur utilise même ce système pour vérifier ses morceaux qu'il télécharge. Enfin, Debian ne signe pour l'instant pas les fichiers Release de ses CD ; apt peut être configuré pour faire toujours confiance aux fichiers des CD de sorte que ce ne soit pas un gros problème.


7.5.3.5 Comment expliquer à apt en quoi avoir confiance

La sécurité de l'intégralité du système dépend de l'existence d'un fichier Release.gpg, qui signe un fichier Release et de la vérification d'apt à l'aide de gpg. Pour vérifier la signature, il doit connaître la clef publique de la personne qui a signé le fichier. Ces clefs sont gardées dans le trousseau spécifique à apt (/etc/apt/trusted.gpg) et apt sécurisé arrive avec la gestion des clefs.

Par défaut, les systèmes Debian sont fournis préconfigurés avec la clef d'archive Debian du trousseau.

     # apt-key list
     /etc/apt/trusted.gpg
     --------------------
     pub   1024D/4F368D5D 2005-01-31 [expire: 2006-01-31]
     uid                  Debian Archive Automatic Signing Key (2005) <ftpmaster@debian.org>

Ici 4F368D5D est l'identifiant de clef, et remarquez que la clef n'est valable que pour une période d'un an. Debian permute ces clefs comme dernière ligne de défense contre une quelconque brèche de sécurité de cassage de clef.

apt aura ainsi confiance en l'archive Debian officielle, mais si vous ajoutez d'autres dépôts apt à /etc/apt/sources.list, il vous faudra également donner à apt sa clef si vous voulez qu'il ait confiance en ce dépôt. Une fois que vous possédez la clef et que vous l'avez vérifiée, il suffit d'exécuter apt-key add fichier pour l'ajouter. Obtenir la clef et la vérifier sont les parties les plus délicates.


7.5.3.6 Trouver la clef d'un dépôt

Le paquet debian-archive-keyring est utilisé pour distribuer les clefs à apt. Les mises à niveau de ce paquet peuvent ajouter (ou retirer) des clefs gpg pour l'archive Debian principale.

Pour les autres archives, il n'y a pas encore d'endroit normalisé pour trouver la clef d'un dépôt apt donné. La clef est souvent liée depuis la page web du dépôt ou placée dans le dépôt directement, mais il vous faudra parfois la chercher.

La clef de signature de l'archive Debian est disponible en http://ftp-master.debian.org/ziyi_key_2006.asc (remplacez 2006 par l'année en cours). [60]

gpg a lui même un moyen normalisé de distribuer les clefs, utilisant un servent de clefs, d'où gpg peut télécharger une clef pour l'ajouter à son trousseau. Par exemple :

     $ gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
     gpg: requête de la clé 2D230C5F du serveur hkp pgpkeys.mit.edu
     gpg: clé 2D230C5F: clé publique « Debian Archive Automatic Signing Key (2006)
     <ftpmaster@debian.org> » importée
     gpg:        Quantité totale traitée: 1
     gpg:                       importée: 1

Vous pouvez alors exporter cette clef depuis votre propre trousseau et la fournir à apt-key :

     $ gpg -a --export 2D230C5F | sudo apt-key add -
     gpg: aucune clé de confiance ultime n'a été trouvée
     OK

L'avertissement « gpg: aucune clé de confiance ultime n'a été trouvée » signifie que gpg n'était pas configuré pour faire confiance de façon ultime à une clef en particulier. Les réglages de confiance font partie du réseau de confiance d'OpenPGP qui ne s'applique pas ici. Cet avertissement n'est donc pas un problème ici. Dans les configurations typiques, seule la propre clef de l'utilisateur est de confiance ultime.


7.5.3.7 Ajout de clef en sécurité

En ajoutant une clef au trousseau d'apt, vous lui dite de faire confiance à tout ce qui est signé par cette clef, et cela vous permet de savoir avec certitude qu'apt n'installera rien de non signé par la personne qui possède la clef privée. Si vous êtes suffisamment paranoïaque, vous pouvez voir que cela ne fait que déplacer les choses d'un niveau : maintenant au lieu de vous inquiéter de la validité d'un paquet ou d'un fichier Release, il suffit de s'inquiéter d'avoir vraiment la bonne clef ; est-ce que le fichier http://ftp-master.debian.org/ziyi_key_2006.asc mentionné ci-dessous est vraiment la clef de signature de l'archive, ou a-t-il été modifié (ou ce document ment-il) ?

Être paranoïaque est une bonne attitude en sécurité, mais vérifier les choses à partir d'ici est plus difficile. gpg connaît le concept de chaîne de confiance, qui peut commencer à partir de quelqu'un dont vous être sûr, qui signe la clef de quelqu'un, qui signe une autre clef, etc. jusqu'à atteindre la clef de l'archive. Si vous êtes suffisamment paranoïaque, vous voudrez vérifier que la clef de l'archive est signée par une clef en laquelle vous pouvez avoir confiance, avec une chaîne de confiance qui remonte jusqu'à quelqu'un que vous connaissez personnellement. Si vous voulez faire cela, rendez vous à une conférence Debian ou peut-être à un groupe (LUG) local pour une signature de clef [61].

Si vous ne pouvez pas vous permettre ce niveau de paranoïa, faites le nécessaire suffisant de votre point de vue quand vous ajoutez une nouvelle source apt et une nouvelle clef. Peut-être voudrez vous échanger un courrier électronique avec la personne fournissant la clef et la vérifier, ou peut-être préférerez vous tenter votre chance en téléchargeant la clef en supposant que c'est la bonne. Ce qui est important est qu'en réduisant le problème au niveau de confiance des clefs de l'archive, apt sécurisé vous laisse être aussi prudent et sécurisé que vous désirez l'être.


7.5.3.8 Vérification de l'intégrité des clefs

Vous pouvez aussi bien vérifier l'empreinte digitale de la clef que ses signatures. La récupération de l'empreinte digitale peut se faire depuis de nombreuses sources : vous pouvez vérifier le livre système Debian, parler avec des développeurs Debian sur IRC, lire la liste de diffusion où la modification de clef sera annoncée ou n'importe quel moyen supplémentaire pour vérifier l'empreinte digitale. Par exemple en faisant :

     $ GET http://ftp-master.debian.org/keys/archive-key-6.0.asc | gpg --import
     gpg: clé 473041FA: clé publique « Debian Archive Automatic Signing Key (6.0/squeeze)
       <ftpmaster@debian.org> » importée
     gpg:        Quantité totale traitée: 1
     gpg:                       importée: 1  (RSA: 1)
     gpg: 3 marginale(s) nécessaires, 1 complète(s) nécessaires, modèle
       de confiance PGP
     gpg: profondeur: 0  valide:   1  signé:   0
     confiance: 0-. 0g. 0n. 0m. 0f. 1u
     $ gpg --check-sigs --fingerprint 473041FA
     pub   4096R/473041FA 2010-08-27 [expire: 2018-03-05]
         Empreinte de la clé = 9FED 2BCB DCD2 9CDF 7626  78CB AED4 B06F 4730 41FA
     uid                  Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>
     sig!3        473041FA 2010-08-27  Debian Archive Automatic Signing Key (6.0/squeeze)
       <ftpmaster@debian.org>
     sig!         7E7B8AC9 2010-08-27  Joerg Jaspert <joerg@debian.org>
     sig!    P    B12525C4 2010-08-27  Joerg Jaspert <joerg@debian.org>
     sig!         D0EC0723 2010-08-27  Mark Hymers <mhy@debian.org>
     sig!         8AEA8FEE 2010-08-27  Stephen Gran <steve@lobefin.net>
     sig!         A3AE44A4 2010-08-28  Michael O'Connor (stew) <stew@vireo.org>
     sig!         00D8CD16 2010-08-28  Alexander Reichle-Schmehl <alexander@reichle.schmehl.info>
     sig!         CD15A883 2010-08-28  Alexander Schmehl (privat) <alexander@schmehl.info>
     sig!         672C8B12 2010-08-28  Alexander Reichle-Schmehl <tolimar@debian.org>
     sig!2        C4CF8EC3 2010-08-28  Torsten Werner <twerner@debian.org>
     sig!2        D628A5CA 2010-08-28  Torsten Werner <mail.twerner@googlemail.com>

puis en vérifiant la chaîne de confiance (consultez La signature de paquet dans Debian, Section 7.5) de votre clef (ou d'une clef de confiance) vers au moins une des clefs utilisées pour signer la clef de l'archive. Si vous êtes suffisamment paranoïaque, vous ne direz à apt de ne faire confiance à la clef que si vous êtes satisfait de la chaîne de confiance :

     $ gpg --export -a 473041FA | sudo apt-key add -
     OK

Remarquez que la clef est signée par la clef de l'archive précédente, donc vous pouvez en théorie vous appuyer simplement sur votre confiance précédente.


7.5.3.9 Rotation annuelle de la clef de l'archive Debian

Comme signalé précédemment, la clef de l'archive Debian est modifiée tous les ans, en janvier. Comme apt sécurisé est encore jeune, nous manquons encore d'expérience pour modifier la clef et des passages sont un peu abrupts.

En janvier 2006, une nouvelle clef à été préparée pour 2006 et le fichier Release a commencé à être signé par cette clef, mais pour éviter de casser les systèmes qui utilisaient encore l'ancienne clef de 2005, le fichier Release était aussi signé par cette dernière. Le but était qu'apt accepte les deux signatures, indépendamment de la clef qu'il possède, mais à cause d'un bogue d'apt, il refusait de faire confiance au fichier s'il n'avait pas les deux clefs et n'était pas capable de vérifier les deux signatures. Cela a été corrigé dans la version 0.6.43.1 d'apt. Une confusion existait aussi sur la façon de distribuer la clef aux utilisateurs qui utilisaient déjà des systèmes avec apt sécurisé ; elle avait été envoyée sur le site web sans annonce et sans réel moyen de la vérifier, et les utilisateurs ont été obligés de la télécharger eux-mêmes.

En janvier 2006, une nouvelle clef à été préparée pour 2006 et le fichier Release a commencé à être signé par cette clef, mais pour éviter de casser les systèmes qui utilisaient encore l'ancienne clef de 2005, le fichier Release était aussi signé par cette dernière. Pour éviter les confusions sur le meilleur mécanisme de distribution pour les utilisateurs qui utilisent déjà des systèmes avec apt sécurisé, le paquet debian-archive-keyring a été introduit, pour gérer les mises à jour du trousseau de clefs d'apt.


7.5.3.10 Problèmes connus de vérification de la publication

Un autre problème évident est que si l'horloge est très décalée, apt sécurisé ne fonctionnera pas. Si la date est configurée dans le passée, comme en 1999, apt échouera avec un message peu compréhensible comme :

     W: GPG error: http://ftp.us.debian.org sid Release: Unknown error executing gpg

Pourtant apt-key list expliquera le problème :

     gpg: la clé 473041FA a été créée 367773259 secondes dans le futur (rupture
     spatio-temporelle ou problème d'horloge)
     pub   4096R/473041FA 2010-08-27 [expire: 2018-03-05]
     uid                  Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>

Si elle est configurée à une date trop dans le futur, apt considérera la clef expirée.

Un autre problème que vous pourriez rencontrer en utilisant testing ou unstable, est que si vous n'avez pas exécuté apt-get update récemment et apt-get install un paquet, apt risque de se plaindre qu'il ne peut pas être authentifié. apt-get update corrigera cela.


7.5.3.11 Vérification manuelle par version de distribution

Au cas où vous voudriez ajouter des vérifications de sécurité supplémentaires et que vous ne vouliez pas ou pouviez pas utiliser la dernière version d'apt[62] vous pouvez utiliser le script ci-dessous fourni par Anthony Towns. Ce script peut automatiquement faire certaines nouvelles vérifications de sécurité qui permettent à l'utilisateur d'être sûr que le logiciel qu'il télécharge correspond à celui de la distribution de logiciels Debian. Cela empêche les développeurs Debian d'intégrer des nouveautés au système de quelqu'un en outrepassant les responsabilités qui incombent au chargement vers l'archive principale, ou encore cela empêche une duplication similaire mais pas exactement identique, ou pour finir cela empêche l'utilisation de miroirs fournissant des copies anciennes de la version unstable ou connaissant des problèmes de sécurité.

Ce code exemple, renommé en apt-release-check, devrait être utilisé de la manière suivante :

     # apt-get update
     # apt-check-sigs
     (...résultats...)
     # apt-get dist-upgrade

Avant tout, vous avez besoin de :

C'est le code exemple pour apt-check-sigs, la dernière version peut être récupérée depuis http://people.debian.org/~ajt/apt-check-sigs. Ce code est actuellement en bêta, pour de plus amples renseignements, consultez http://lists.debian.org/debian-devel/2002/debian-devel-200207/msg00421.html.

     #!/bin/bash
     
     # Copyright (c) 2001 Anthony Towns <ajt@debian.org>
     #
     # This program is free software; you can redistribute it and/or modify
     # it under the terms of the GNU General Public License as published by
     # the Free Software Foundation; either version 2 of the License, or
     # (at your option) any later version.
     #
     # This program is distributed in the hope that it will be useful,
     # but WITHOUT ANY WARRANTY; without even the implied warranty of
     # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     # GNU General Public License for more details.
     
     rm -rf /tmp/apt-release-check
     mkdir /tmp/apt-release-check || exit 1
     cd /tmp/apt-release-check
     
     >OK
     >MISSING
     >NOCHECK
     >BAD
     
     arch=`dpkg --print-installation-architecture`
     
     am_root () {
             [ `id -u` -eq 0 ]
     }
     
     get_md5sumsize () {
             cat "$1" | awk '/^MD5Sum:/,/^SHA1:/' | 
               MYARG="$2" perl -ne '@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) { 
     print "$f[1] $f[2]\n"; exit(0); }'
     }
     
     checkit () {
             local FILE="$1"
             local LOOKUP="$2"
     
             Y="`get_md5sumsize Release "$LOOKUP"`"
             Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"
     
             if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                     if [ "$Y" = "" ]; then
                             # No file, but not needed anyway
                             echo "Succès"
                             return
                     fi
                     echo "$FILE" >>MISSING
                     echo "$Y manquant"
                     return
             fi
             if [ "$Y" = "" ]; then
                     echo "$FILE" >>NOCHECK
                     echo "Pas de vérification"
                     return
             fi
             X="`md5sum < /var/lib/apt/lists/$FILE | cut -d\  -f1` `wc -c < /var/lib
     /apt/lists/$FILE`"
             X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
             if [ "$X" != "$Y" ]; then
                     echo "$FILE" >>BAD
                     echo "Problème"
                     return
             fi
             echo "$FILE" >>OK
             echo "Succès"
     }
     
     echo
     echo "Vérification des sources dans /etc/apt/sources.list :"
     echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
     echo
     (echo "Vous devriez vous assurer que les distributions que vous téléchargez"
     echo "sont bien celles que vous pensez télécharger, et qu'elle sont aussi à"
     echo "jour que vous pourriez l'espérer (testing et unstable ne devraient pas"
     echo "être désynchronisées de plus d'un jour ou deux, stable-updates pas plus"
     echo "de quelques semaines ou un mois)."
     ) | fmt
     echo
     
     cat /etc/apt/sources.list | 
       sed 's/^ *//' | grep '^[^#]' |
       while read ty url dist comps; do
             if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
                     baseurl="${url#*://}"
             else
                     continue
             fi
     
             echo "Source : ${ty} ${url} ${dist} ${comps}"
     
             rm -f Release Release.gpg
             lynx -reload -dump "${url}/dists/${dist}/Release" >/dev/null 2>&1
             wget -q -O Release "${url}/dists/${dist}/Release"
     
             if ! grep -q '^' Release; then
                     echo "  * Pas de fichier Release au premier niveau"
                     >Release
             else
                     origline=`sed -n 's/^Origin: *//p' Release | head -1`
                     lablline=`sed -n 's/^Label: *//p' Release | head -1`
                     suitline=`sed -n 's/^Suite: *//p' Release | head -1`
                     codeline=`sed -n 's/^Codename: *//p' Release | head -1`
                     dateline=`grep "^Date:" Release | head -1`
                     dscrline=`grep "^Description:" Release | head -1`
                     echo "  o Origine : $origline/$lablline"
                     echo "  o Suite : $suitline/$codeline"
                     echo "  o $dateline"
                     echo "  o $dscrline"
     
                     if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
                             echo "  * Attention : $dist était demandée, $suitline/$codeline a été obtenue"
                     fi
     
                     lynx -reload -dump "${url}/dists/${dist}/Release.gpg" >/dev/null 2>&1
                     wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"
     
                     gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] //p" | (okay=0; err=""; while read gpgcode rest; do
                             if [ "$gpgcode" = "GOODSIG" ]; then
                                 if [ "$err" != "" ]; then
                                     echo "  * Signé par ${err# } clef : ${rest#* }"
                                 else
                                     echo "  o Signé par : ${rest#* }"
                                     okay=1
                                 fi
                                 err=""
                             elif [ "$gpgcode" = "BADSIG" ]; then
                                 echo "  * Mauvaise signature par : ${rest#* }"
                                 err=""
                             elif [ "$gpgcode" = "ERRSIG" ]; then
                                 echo "  * Impossible de vérifier la signature par identifiant de clef : ${rest %% *}"
                                 err=""
                             elif [ "$gpgcode" = "SIGREVOKED" ]; then
                                 err="$err Révoquée"
                             elif [ "$gpgcode" = "SIGEXPIRED" ]; then
                                 err="$err Expirée"
                             fi
                         done
                         if [ "$okay" != 1 ]; then
                             echo "  * Pas de signature valable"
                             >Release
                         fi)
             fi
             okaycomps=""
             for comp in $comps; do
                     if [ "$ty" = "deb" ]; then
                             X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Release" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Release")
                             Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/binary-${arch}/Packages" | sed 's,//*,_,g'`" "${comp}/binary-${arch}/Packages")
                             if [ "$X $Y" = "OK OK" ]; then
                                     okaycomps="$okaycomps $comp"
                             else
                                     echo "  * Problèmes avec $comp ($X, $Y)"
                             fi
                     elif [ "$ty" = "deb-src" ]; then
                             X=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Release" | sed 's,//*,_,g'`" "${comp}/source/Release")
                             Y=$(checkit "`echo "${baseurl}/dists/${dist}/${comp}/source/Sources" | sed 's,//*,_,g'`" "${comp}/source/Sources")
                             if [ "$X $Y" = "OK OK" ]; then
                                     okaycomps="$okaycomps $comp"
                             else
                                     echo "  * Problèmes avec le composant $comp ($X, $Y)"
                             fi
                     fi
             done
             [ "$okaycomps" = "" ] || echo "  o Okay:$okaycomps"
             echo
       done
     
     echo "Résultat"
     echo "~~~~~~~~"
     echo
     
     allokay=true
     
     cd /tmp/apt-release-check
     diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -type f -maxdepth 1 | sed 's,^\./,,g' | grep '_' | sort) | sed -n 's/^> //p' >UNVALIDATED
     
     cd /tmp/apt-release-check
     if grep -q ^ UNVALIDATED; then
         allokay=false
         (echo "Les fichiers suivants de /var/lib/apt/lists n'ont pas été validés."
         echo "Cela peut soit être une simple indication inoffensive que ce script"
         echo "est bogué ou pas à jour, soit un indicateur de porte ouverte aux"
         echo "paquets de type chevaux de Troie sur le système."
         ) | fmt
         echo
         sed 's/^/    /' < UNVALIDATED
         echo
     fi
     
     if grep -q ^ BAD; then
         allokay=false
         (echo "Les contenus des fichiers suivants de /var/lib/apt/lists ne"
         echo "correspondent pas à ce qui était attendu. Cela peut signifier que"
         echo "ces sources ne sont pas à jour, qu'il y a un problème d'archive,"
         echo "ou que quelqu'un est en train d'utiliser le miroir pour distribuer"
         echo "des chevaux de Troie."
         if am_root; then 
             echo "Les fichiers ont été renommés avec l'extension .FAILED et"
             echo "seront ignorés par apt."
             cat BAD | while read a; do
                 mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
             done
         fi) | fmt
         echo
         sed 's/^/    /' < BAD
         echo
     fi
     
     if grep -q ^ MISSING; then
         allokay=false
         (echo "Les fichiers suivants de /var/lib/apt/lists manquaient. Cela"
         echo "pourrait vous faire manquer des mises à jours de paquets vulnérables."
         ) | fmt
         echo
         sed 's/^/    /' < MISSING
         echo
     fi
     
     if grep -q ^ NOCHECK; then
         allokay=false
         (echo "Les contenus des fichiers suivants de /var/lib/apt/lists n'ont pas"
         echo "pu être validés à cause d'un manque de fichier Release signé, ou"
         echo "d'un manque d'entrée appropriée dans un fichier Release signé. Cela"
         echo "signifie probablement que les mainteneurs de ces sources sont"
         echo "négligents, mais pourrait signifier que ces sources sont en cours"
         echo "d'utilisation pour distribuer des chevaux de Troie."
         if am_root; then 
             echo "Les fichiers ont été renommés avec l'extension .FAILED et"
             echo "seront ignorés par apt."
             cat NOCHECK | while read a; do
                 mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
             done
         fi) | fmt
         echo
         sed 's/^/    /' < NOCHECK
         echo
     fi
     
     if $allokay; then
         echo 'Tout semble se passer correctement !'
         echo
     fi
     
     rm -rf /tmp/apt-release-check

Vous pourriez devoir ajouter le correctif suivant pour Sid car md5sum ajoute un « - » après la somme quand l'entrée provient de l'entrée standard :

     @@ -37,7 +37,7 @@
             local LOOKUP="$2"
     
             Y="`get_md5sumsize Release "$LOOKUP"`"
     -       Y="`echo "$Y" | sed 's/^ *//;s/  */ /g'`"
     +       Y="`echo "$Y" | sed 's/-//;s/^ *//;s/  */ /g'`"
     
             if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
                     if [ "$Y" = "" ]; then
     @@ -55,7 +55,7 @@
                     return
             fi
             X="`md5sum < /var/lib/apt/lists/$FILE` `wc -c < /var/lib/apt/lists/$FILE`"
     -       X="`echo "$X" | sed 's/^ *//;s/  */ /g'`"
     +       X="`echo "$X" | sed 's/-//;s/^ *//;s/  */ /g'`"
             if [ "$X" != "$Y" ]; then
                     echo "$FILE" >>BAD
                     echo "Problème"

7.5.4 Vérification de distribution pour les sources non Debian

Notez que, lors de l'utilisation de la dernière version d'apt (avec apt sécurisé), aucun effort supplémentaire ne devrait être nécessaire de votre part sauf si vous utilisez des sources non Debian, auquel cas une étape de confirmation supplémentaire sera imposée par apt-get. C'est évité en fournissant les fichiers Release et Release.gpg dans les sources non Debian. Le fichier Release peut être généré avec apt-ftparchive (disponible dans apt-utils 0.5.0 et ultérieur), le fichier Release.gpg est simplement une signature détachée. Pour générer les deux fichiers, suivez cette procédure simple :

     $ rm -f dists/unstable/Release
     $ apt-ftparchive release dists/unstable > dists/unstable/Release
     $ gpg --sign -ba -o dists/unstable/Release.gpg dists/unstable/Release

7.5.5 Schéma alternatif de signature par paquet

Le schéma supplémentaire de signature de chacun des paquets permet aux paquets d'être vérifiés quand ils ne sont plus référencés par un fichier Packages existant, et également pour les paquets de tierce partie dont aucun Packages n'a jamais existé, pour qu'ils puissent être utilisés dans Debian, mais ce ne sera pas le schéma par défaut.

Ce schéma de signature des paquets peut être implémenté en utilisant debsig-verify et debsigs. Ces deux paquets peuvent signer et vérifier des signatures intégrées au .deb lui-même. Debian a déjà la capacité de faire cela actuellement, mais il n'y a aucun projet de mettre en place une charte ou d'autres outils puisque la signature de l'archive est préférée. Ces outils sont disponibles aux utilisateurs et aux administrateurs d'archive qui pourraient préférer utiliser ce schéma.

Les dernières versions de dpkg (à partir de la version 1.9.21) contiennent un correctif qui fournit cette fonctionnalité dès que debsig-verify est installé.

Note : actuellement, /etc/dpkg/dpkg.cfg est livré avec « no-debsig » par défaut.

Seconde note : les signatures des développeurs sont actuellement enlevées lors de l'entrée du paquet dans l'archive car la méthode actuellement préférée est par vérification de distribution comme décrit précédemment.


[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ suivant ]


Securing Debian Manual

Version: 3.16, construite le Sun, 08 Apr 2012 02:48:09 +0000

Javier Fernández-Sanguino Peña jfs@debian.org
Auteurs, Section 1.1