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é :
team@security.debian.org
qui
n'est lu que par les membres de l'équipe de sécurité.
security@debian.org
qui
est lu par tous les développeurs Debian (y compris l'équipe de sécurité). Les
messages envoyés sur cette liste ne sont pas publiés sur l'Internet (ce n'est
pas une liste publique).
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 Se
mettre à jour au niveau de la sécurité, Section 4.8). 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.
Les alertes de sécurité Debian sont effectuées à chaque fois qu'une faille est découverte affectant un paquet Debian. Ces alerte, 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
(une fois par jour), 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é comme CVE
, Notes de failles CERT/CC
ou Bugtraq
. 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 :
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écurié
é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'envoir, 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és, 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 la corriger.
L'archive d'envoi de sécurité fonctionner donc de la façon suivante (dénommée "Accepted-Autobuilding") :
dpkg-scanpackages
,
dpkg-scansources
, etc.),
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 issues pour toutes les architectures supportées (presque vingt) en moins d'un jour.
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.
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 de version, 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).
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.
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 ne de 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 :
buildd
ne construira pas
ceux-ci.
pbuilder
et debootstrap
peuvent
s'avérer utiles dans ce cas).
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.
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.
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 improtante 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. [25]
À ce jour (février 2003), Debian ne fournit pas de paquets signés pour la distribution et la version woody (3.0) n'intègre pas cette fonctionnalité. Il existe une solution pour les paquets signés qui sera, espérons-le, fournie dans les prochaines versions (sarge).
Ce problème est mieux décrit dans le Strong
Distribution HOWTO
par V. Alex Brennen.
Le schéma actuel (non implémenté) 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).
La signature de paquets a été abordée dans la 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/
.
Le schéma complémentaire concernant la signature de chaque paquet autorise les paquets à être vérifiés quand ils ne sont plus référencés par un fichier Packages existant, les paquets tiers pour lesquels aucun fichier Packages n'existe peuvent également être utilisés avec la Debian mais n'entre pas dans le système par défaut.
Ce schéma de signature par paquet peut être implémenté en utilisant
debsig-verify
et debsigs
. Ces deux paquets peuvent
signer et vérifier les signatures incluses dans le .deb lui-même. Debian a
déjà la capacité de le faire maintenant mais l'implémentation de cette
politique et de ces outils ne démarrera qu'après la sortie de la woody.
Les dernières versions de dpkg (depuis la 1.9.21) incluent un correctif
qui fournit cette fonctionnalité dès que debsig-verify
est
installé.
Note : Actuellement /etc/dpkg/dpkg.conf
est livré avec
« no-debsig » par défaut.
Note2 : Les signatures des développeurs sont actuellement épurées quand elles entrent dans l'archive des paquets car la méthode préférée actuellement est les vérifications de distribution comme décrit précédemment.
Au cas où vous voudriez ajouter des vérifications de sécurité supplémentaires, vous pouvez utiliser le script ci-dessous fourni par Anthony Thown. Ce script peut automatiquement faire certaines nouvelles vérifications de sécurité qui permettent à l'utilisateur d'être sûr que le logiel 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 exmple, renommé en apt-release-check
, devrait être utilisé
de la manière suivante :
# apt-get update # apt-release-check (...résultats...) # apt-get dist-upgrade
Avant tout, vous avez besoin de :
http://ftp-master.debian.org/ziyi_key.asc
,
et les ajouter à ~/.gnupg/trustedkeys.gpg
(ce qui est ce que
gpgv
utilise par défaut).
gpg --no-default-keyring --keyring trustedkeys.gpg --import ziyi_key_2003.asc
/etc/apt/sources.list
qui n'utilisent
pas la structure normale « dists » ou changer le script afin qu'il
fonctionne avec elles.
Ceci est le code exemple pour apt-check-sigs
, la dernière version
peut être récupérée de 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 # This script is copyright (c) 2001, Anthony Towns # # 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` `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 wget -q -O Release "${url}/dists/${dist}/Release" if ! grep -q '^' Release; then echo " * NO TOP-LEVEL Release FILE" 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 wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg" sigline="`gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/null 2>&1 | sed -n "s/^\[GNUPG:\] GOODSIG [0-9A-Fa-f]* //p"`" if [ "$sigline" ]; then echo " o Signed by: $sigline" else 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"
Manuel de sécurisation de Debian
Version: 2.95 (CVS revision 1.113), Fri, 03 Dec 2004 23:31:54 +0000jfs@debian.org
debian-l10n-french@lists.debian.org