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

To better protect our users, we addressed the security vulnerabilities as soon as they were discovered and reported to us, without waiting for the audit to be complete and public.

Nous pouvons maintenant vous partager le rapport final.

The auditors concluded that:

The Tails operating system leaves a strong security impression, addressing most anonymity-related concerns. We did not find any remote code execution vulnerabilities, and all identified issues required a compromised low-privileged amnesia user – the default user in Tails.

Looking back at the previous audit, we can see the Tails developers have made significant progress, demonstrating expertise and a serious commitment to security.

Constatations

The auditors did not identify any vulnerability in:

• 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)

The auditors found 4 issues in:

• Le mécanisme de mise à jour automatique

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

Postmortem

Our team went further than simply fixing these issues. We conducted a postmortem to understand how we introduced these vulnerabilities in our releases and what we could do to avoid similar vulnerabilities in the future. This analysis led to technical, policy, and culture changes.

This analysis was useful and we'll definitely consider doing postmortems again after future audits. It might also be useful for other projects to understand how we worked on these long-lasting improvements.

Améliorations techniques

• Postmortem de OTF-001

  While preparing a major Tails release based on a new version of Debian, for example, Tails 7.0, we will look for Perl code included in Tails that modifies @INC in a dangerous way. (#19627)

  De plus, nous vérifions automatiquement for potentially vulnerable Mite code and fail the build if we find any.

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

  Our CI now ensures that all our custom Python software runs in isolated mode.

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

  Our sudo configuration is now generated from a higher-level description, which has safer defaults and demands explanations when diverging from them.

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

  Our CI now ensures that we don't write software that does unsafe .desktop file lookup.

  We will also periodically audit the configuration of onion-grater, our firewall for the Tor control port. (#20821)

Policy and culture improvements

• During the audit, we noticed that we lacked a policy about when we should make confidential security issues public.

  This was problematic because:

  • We have sometimes been too secretive.

    As a temporary measure, this protected our users by erring on the safe side. But, without a disclosure process, we were not meeting our own standards for transparency and openness to third-party reviews.

  • Different team members were working with different assumptions, which caused communication issues.

  To have better guidelines for confidentiality and disclosure, we created our security issue response policy, based on the policy of the Tor Project's Network Team.

• We will be more intentional about when it's worth the effort and risk to do large code refactoring.

  While refactoring is necessary for a healthy software development process, this postmortem showed that large refactoring can also introduce security vulnerabilities.

• When changing security-sensitive code, such as our sudo configuration or any code that elevates privileges, we now require an extra review focused on security.

• We will communicate about security issues more broadly within our team when we discover them so that every team member can learn along the way.