Je mets régulièrement à jour mon système chaque fois qu'il m'informe des mises à jour logicielles. C'est l'une de ces choses auxquelles je fais confiance pour travailler sans connaître les détails, mais je suis devenu curieux récemment :comment puis-je le savoir

• le processus de vérification des mises à jour n'affichera que les mises à jour légitimes ?
• les mises à jour que je reçois et que j'installe ne sont pas malveillantes ?

Je sais que j'ai un ensemble de sources de logiciels que je spécifie moi-même par URL et que je décide si je fais confiance à ces sources. Mais que se passe-t-il une fois que j'ai spécifié ces URL ?

D'après ce qui est courant de nos jours, je soupçonnerais que l'authenticité de ces sources est vérifiée avec quelque chose comme HTTPS / SSL, c'est-à-dire. e. J'ai des certificats qui sont vérifiés par rapport à une autorité, ce qui signifie que j'ai besoin de certificats racine fiables installés quelque part (ils sont probablement fournis avec le système).

De plus, je suppose que les packages sont signés de manière cryptographique, comme avec GPG ou similaire.

Ces hypothèses sont-elles correctes ? Où puis-je inspecter les clés/certificats utilisés ? Comment puis-je vérifier si ce sont les bons ? Comment puis-je vérifier qu'ils sont effectivement utilisés ? Existe-t-il des options de configuration qui rendent le processus plus ou moins prudent, et quelles sont leurs valeurs par défaut ? Existe-t-il des attaques connues ou y a-t-il eu des vulnérabilités récemment ? Il me semble me souvenir que Windows avait eu un problème comme celui-là il n'y a pas longtemps.

Je suis sur 12.04, mais je suppose que cela peut être répondu de manière plus générale.

Réponse acceptée :

c'est une excellente question. La réponse est (bien sûr) assez complexe, mais laissez-moi essayer de la décomposer pour vous. Voyons d'abord les processus techniques :

La chaîne de confiance

Nous n'utilisons pas SSL pour sécuriser APT, nous utilisons des hachages cryptographiques (SHA256, de nos jours) et des signatures OpenPGP. Cela vous permet de faire confiance à des miroirs non approuvés et évite d'avoir à faire confiance à CA PKI.

Lorsque vous ajoutez un dépôt au sources.list d'APT , vous devez également ajouter sa clé PGP au trousseau de clés de confiance d'APT, avec le apt-key commande. Le porte-clés est livré avec les clés des référentiels d'Ubuntu inclus. Et lorsque vous utilisez le apt-add-repository commande pour ajouter un PPA, il ajoute la clé (obtenue à partir de Launchpad via SSL) pour vous.

La chaîne de confiance est :

1. Chaque sources.list point d'entrée APT vers une Release fichier dans le référentiel, avec un Release.gpg signature (ou ils peuvent être combinés en tant que InRelease dossier). Ce fichier décrit le référentiel et doit être signé par une clé dans le trousseau de clés de votre APT.
2. La Release le fichier contient les hachages cryptographiques de tous les Packages et Sources des dossiers. Celles-ci répertorient tous les packages et versions disponibles dans le référentiel.
3. Les Packages et Sources les fichiers contiennent les hachages cryptographiques de chaque paquet.
4. Les packages eux-mêmes ne sont pas signés. C'est inutile, il y a une chaîne de confiance vers eux, à partir du fichier Release, signé par le miroir. Cependant, les packages source, utilisés pour créer les packages binaires, sont signés PGP par le développeur qui les a téléchargés.

Vous pouvez en savoir plus sur le format du dépôt sur le wiki Debian.

Cette chaîne signifie que nous n'avons pas à faire confiance à des miroirs intermédiaires, nous pouvons être sûrs que le paquet que nous installons est identique à celui présent lors de la signature du fichier Release.

Vous pouvez inspecter le trousseau de clés d'APT en exécutant sudo apt-key finger .

Vérification des clés d'archive d'Ubuntu

Comment savez-vous ce qui devrait être là? Si vous ne faites pas confiance à votre ordinateur, vous ne pouvez faire confiance à aucun programme dessus pour ne pas vous mentir (comme apt-key ), et cet exercice est futile. Supposons donc que ce soit juste par intérêt académique et vérifions le contenu du trousseau de clés à partir du paquet source définitif, qui est PGP signé par le développeur qui l'a téléchargé.

Connexes :Avoir des espaces de travail 2 × 2 dans Gnome 3 dans Ubuntu ?

Téléchargez le ubuntu-keyring paquet source, et voyez ce qui devrait s'y trouver :

$ apt-get source ubuntu-keyring
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Need to get 20.0 kB of source archives.
Get:1 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (dsc) [1542 B]
Get:2 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (tar) [18.5 kB]
Fetched 20.0 kB in 0s (0 B/s)               
dpkg-source: info: extracting ubuntu-keyring in ubuntu-keyring-2012.05.19
dpkg-source: info: unpacking ubuntu-keyring_2012.05.19.tar.gz
$ gpg --verify ubuntu-keyring_2012.05.19.dsc
gpg: Signature made Sat May 19 03:33:12 2012 SAST
gpg:                using RSA key 0x393587D97D86500B
gpg: Good signature from "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
$ gpg --no-default-keyring --keyring ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg --fingerprint
ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg
-------------------------------------------------------------
pub   1024D/0x40976EAF437D05B5 2004-09-12
      Key fingerprint = 6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid                            Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/0x251BEFF479164387 2004-09-12

pub   1024D/0x46181433FBB75451 2004-12-30
      Key fingerprint = C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid                            Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/0x3B4FE6ACC0B21F32 2012-05-11
      Key fingerprint = 790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid                            Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/0xD94AA3F0EFE21092 2012-05-11
      Key fingerprint = 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid                            Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

Je sais qu'il s'agit en fait de la signature de Colin Watson, car je l'ai rencontré plusieurs fois et nous avons vérifié l'identité de l'autre et signé les clés de l'autre. Si vous avez une clé dans l'ensemble fort de PGP, vous devriez pouvoir lui trouver un chemin de confiance. Je sais aussi que je peux lui faire confiance pour télécharger le bon ubuntu-keyring paquet.

Pour Debian, il existe un paquet (debian-keyring ) contenant les clés PGP de tous les développeurs Debian, et vous pouvez l'utiliser pour vérifier les signatures des paquets source. Ubuntu n'a pas d'équivalent, mais de nombreux développeurs Ubuntu sont également des développeurs Debian, et toutes les clés PGP de nos développeurs sont disponibles sur leurs profils dans Launchpad.

Les autres questions

Comment savoir si les mises à jour ne sont pas malveillantes ?

Cela se résume à la confiance. Vous devez faire entièrement confiance à chaque référentiel que vous utilisez. Vous donnez aux mainteneurs de chaque référentiel la permission d'exécuter des choses en tant que root sur votre machine.

Les packages Ubuntu ne peuvent être téléchargés que par les développeurs Ubuntu qui ont obtenu des droits de téléchargement par le Developer Membership Board (au sein duquel je siège actuellement). Pour demander des droits de téléchargement, vous devez être recommandé par plusieurs développeurs Ubuntu existants qui ont travaillé avec vous et font confiance à vos capacités à travailler par vous-même. Sans droits de téléchargement, les téléchargements doivent être parrainés par les développeurs qui en ont les droits (ce qui devrait inclure l'examen du téléchargement).

Pour les mises à jour post-publication, Ubuntu a des politiques strictes sur le contenu des mises à jour. Ils ne doivent contenir que des correctifs minimaux pour corriger les bogues connus. Les correctifs sont revus par les membres des équipes SRU / Sécurité avant d'être acceptés.

De toute évidence, les PPA et les référentiels tiers n'ont pas toutes ces restrictions. Vous devez faire confiance aux propriétaires de PPA pour être raisonnables.

Tous les packages Ubuntu et PPA ont la source disponible, de sorte qu'ils peuvent être inspectés par n'importe qui.

Existe-t-il des options de configuration qui rendent le processus plus ou moins prudent, et quelles sont leurs valeurs par défaut ?

Vous pouvez désactiver la vérification de signature dans APT, mais bien sûr, elle est activée par défaut. Lorsque vous essayez d'installer quelque chose à partir d'un référentiel non signé / non approuvé, apt vous fait confirmer que vous voulez vraiment le faire.

Existe-t-il des attaques connues ou y a-t-il eu des vulnérabilités récemment ?

Je me souviens d'un bogue Debian 499897. Debian contourne ce problème en donnant aux fichiers Release une date d'expiration, après laquelle on ne peut plus leur faire confiance. Ubuntu ne le supporte pas encore.

En relation :Comment rechercher le nom de l'espace de travail actuel ?