6.6. Vérification d'authenticité des paquets

Étant donné l'importance qu'accordent les administrateurs de Falcot SA à la sécurité, ils veulent s'assurer de n'installer que des paquets garantis provenant de Debian et non altérés en cours de route. En effet, un pirate pourrait tenter d'agir indirectement sur des machines en modifiant un paquet Debian diffusé afin d'y ajouter les instructions de son choix. Si un paquet ainsi modifié est installé, ces instructions agiront, par exemple afin de dérober les mots de passe. C'est pourquoi Debian offre un moyen de s'assurer que le paquet installé provient bien de son mainteneur et qu'il n'a subi aucune modification par un tiers : il existe un mécanisme de scellement des paquets.

The seal works with a chain of cryptographic hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/
debian-archive-bullseye-automatic.gpg
debian-archive-bullseye-security-automatic.gpg
debian-archive-bullseye-stable.gpg
debian-archive-buster-automatic.gpg
debian-archive-buster-security-automatic.gpg
debian-archive-buster-stable.gpg
debian-archive-stretch-automatic.gpg
debian-archive-stretch-security-automatic.gpg
debian-archive-stretch-stable.gpg

EN PRATIQUE Ajouter des clés de confiance

Lorsqu'une source de paquets tierce est ajoutée au fichier sources.list, il faut désormais porter à la connaissance de APT la clé de confiance correspondante (sans quoi il se plaindra constamment qu'il ne peut pas vérifier l'authenticité des paquets contenus dans le dépôt concerné). Pour cela, il faut avant tout récupérer la clé publique en question : la plupart du temps, elle sera fournie sous la forme d'un petit fichier texte (qui sera nommé cle.asc dans les exemples ci-dessous).

Pour ajouter la clé au trousseau de confiance d'APT, l'administrateur peut simplement la placer dans un fichier *.gpg dans /etc/apt/trusted.gpg.d/ (les fichiers*.asc sont déconseillés et peuvent causer des problèmes). Cela est géré depuis Debian Stretch. Avec les versions antérieures, la commande apt-key add < key.asc devait être exécutée, ce qui est considéré maintenant comme obsolète.

Bien qu'il s'agisse d'un comportement très courant, cela crée également un problème potentiel. APT ne sait pas quelle clé appartient à quel dépôt. Si l'une des clés du trousseau d'APT correspond à la signature d'une archive, APT considère l'archive comme authentifiée. Une fois qu'une clé a été ajoutée au trousseau de clés de confiance, un attaquant malveillant pourrait en fait fournir sa propre « version » d'un miroir Debian signé par la même clé. Il serait donc préférable de mettre la clé sous forme de fichier *.gpg dans /usr/share/keyrings/ et d'utiliser le champ Signed-By dans sources pour les dépôts tiers, comme le montre l'exemple ci-dessous.

Imaginez que la société Falcot Corp. gère son propre dépôt public et que vous souhaitiez l'utiliser. Elle l'a signé et fournit une clé ou un trousseau publics pouvant être téléchargés. Pour restreindre la clé à celle du dépôt, vous pouvez simplement faire ceci :

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Soyez conscient que l'ajout et l'utilisation de dépôts tiers posent toujours un risque de sécurité et de stabilité !

Once the appropriate keys are in the keyring, APT will check the signatures before any risky operation, so that frontends will display a warning if asked to install a package whose authenticity can't be ascertained.

Notez que les paquets binaires ne sont généralement pas signés. L'intégrité d'un paquet ne peut être confirmée qu'en vérifiant ses sommes de hachage par rapport à une source de hachage fiable (et éventuellement signée).

SPECIFIC CASE Unsigned repositories

Bien qu'en général les dépôts non signés ne doivent pas être utilisés, certains utilisateurs peuvent en avoir besoin, par exemple pour fournir des paquets construits localement. APT peut être forcé d'accepter un tel dépôt en faisant précéder l'URL du dépôt par allow-insecure=yes ou trusted=yes. Nous allons le démontrer en utilisant l'exemple de la Section 15.3, « Créer une archive de paquets pour APT » :

deb [ trusted=yes ] http://packages.falcot.com/ updates/
deb [ trusted=yes ] http://packages.falcot.com/ internal/