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

Manuel de sécurisation de Debian
Chapitre 7 - Infrastructure de sécurité Debian

7.1 L'équipe de sécurité Debian

Debian possède une équipe de sécurité, composée de cinq membres et deux secrétaires, qui gère la sécurité dans la distribution stable. Gérer la sécurité veut dire qu'ils suivent les failles qui surviennent dans les logiciels (en surveillant des forums comme bugtraq ou vuln-dev) et ils déterminent si la distribution stable est touchée par ces failles.

L'équipe de sécurité Debian est également le point de contact pour les problèmes qui sont coordonnées par les développeurs amont ou des organisations comme le CERT, qui peuvent toucher de multiples vendeurs. C'est-à-dire, quand les problèmes ne sont pas spécifiques à Debian. Il existe deux points de contact avec l'équipe de sécurité :

Les informations secrètes devraient être envoyées à la première adresse et, dans certains cas, devraient être cryptées avec la clé du contact de l'équipe de sécurité (key ID 363CCD95).

Une fois 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 inclura parfois un rétro-portage du correctif effectué en amont (qui est habituellement en avance de plusieurs version 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 security.debian.org pour pouvoir être récupéré par apt (voir 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 à Questions concernant l'équipe de sécurité Debian, Section 11.3.

7.2 Alertes de sécurité Debian

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

Les DSA sont publiées sur la page principale de Debian et dans les pages de sécurité Debian. Ceci 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ées peuvent, cependant (et ceci est fait sur quelques portails relatifs à Debian) utiliser le canal 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 applet GNOME) peuvent être utilisés pour récupérer les alertes automatiquement. Le canal 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 [43] des DSA ne sont pas envoyées aux listes de diffusion de sécurité, mais elles sont directement incluses sur le 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 pourrez noter 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 failles US-CERT ainsi que les noms CVE (voir ci-dessous). Ces références sont fournis pour faciliter l'utilisation, mais seules les références CVE sont périodiquement vérifiées et incluses. Cette fonctionnalité a été ajoutée au site web en juin 2002.

L'un des avantages d'ajouter les références croisées vers ces bases de données de failles est que :

7.2.2 Compatibilité CVE

Les alertes de sécurité Debian ont été déclarées comme étant compatibles CVE[44] 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 croit 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 a commencé à ajouter les noms CVE aux DSA en juin 2002 et fournit maintenant les noms CVA pour toutes les DSA publiées depuis septembre 1998 après un processus de vérification commencé en août 2002. Toutes les alertes peuvent être récupérées sur le site web Debian et les annonces liées aux nouvelles failles incluent les noms CVS quand ils sont disponibles lors de leur publication. Les alertes liées à un nom de CVE donné peuvent être cherchées directement avec le moteur de rechercher.

Les utilisateurs désirant chercher un nom particulier de CVE peuvent utiliser le moteur de recherche disponible sur debian.org pour récupérer les alertes disponibles (en anglais et traduites dans d'autres langues) associées aux noms CVE. Une recherche peut être faite avec un nom spécifique (comme alerte CAN-2002-0001) ou pour des noms partiels (comme une recherche de tous les candidats 2002 inclus dans des alertes pour CAN-2002). Notez que vous devez entrer lie mot clé alerte (« advisory » en anglais) avec le nom CVE pour ne récupérer que les alertes de sécurité.

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

7.3 Infrastructure de construction de sécurité Debian

Comme Debian supporte actuellement 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, à l'exception de rares circonstances, les mises à jour sont disponibles pour toutes les architectures en même temps.

Alors que précédemment la tâche de construction des mises à jour de sécurité était faite à la main, ce n'est plus actuellement le cas (comme le décrit Anthony Towns dans un courriel envoyé à la liste de diffusion debian-devel-announce daté du 8 juin 2002).

Les paquets envoyés par l'équipe de sécurité (à security.debian.org:/org/security.debian.org/queue/unchecked ou ftp://security.debian.org/pub/SecurityUploadQueue) avec un correctif approprié voient leur signature vérifiée dans les quinze minutes après l'envoi, une fois ceci fait, ils sont ajoutés à la liste des autoconstructeurs (qui n'est plus une exécution d'archive journalière). Les paquets sont donc automatiquement construits pour toutes les architectures trente minutes ou une heure après leur envoi. Cependant, les mises à jour de sécurité sont un petit peu différentes que les 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 vendeurs aient eu une chance raisonnable de le corriger.

L'archive d'envoi de sécurité fonctionner donc de la façon suivante (dénommée "Accepted-Autobuilding") :

Cette procédure, auparavant fait à la main, a été testé 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 supportées (presque vingt) en moins d'un jour.

7.3.1 Le guide du développeur aux mises à jour de sécurité

Ce message a été envoyé par Wichert Akkerman à la liste de diffusion debian-devel-announce pour décrire le comportement des développeurs Debian pour la gestion des problèmes de sécurité dans leurs paquets. Il est publié ici à la fois pour le bénéfice des développeurs ainsi que pour que les utilisateurs comprennent mieux comment est gérée la sécurité dans Debian.

Veuillez noter que la référence à jour pour cette information est la référence du développeur Debian, cette section sera supprimée dans un avenir proche.

7.3.1.1 Se coordonner avec l'équipe de sécurité

Si un développeur apprend un problème de sécurité soit dans son paquet ou dans celui de quelqu'un d'autre, il devrait toujours contacter l'équipe de sécurité (à team@security.debian.org). Il suivent les problèmes de sécurité existants, ils peuvent aider les responsables avec des problèmes de sécurité ou les corriger eux-même, ils sont responsables de l'envoi des alertes de sécurité et maintiennent security.debian.org.

Veuillez noter que les alertes de sécurité ne sont effectuées que pour des distributions stables, pas pour testing, unstable (voir Comment est assurée la sécurité pour les versions testing et unstable ?, Section 11.3.7) ou d'anciennes distributions (voir Je possède un ancienne version de Debian, est-elle supportée par l'équipe de sécurité Debian ?, Section 11.3.8).

7.3.1.2 Prendre connaissance des problèmes de sécurité

Il existe plusieurs façons pour un développeur de prendre connaissance d'un problème de sécurité :

Dans les deux premiers cas, l'information est publique et il est important d'avoir une solution le plus vite possible. Dans le dernier cas, cependant, ce n'est peut-être pas une information publique. Dans ce cas, il existe quelques options possibles pour traiter le problème :

Dans tous les cas, si la personne qui indique le problème demande à ce que l'information ne soit pas diffusée, cela devrait être respecté avec l'évidente exception d'informer l'équipe de sécurité (le développeur devrait s'assurer de dire à l'équipe de sécurité que l'information ne peut être dévoilée).

Veuillez noter que si le secret est nécessaire, vous ne pourrez pas envoyer un correctif vers unstable (ou ailleurs) puisque les informations de changelog sont publiques.

Il existe deux raisons pour diffuser l'information même si le secret est demandé : le problème est connu depuis un certain temps ou le problème est devenu public.

7.3.1.3 Construire le paquet

La règle la plus important lors de la construction d'un nouveau paquet corrigeant un problème de sécurité est de faire aussi peu de modifications que possible. Les personnes s'attendent à un comportement identique dans une version lorsque celle-ci est diffusée, donc tout changement qui est fait est susceptible de casser le système de quelqu'un. Ceci est spécialement vrai pour les bibliothèques : assurez-vous de ne jamais changer l'API ou l'ABI, quelque minimal que soit le changement.

Cela veut dire que passer à une version amont supérieure n'est pas une bonne solution. À la place, les changements pertinents devraient être rétroportés. Habituellement, les développeurs amont veulent bien aider. Sinon, l'équipe de sécurité Debian peut le faire.

Dans certains cas, il n'est pas possible de rétroporter un correctif de sécurité, par exemple, quand de grandes quantités de code source doivent être modifiées ou réécrites. Si cela se produit, il peut être nécessaire de passer à une nouvelle version amont, mais vous devez toujours coordonner cela avec l'équipe de sécurité au préalable.

Il existe une autre règle de conduite liée à cela : les développeurs doivent toujours tester leurs changements. Si une exploitation du problème existe, essayez-la et vérifiez qu'elle réussit sur le paquet non corrigé et échoue sur le paquet corrigé. Testez aussi les autres actions normales car parfois un correctif de sécurité peut casser de manière subtile des fonctionnalités normales.

Enfin, quelques points techniques que les développeurs doivent garder à l'esprit :

7.3.1.4 Envoyer les correctifs de sécurité

Une fois que le développeur a créé et testé le nouveau paquet, il doit être envoyé pour être installé dans l'archive. Pour les envois de sécurité, l'adresse d'envoi est ftp://security.debian.org/pub/SecurityUploadQueue/.

Une fois que l'envoi vers la file d'attente de sécurité a été accepté, le paquet sera automatiquement recompilé pour toutes les architectures et stocké pour vérification par l'équipe de sécurité.

Les envois en attente d'acceptation ou de vérification ne sont accessibles que par l'équipe de sécurité. C'est nécessaire car il pourrait y avoir des correctifs pour des problèmes de sécurité qui ne peuvent pas encore être diffusés.

Si une personne de l'équipe de sécurité accepte un paquet, il sera installé sur security.debian.org ainsi que dans le répertoire <nomdecode>-proposed-updates qui convient sur ftp-master ou dans l'archive non-US.

7.3.1.5 Alertes de sécurité

Les alertes de sécurité sont écrites et envoyées par l'équipe de sécurité. Cependant, ils ne verront aucun inconvénient à qu'un responsable fournisse (une partie) du texte pour eux. Les informations qui devraient être présentes dans une alerte sont décrites dans Alertes de sécurité Debian, Section 7.2.

7.4 La signature de paquet dans Debian

Ce chapitre pourrait également être intitulé « comment améliorer/actualiser sûrement votre système Debian GNU/Linux » et il 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 sur l'homme-du-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 pourrait favoriser la propagation de chevaux de Troie et la compromission de systèmes lors des mises à jour [45].

À ce jour (mai 2005), Debian ne fournit pas de paquets signés pour la distribution et les versions Woody (3.0) et Sarge (3.1) n'intègrent pas cette fonctionnalité. Il existe une solution pour les paquets signés qui sera, espérons-le, fournie dans la prochaine version (Etch). Cette nouvelle fonctionnalité sera disponible dans apt 0.6 (actuellement disponible dans la distribution sid, voir Apt-secure, Section 7.4.2).

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

7.4.1 Le schéma proposé 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 de sommes MD5, apt est capable de vérifier qu'un paquet est originaire d'une version bien spécifique. Ceci est moins souple que de signer chaque paquet un par un, mais peut être combiné également avec ce schéma suivant (voir ci-dessous).

Actuellement, ce schéma est complètement implémenté dans apt 0.6 qui est maintenant disponible dans la distribution unstable ; pour plus d'informations, voir Apt-secure, Section 7.4.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. Parmi les frontaux qui sont déjà référencés comme fonctionnant correctement avec cette fonctionnalité, citons aptitude et synaptic.

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.4.2 Apt-secure

La version 0.6 d'apt inclut apt-secure qui est un outil permettant à l'administrateur système de tester l'intégrité des paquets téléchargés par le schéma ci-dessus. Cette version inclut l'outil apt-key pour ajouter de nouvelles clés au porte-clés d'apt qui n'inclut par défaut que la clé actuelle de signature de l'archive Debian.

Ces changements sont basés sur un correctif pour apt (disponible dans le bogue n°\|[nbsp ]\|203741) qui fournit cette implémentation.

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

Notez que, lors de l'utilisation de la version d'apt, 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. Ceci 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.4.3 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 quand aucun paquet n'a jamais existé pour ceux-ci qui puisse être utilisé 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 incluses dans le .deb lui-même. Debian a déjà la capacité de faire cela actuellement, mais l'implémentation de cette règle et des outils ne commencera pas avant la sortie de Woody.

Les dernières versions de dpkg (à partir de la version 1.9.21) incluent 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.

Note2 : 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 des vérifications de version comme décrit précédemment.

7.4.4 Alternative à la vérification des versions 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 plus récente version d'apt (bien que vous apprécierions qu'elle soit testée), 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 instable 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 :

Ceci 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 plus d'informations, lisez 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 "OK"
                             return
                     fi
                     echo "$FILE" >>MISSING
                     echo "MISSING $Y"
                     return
             fi
             if [ "$Y" = "" ]; then
                     echo "$FILE" >>NOCHECK
                     echo "NOCHECK"
                     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 "BAD"
                     return
             fi
             echo "$FILE" >>OK
             echo "OK"
     }
     
     echo
     echo "Checking sources in /etc/apt/sources.list:"
     echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
     echo
     (echo "You should take care to ensure that the distributions you're downloading
     "
     echo "are the ones you think you are downloading, and that they are as up to"
     echo "date as you would expect (testing and unstable should be no more than"
     echo "two or three days out of date, stable-updates no more than a few weeks"
     echo "or a month)."
     ) | 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 "  * NO TOP-LEVEL Release FILE"
                     >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 Origin: $origline/$lablline"
                     echo "  o Suite: $suitline/$codeline"
                     echo "  o $dateline"
                     echo "  o $dscrline"
     
                     if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeline" ]; then
                             echo "  * WARNING: asked for $dist, got $suitline/$codeline"
                     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 "  * Signed by ${err# } key: ${rest#* }"
                                 else
                                     echo "  o Signed by: ${rest#* }"
                                     okay=1
                                 fi
                                 err=""
                             elif [ "$gpgcode" = "BADSIG" ]; then
                                 echo "  * BAD SIGNATURE BY: ${rest#* }"
                                 err=""
                             elif [ "$gpgcode" = "ERRSIG" ]; then
                                 echo "  * COULDN'T CHECK SIGNATURE BY KEYID: ${rest %% *}"
                                 err=""
                             elif [ "$gpgcode" = "SIGREVOKED" ]; then
                                 err="$err REVOKED"
                             elif [ "$gpgcode" = "SIGEXPIRED" ]; then
                                 err="$err EXPIRED"
                             fi
                         done
                         if [ "$okay" != 1 ]; then
                             echo "  * NO VALID SIGNATURE"
                             >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 "  * PROBLEMS WITH $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 "  * PROBLEMS WITH component $comp ($X, $Y)"
                             fi
                     fi
             done
             [ "$okaycomps" = "" ] || echo "  o Okay:$okaycomps"
             echo
       done
     
     echo "Results"
     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 "The following files in /var/lib/apt/lists have not been validated."
         echo "This could turn out to be a harmless indication that this script"
         echo "is buggy or out of date, or it could let trojaned packages get onto"
         echo "your system."
         ) | fmt
         echo
         sed 's/^/    /' < UNVALIDATED
         echo
     fi
     
     if grep -q ^ BAD; then
         allokay=false
         (echo "The contents of the following files in /var/lib/apt/lists does not"
         echo "match what was expected. This may mean these sources are out of date,"
         echo "that the archive is having problems, or that someone is actively"
         echo "using your mirror to distribute trojans."
         if am_root; then 
             echo "The files have been renamed to have the extension .FAILED and"
             echo "will be ignored by 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 "The following files from /var/lib/apt/lists were missing. This"
         echo "may cause you to miss out on updates to some vulnerable packages."
         ) | fmt
         echo
         sed 's/^/    /' < MISSING
         echo
     fi
     
     if grep -q ^ NOCHECK; then
         allokay=false
         (echo "The contents of the following files in /var/lib/apt/lists could not"
         echo "be validated due to the lack of a signed Release file, or the lack"
         echo "of an appropriate entry in a signed Release file. This probably"
         echo "means that the maintainers of these sources are slack, but may mean"
         echo "these sources are being actively used to distribute trojans."
         if am_root; then 
             echo "The files have been renamed to have the extension .FAILED and"
             echo "will be ignored by 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 'Everything seems okay!'
         echo
     fi
     
     rm -rf /tmp/apt-release-check

Il est possible que vous deviez ajouter le correctif suivant pour Sid car md5sum ajoute un '-' après la somme quand l'entrée est stdin : 

     @@ -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 "BAD"

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

Manuel de sécurisation de Debian

Version: 3.4, Sun, 06 Nov 2005 22:34:04 +0100

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

version française par Frédéric Bothamy (traducteur actuel)
Pierre Machard et Arnaud Assad (anciens traducteurs)
et les membres de la liste debian-l10n-french@lists.debian.org