Fin 2024, Radically Open Security a effectué un nouvel audit de sécurité autour des parties critiques de Tails.

Pour mieux protéger les personnes utilisant Tails, nous avons traité les failles de sécurité dès qu'elles ont été découvertes et qu'elles nous sont parvenues, sans attendre que l'audit soit terminé et rendu public.

Nous pouvons maintenant vous partager le rapport final.

Les personnes ayant fait l'audit ont conclu que :

Le système d'exploitation Tails donne une forte impression de sécurité, réglant la majorité des préoccupations liées à l'anonymat. Nous n'avons pas trouvé de vulnérabilités d’exécution à distance de code, et tous les problèmes identifiés exigeaient un compte d'utilisation à faible privilège amnesia compromis – le compte d'utilisation par défaut de Tails.

En regardant l'audit précédent, nous pouvons remarquer que les personnes développant Tails ont fait des progrès significatifs, démontrant une expertise et un investissement sérieux sur la sécurité.

Constatations

Les personnes ayant fait l'audit n'ont pas identifié de vulnérabilités dans :

• La création du stockage persistant utilisant LUKS2, apparut dans Tails 5.14 (juin 2023)

• Nos améliorations de sécurité dans Thunderbird

• La fonctionnalité de graine aléatoire, apparut dans Tails 6.4 (juin 2024)

Les personnes ayant fait l'audit ont trouvé quatre problèmes dans :

• Le mécanisme de mise à jour automatique

• D'autres changements importants depuis Tails 5.8 (novembre 2023)

Post-mortem

Notre équipe n'a pas seulement résolu ces problèmes. Nous avons créé un post-mortem pour comprendre comment nous avons introduit ces vulnérabilités dans nos versions et comment empêcher des vulnérabilités similaires dans le futur. Cette analyse a amené des changements techniques, culturels et politiques.

Cette analyse a été utile et nous allons définitivement considérer faire plus de post-mortems dans le futur. Il serait aussi intéressant pour d'autres projets de comprendre comment nous avons travaillé sur ces améliorations durables.

Améliorations techniques

• Post-mortem de OTF-001

  Durant la préparation d'une mise à jour majeur de Tails se basant sur une nouvelle version de Debian, par exemple, Tails 7.0, nous regarderons le code Perl inclus dans Tails qui modifie @INC de façon dangereuse. (#19627)

  De plus, nous vérifions automatiquement la présence de potentielles vulnérabilités de code Mite et nous faisons échouer la construction si nous en trouvons un.

• Post-mortem de OTF-002 (#20719 et !1911)

  Notre intégration continue assure maintenant que notre logiciel Python personnalisé s’exécute dans un mode isolé.

• Post-mortem de OTF-003 (#20711 et !1979)

  Notre configuration sudo est maintenant générée depuis une description haut niveau, qui a des valeurs par défauts plus sûres et demande des explications quand elle diverge de ces dernières.

• Post-mortem de OTF-004 (#20817 et !2040)

  Notre intégration continue s'assure désormais que nous n'écrivions pas de logiciel effectuant une recherche de fichiers .desktopnon sécurisée.

  Nous auditerons aussi périodiquement la configuration de onion-grater, notre pare-feu pour le port de contrôle Tor. (#20821)

Améliorations en matière de politique et de culture

• Durant l'audit, nous avons constaté un manque de règle sur quand nous devrions rendre publics les problèmes de sécurité confidentiels.

  Ceci est problématique car :

  • Nous avons parfois fait preuve de trop de discrétion.

    Comme mesure temporaire, cela protégeait les personnes utilisant Tails en jouant la carte de la prudence. Mais, sans processus de publication, nous n'atteignions pas nos propres standards de transparence et d'ouverture aux revues par des tiers.

  • Différents membres de l'équipe travaillaient avec des présomptions différentes, ce qui a causé des problèmes de communication.

  Afin d'avoir de meilleures lignes directrices concernant la confidentialité et la divulgation, nous avons créé notre politique de réponse aux problèmes de sécurité, basée sur la politique de l'équipe réseau du projet Tor.

• Nous ferons plus attention au ratio risque/effort lié à un remaniement profond du code.

  Si un remaniement du code est nécessaire pour un processus de développement logiciel sain, ce post-mortem a démontré qu'un remaniement important peut aussi introduire des failles de sécurité.

• Lors d'un changement autour de code lié à un point de sécurité, comme notre configuration sudo ou tout autre code lié à l'élévation de privilèges, nous demandons maintenant un avis supplémentaire centré sur la sécurité.

• Nous communiquerons sur les problèmes de sécurité plus largement dans notre équipe lors de leur découverte, afin que chaque membre puisse apprendre tout du long.