The Uncomfortable Truth About Linux Security Defaults
Cette vidéo démontre que la sécurité sous Linux n’est pas un acquis lié au choix du système d’exploitation, mais une série de décisions techniques précises que la grande majorité des distributions populaires ne prennent pas par défaut, laissant l’utilisateur seul face à des ri...
SYNTHÈSE STRUCTURÉE
Le mythe de la sécurité automatique sous Linux
L’intervenant commence par déconstruire une croyance répandue : « I left Windows, I installed Linux, therefore I am now more secure ». Il explique que la sécurité n’est pas une propriété inhérente à un OS, mais un ensemble de choix techniques vérifiables. La plupart des distributions ne configurent rien par défaut, et ce qui n’est pas demandé à l’installation reste souvent désactivé. Le problème est structurel : l’utilisateur moyen n’est jamais invité à activer ces protections, et il ne le fait jamais.
Le contrôle d’accès discrétionnaire (DAC) : une faiblesse structurelle
Le modèle Unix classique (permissions rwx par utilisateur/groupe/autre) a 50 ans et un défaut fondamental : « Whoever owns the process decides who can access what ». Si une application compromise tourne avec vos droits, l’attaquant hérite de tout ce que vous pouvez faire. Par exemple, votre navigateur n’a pas besoin de lire vos clés SSH, mais rien ne l’en empêche au niveau du système si le processus a vos permissions.
Le contrôle d’accès obligatoire (MAC) : SELinux et AppArmor
Le MAC ferme cette brèche en imposant des règles au-dessus des permissions Unix, directement dans le noyau. SELinux étiquette chaque processus, fichier et socket avec un contexte de sécurité. Le noyau applique des règles explicites : « Your browser, on a properly configured SELinux system, has a domain that simply does not include permission to read the context associated with SSH keys ». AppArmor utilise des profils basés sur le chemin d’accès de l’exécutable, plus faciles à écrire et à lire, mais avec une granularité légèrement inférieure. Les deux représentent un saut catégoriel par rapport à l’absence totale de MAC.
Les distributions spécialisées : Qubes, Whonix, Tails
Ces projets placent la sécurité comme principe architectural non négociable dès la conception. Qubes isole chaque domaine de vie (travail, banque, email) dans des machines virtuelles séparées au niveau de l’hyperviseur. Whonix force tout le trafic réseau à passer par Tor via deux VM (workstation + gateway). Tails applique l’amnésie totale au redémarrage : rien ne persiste sauf ce qui est explicitement chiffré. L’intervenant les exclut de la comparaison car leur objectif est différent : « Security in these projects is not an extra the user switches on after reading a wiki. It is the reason the project exists ».
L’étude des 100 distributions les plus populaires
L’intervenant a analysé le top 100 des distributions selon l’intérêt utilisateur, en vérifiant trois critères :
- Le MAC est-il actif en mode enforcing dès le premier démarrage ?
- Un pare-feu est-il actif par défaut ?
- Quelles garanties sur l’intégrité de la chaîne d’approvisionnement (reproductibilité des paquets) ?
Résultat : « Across the entire top 100, I found exactly two lineages that meet the first criterion in a genuinely non-negotiable way, from first boot ».
Les deux seules lignées qui protègent par défaut
La première lignée est Fedora, qui active SELinux en enforcing et firewalld dès l’installation. Cette décision se propage à tous ses dérivés : Bazzite (qui ajoute l’immutabilité), Nobara, Red Hat, CentOS, Rocky, AlmaLinux, Ultramarine, Aurora. La seconde lignée est openSUSE avec AppArmor en enforcing et un pare-feu actif. L’intervenant insiste : ce ne sont pas neuf distributions indépendantes, mais deux décisions architecturales originales qui se transmettent automatiquement.
Les absents : Debian, Ubuntu, Arch et la quasi-totalité du top 100
Debian n’a ni MAC actif ni pare-feu préconfiguré. Ubuntu applique AppArmor seulement à une sélection partielle d’applications, et son problème structurel est le PPA : « Anyone can publish a PPA, and the average user adds one by copying and pasting from a forum with no practical way to verify who is actually behind that repository ». Arch et toute sa constellation (EndeavourOS, Manjaro, Garuda, CachyOS) n’activent aucun MAC par défaut et héritent de l’AUR, un dépôt communautaire sans revue centralisée. L’intervenant rappelle que des paquets malveillants ont déjà été téléchargés des milliers de fois avant d’être détectés. « The trust mechanism there is almost entirely social, not technical ».
L’exemple de XZ et la reproductibilité des paquets
Au printemps 2024, une backdoor a été découverte dans la bibliothèque de compression XZ, après deux ans de travail de l’attaquant pour gagner la confiance de la communauté. Elle a été détectée par hasard, à cause d’un demi-seconde de latence sur une connexion SSH. Cet incident a relancé l’urgence de la reproductibilité des paquets : si le binaire officiel est bit-à-bit identique à celui compilé par n’importe qui, une backdoor cachée dans l’étape de construction devient détectable. Debian a annoncé que la migration vers testing bloque désormais automatiquement tout paquet non reproductible. Fedora vise 99 % de paquets reproductibles. L’intervenant souligne : « This is proof that when a project decides something is truly non-negotiable, it finds a concrete technical way to enforce it ».
Le décalage entre l’infrastructure et les utilisateurs
Gentoo et Slackware offrent un contrôle absolu (flags USE, absence d’automatisation), mais ce modèle suppose un administrateur expérimenté. « Complexity was a natural filter for competence ». Or, Linux a gagné la bataille de l’adoption de masse : des utilisateurs quittent Windows pour fuir la télémétrie, ou installent Linux sur un ordinateur bas de gamme. Le problème est que « the technical infrastructure underneath has not evolved at the same speed as the user base running on top of it ». On livre des systèmes conçus pour des experts à des gens qui attendent une protection par défaut, comme celle d’un téléphone sorti de sa boîte.
L’absence de volonté collective
L’intervenant conclut que la technologie existe (SELinux, AppArmor, pare-feu, reproductibilité) depuis plus de 20 ans pour certains. Ce qui manque, c’est la volonté de traiter ces outils comme un minimum non négociable, et non comme une fonction avancée réservée aux initiés. Il cite l’AUR comme exemple de risque structurel minimisé : « The AUR in particular keeps getting treated as a minor detail instead of the structural risk that the facts I’ve just shown you prove it actually is ».
CONCEPTS CLÉS
- Contrôle d’accès discrétionnaire (DAC) : Modèle Unix classique où le propriétaire d’un processus décide des accès. Vulnérable car un processus compromis hérite des droits de l’utilisateur.
- Contrôle d’accès obligatoire (MAC) : Mécanisme noyau (SELinux, AppArmor) qui impose des règles indépendantes des permissions Unix, empêchant un processus compromis d’accéder à des ressources non autorisées.
- Reproductibilité des paquets : Propriété permettant à quiconque de recompiler le même code source et d’obtenir un binaire bit-à-bit identique à celui distribué. Détecte les backdoors cachées dans l’étape de construction.
- AUR (Arch User Repository) : Dépôt communautaire sans revue centralisée. Risque structurel car des paquets malveillants peuvent y être publiés et téléchargés massivement avant détection.
- PPA (Personal Package Archive) : Dépôt tiers pour Ubuntu, sans vérification de l’identité du mainteneur ni du contenu du script de construction.