APT-SECURE(8) APT APT-SECURE(8) NOM apt-secure - Gestion de l'authentification d'archive avec APT DESCRIPTION Depuis sa version 0.6, apt sait verifier la signature du fichier Release de chaque depot. On s'assure ainsi que les paquets dans l'archive ne peuvent pas etre modifies par quelqu'un qui ne possede pas la cle de la signature du fichier Release. A partir de la version 1.1, apt exige que les depots fournissent des informations recentes d'authentification pour une utilisation libre du depot. Depuis la version 1.5, les modifications dans les informations contenues dans le fichier Release sur le depot, doivent etre confirmees avant qu'APT continue a appliquer les mises a jour depuis ce depot. Attention : toutes les interfaces de gestion de paquets comme apt- get(8), aptitude(8) et synaptic(8) possedent cette fonction de certification, aussi cette page de manuel utilise APT pour se referer a l'ensemble d'entre elles, pour des raisons de simplicite. DEPOTS NON SIGNES Si une archive possede un fichier Release non signe ou pas de fichier Release du tout, les versions actuelles d'APT refuseront par defaut d'en telecharger des donnees dans les operations update. Meme si un frontal tel que apt-get(8) est force de telecharger, il demandera une confirmation explicite si une installation inclut un paquet d'une archive non authentifiee. Vous pouvez contraindre les clients APT a n'emettre que des avertissements en configurant l'option Acquire::AllowInsecureRepositories a true. L'option allow-insecure=yes de sources.list(5) peut aussi permettre a des depots individuels d'etre non securises. Veuillez noter que les depots non securises sont fortement deconseilles et toutes les options pour contraindre APT a continuer a les prendre en charge devront etre eventuellement supprimees. Les utilisateurs disposent aussi de l'option Trusted pour desactiver meme les avertissements, mais il faut etre sur de comprendre ses implications detaillees dans sources.list(5). Un depot qui auparavant etait authentifie, mais qui perdrait cet etat lors d'une operation update envoie un message d'erreur a tous les clients d'APT quelle que soit l'option d'autoriser ou d'interdire l'utilisation de depots non securises. L'erreur peut etre contournee par le reglage supplementaire de Acquire::AllowDowngradeToInsecureRepositories a true, ou, pour des depots individuels avec l'option allow-downgrade-to-insecure=yes de sources.list(5). DEPOTS SIGNES D'une archive APT jusqu'a l'utilisateur, la chaine de confiance se construit en plusieurs etapes. Apt-secure est la derniere etape. Faire confiance a une archive ne signifie pas que les paquets qu'elle contient sont exempts de code malveillant, mais signifie que vous faites confiance au responsable de l'archive. C'est ensuite au responsable de l'archive de faire en sorte que l'archive soit fiable. Apt-secure n'examine pas la signature d'un paquet. Certains programmes peuvent le faire comme debsig-verify ou debsign, qu'on peut trouver dans les paquets debsig-verify et devscripts. La chaine de confiance dans Debian commence, par exemple, quand un responsable de paquet envoie un nouveau paquet ou une nouvelle version d'un paquet dans l'archive. Cet envoi, pour etre effectif, doit etre signe avec la cle d'un responsable qui se trouve dans un des trousseaux des responsables de paquet Debian (disponibles dans le paquet debian-keyring). Les cles des responsables de paquet sont signees par d'autres responsables, suivant des procedures preetablies pour s'assurer de l'identite des proprietaires de la cle. Des procedures similaires existent dans toutes les distributions basees sur Debian. Une fois que le paquet envoye a ete verifie et inclus dans l'archive, la signature du responsable est enlevee, une somme de controle du paquet est calculee et mise dans le fichier Packages. Une somme de controle de tous les paquets est ensuite calculee et mise dans le fichier Release. Ce fichier est signe par la cle de l'archive pour la version courante de la distribution et distribuee en meme temps que les paquets et les fichiers Packages sur les miroirs. Les cles sont dans le trousseau de cles de l'archive fournies par le paquet debian-archive-keyring. Un utilisateur peut consulter la signature du fichier Release, extraire la somme de controle d'un paquet et la comparer avec la somme du paquet qu'il a telecharge, ou tout simplement compter sur APT pour faire ces operations automatiquement. Cette facon de faire est differente d'une verification de la signature d'un paquet. Elle vise a empecher deux types d'attaque possibles : o Attaque reseau de type << homme au milieu >>. Sans verification de signature, quelqu'un de malveillant peut s'introduire au milieu du processus de telechargement et inserer du code soit en controlant un element du reseau, routeur, commutateur, etc. soit en detournant le trafic vers un serveur fourbe (par usurpation d'adresses). o Attaque par compromission d'un miroir sur le reseau. Sans verification de signature, quelqu'un de malveillant peut compromettre un miroir et modifier les fichiers. Ainsi tous ceux qui telechargent les paquets de ce miroir propagent du code malveillant. Cependant cette methode ne protege pas contre une compromission du serveur principal lui-meme (qui signe les paquets) ni contre la compromission de la cle qui sert a signer les fichiers Release. Mais elle peut completer la signature des paquets. MODIFICATIONS DES INFORMATIONS Le fichier Release renferme, en plus des sommes de controle pour les fichiers du depot, des informations generales sur le depot comme l'origine, le nom de code ou le numero de la version. Ces informations apparaissent a plusieurs endroits, aussi, le proprietaire d'un depot devrait toujours s'assurer de leur exactitude. Par ailleurs, les configurations de l'utilisateur, comme apt_preferences(5), peuvent dependre de ces informations et les utiliser. Depuis la version 1.5, l'utilisateur doit par consequent confirmer de facon explicite les modifications pour signaler qu'il est suffisamment prepare, par exemple, pour la nouvelle version majeure de la distribution fournie dans le depot (comme indique par exemple par le nom de code). CONFIGURATION UTILISATEUR Le programme qui gere la liste des cles utilisees par APT pour faire confiance aux depots s'appelle apt-key. Il peut ajouter ou supprimer des cles aussi bien que lister les cles de confiance. Il est possible de limiter la capacite pour une ou plusieurs cles de signer telle ou telle archive avec l'option Signed-By dans sources.list(5). Veuillez noter qu'une installation par defaut possede toutes les cles pour obtenir en toute securite des paquets des depots par defaut, aussi, bricoler avec apt-key n'est necessaire que si vous souhaitez ajouter des depots tiers. Pour ajouter une cle, vous devez d'abord la telecharger. Il vaut mieux utiliser un canal fiable pour ce telechargement. Ensuite vous l'ajoutez avec la commande apt-key et vous lancez la commande apt-get update pour telecharger et verifier le fichier InRelease ou Release.gpg de l'archive que vous avez configuree. CONFIGURATION DU DEPOT Si vous voulez signer les archives dont vous avez la responsabilite, vous devez : o creer un fichier Release a la racine de l'archive, s'il n'existe pas deja. Vous pouvez le creer avec la commande apt-ftparchive release (fournie dans le paquet apt-utils). o le signer, avec les commandes gpg --clearsign -o InRelease Release et gpg -abs -o Release.gpg Release. o publier l'empreinte de la cle. Ainsi les utilisateurs de votre archive connaitront la cle qu'ils doivent importer pour authentifier les fichiers de l'archive. Le mieux est de diffuser sa cle dans son propre paquet de trousseau comme le fait Debian avec debian-archive-keyring pour ensuite distribuer automatiquement les mises a jour et les transitions de cles. o fournir les instructions pour ajouter l'archive et la cle. Si les utilisateurs ne peuvent recuperer de facon sure votre cle, la chaine de confiance decrite plus haut est rompue. La facon d'aider les utilisateurs a ajouter votre cle de l'archive depend de l'archive et de l'audience cible : cela va d'un paquet de trousseau inclus dans une autre archive que des utilisateurs ont deja configuree (comme les depots par defaut de leur distribution) a la mobilisation du web de confiance. Chaque fois que le contenu de l'archive change, (suppression ou ajout de nouveaux paquets) le responsable doit refaire les deux premieres etapes. VOIR AUSSI apt.conf(5), apt-get(8), sources.list(5), apt-key(8), apt- ftparchive(1), debsign(1), debsig-verify(1), gpg(1) Pour des informations plus completes, vous pouvez consulter l'infrastructure debian pour la securite[1] un chapitre du manuel Debian sur la securite (disponible dans le paquet harden-doc) et le Strong Distribution HOWTO[2] par V. Alex Brennen. BOGUES Page des bogues d'APT[3]. Si vous souhaitez signaler un bogue a propos d'APT, veuillez lire /usr/share/doc/debian/bug-reporting.txt ou utiliser la commande reportbug(1). AUTHOR APT a ete ecrit par l'equipe de developpement APT . AUTEURS DES PAGES DE MANUEL Cette page a ete ecrite a partir des travaux de Javier Fernandez-Sanguino Pena, Isaac Jones, Colin Walters, Florian Weimer et Michael Vogt. TRADUCTEURS Jerome Marant, Philippe Batailler, Christian Perrier (2000, 2005, 2009, 2010), Equipe de traduction francophone de Debian Veuillez noter que cette traduction peut contenir des parties non traduites. Cela est volontaire, pour eviter de perdre du contenu quand la traduction est legerement en retard sur le contenu d'origine. AUTEURS Jason Gunthorpe Equipe de developpement d'APT NOTES 1. l'infrastructure debian pour la securite https://www.debian.org/doc/manuals/securing-debian-howto/ch7 2. Strong Distribution HOWTO http://www.cryptnet.net/fdp/crypto/strong_distro.html 3. Page des bogues d'APT https://bugs.debian.org/src:apt APT 2.9.5 06 aout 2016 APT-SECURE(8)