[ 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 ]
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.
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 :
numéro de version pour le correctif ;
type de problème ;
s'il est exploitable à distance ou localement ;
description courte du paquet ;
description du problème ;
description du stratagème ;
description du correctif.
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[50] des DSA ne sont pas envoyées aux listes de diffusion de sécurité, mais elles sont directement intégrées au site web.
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 :
cela permet plus facilement aux utilisateurs de Debian de voir et de suivre quelles alertes générales (publiées) ont déjà été couvertes par Debian ;
les administrateurs système peuvent en apprendre plus sur la faille et ses impacts en suivant les références croisées ;
ces renseignements peuvent être utilisés pour vérifier les sorties de scanneurs de failles qui contiennent des références à CVE pour supprimer des faux positifs (consultez Le scanneur X de vérification des failles indique que le système Debian est vulnérable !, Section 12.2.1).
Les alertes de sécurité Debian ont été déclarées comme
étant compatibles CVE[51] 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 :
aucun produit Debian n'est concerné par cette faille ;
il n'y a pas encore eu d'alerte couvrant cette faille (le problème de
sécurité peut avoir été signalé comme un bogue de
sécurité, mais aucune correction n'a encore été testée et
envoyée) ;
une alerte a été publiée avant qu'un nom CVE ait été attribué à une faille donnée (chercher une mise à jour sur le site web).
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.
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 :
quelqu'un trouve un problème de sécurité ;
quelqu'un corrige le problème et fait un envoi vers incoming de security-master.debian.org (ce quelqu'un est habituellement un membre de l'équipe de sécurité, mais ce peut aussi être un responsable de paquet avec un correctif approprié qui a contacté l'équipe de sécurité auparavant). Le journal de modifications contient une cible de distribution testing-security ou stable-security ;
l'envoi est vérifié et traité par un système Debian et déplacé dans queue/accepted et le service d'empaquetage est prévenu. Les fichiers à cet endroit sont accessibles par l'équipe de sécurité et (de façon un peu indirecte) par les service d'empaquetage ;
les serveurs d'empaquetage activés pour la sécurité récupèrent le paquet source (en priorité par rapport aux constructions courantes), le construisent et envoient les journaux à l'équipe de sécurité ;
l'équipe de sécurité répond aux journaux et les paquets nouvellement construits sont envoyés vers queue/unchecked, où ils sont traités par un système Debian et déplacés dans queue/accepted ;
quand l'équipe de sécurité trouve les paquets acceptables (c'est-à-dire qu'ils sont correctement construits pour toutes les architectures pertinentes et corrigent le trou de sécurité sans introduire de nouveau problème par eux-mêmes), un script est exécuté qui :
installe le paquet dans l'archive de sécurité ;
met à jour les fichiers Packages, Sources et
Release de security.debian.org de la façon habituelle
(dpkg-scanpackages,
dpkg-scansources, etc.) ;
met en place un modèle d'alerte que l'équipe de sécurité peut compléter ;
fait suivre les paquets vers le proposed-updates approprié pour qu'il soit intégré à l'archive réelle dès que possible.
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.
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é.
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[52].
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[53]. 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.
Le schéma actuel pour la vérification de signatures de paquet en utilisant
apt est :
le fichier Release contient la somme de contrôle MD5 de
Packages.gz (qui contient les sommes de contrôle MD5 des paquets)
et sera signé. La signature est celle d'une source sûre ;
ce fichier Release est téléchargé par « apt-get
update » et stocké sur le disque dur avec
Packages.gz ;
quand un paquet est sur le point d'être installé, il est d'abord téléchargé, puis la somme MD5 est calculée ;
le fichier Release signé est vérifié (la signature est bonne)
et la somme MD5 en est extraite pour le fichier Packages.gz, la
somme de contrôle de Packages.gz est calculée et (si elle est
bonne) la somme de contrôle MD5 du paquet téléchargé en est extraite ;
si la somme de contrôle MD5 du paquet téléchargé est la même que celle
contenue dans le fichier Packages.gz, le paquet sera installé
sinon l'administrateur sera averti et le paquet sera laissé dans le cache
(ainsi l'administrateur décidera de l'installer ou non). Si le paquet n'est
pas dans Packages.gz et que l'administrateur a configuré le
système pour installer uniquement les paquets vérifiés, il ne sera pas
installé non plus.
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/.
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 [54] 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.
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.
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.
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.
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[55], 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-----
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[56] 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.
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.
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). [57]
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.
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 [58].
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.
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.
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.
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.
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[59] 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 :
récupérer les clefs que les logiciels de l'archive utilisent pour signer les
fichiers Release, http://ftp-master.debian.org/ziyi_key_2006.asc,
et les ajouter à ~/.gnupg/trustedkeys.gpg (c'est ce que
gpgv utilise par défaut) ;
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2006.asc
retirer toutes les lignes de /etc/apt/sources.list qui n'utilisent
pas la structure normale « dists » ou modifier le script afin qu'il
fonctionne avec elles ;
être prêt à ignorer le fait que les mises à jour de sécurité Debian n'ont
pas de fichiers Release signés et que les fichiers
Sources n'ont pas (encore) les sommes de contrôle
(« checksums ») appropriées dans le fichier
Release ;
être prêt à vérifier que les sources appropriées soient signées par les clefs appropriées.
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"
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
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.13, Sun, 08 Apr 2012 02:48:09 +0000jfs@debian.org