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
2.95 31 mayo 2004Vendredi 4 juillet 2003 23:13:42 +0100jfs@computer.org