Linux et la sécurité, tel un désert et un oasis ?
On entend souvent que Linux est un OS plus sécurisé que les autres. Mais qu'est-ce que ça veut dire, et est-ce vrai ? Posons-nous un court instant pour vérifier la véracité de cette association en l'an 2021...
Civilization runs on Linux
Linux est un noyau (pour résumer, le programme qui sert d'interface matériel/logiciel) inspiré des systèmes UNIX (dit UNIX-like). Il est utilisé dans divers appareils embarqués, sur des serveurs, sur des smartphones (Android), et en très petite partie sur des ordinateurs personnels. Sa sécurité est donc responsable du bon fonctionnement de la société, rien que ça.
Civilization runs on Linux. - [LWN.net]
Quand on parle de "Linux" sur Internet, on se réfère souvent aux distributions GNU/Linux (un OS complet qui associe le noyau Linux à l'userland GNU). Je vais commettre également cet abus de language par commodité, mais il faut impérativement garder à l'esprit ces différences.
Linux est souvent considéré comme une alternative plus sûre aux OS traditionnels et commerciaux (que sont Windows et macOS). Si cela a peut-être été le cas il y a plus d'une dizaine d'années, ce n'est plus tout à fait correct de nos jours. Ici, je critique particulièrement l'adaptation de Linux au modèle de sécurité desktop. Certaines parties sont plutôt universelles, mais gardez cela à l'esprit.
Quand on s'aime, on se dit les choses. - Moi-même
Je tiens à dire que j'utilise Linux au quotidien, sur mes serveurs (Debian, Alpine), parfois en environnement de développement, et bien sûr sur mon smartphone (GrapheneOS). J'ai également été un utilisateur quotidien de Linux sur desktop (I used Arch btw) principalement de 2011 à 2014, mais je suis toujours ce monde de près ; et puis je ne pourrais pas me passer du fameux WSL (Windows Subsystem for Linux).
Le mythe de la sécurité sur Linux
Sans plus attendre, rentrons dans le vif du sujet. Tout d'abord, on peut parler de l'absence de mitigations modernes (comprendre : mécanismes de protection) ainsi que de défauts techniques majeurs.
Défauts liés à l'écosystème dit GNU/Linux développé autour :
- L'absence de sandboxing efficace : toutes les applications ont accès aux mêmes données entre elles (modèle MS-DOS). Il suffit d'une application malveillante qui exploite une faille random et la partie est finie pour vos données. Une sandbox élaborée limiterait ces dommages.
- L'absence généralisée de CFI (Control Flow Integrity) qui empêche l'exploitation de processus notamment par des attaques de corruption liées à la mémoire. CFI est intensivement utilisé dans Chromium et Windows par exemple.
- L'usage massif dans les programmes de langages memory-unsafe tels que le C et le C++, qui sont prompts aux erreurs et aux attaques liées à la mémoire. Microsoft, par exemple, s'intéresse au Rust.
- L'absence de vérification d'intégrité au démarrage : Secure Boot en est une implémentation partielle seulement, qui ne fonctionne que sous certaines conditions avec certaines distributions GNU/Linux. Sur "desktop", cette forme de protection existe sur les PC Secured-Core (que Windows...), les Macbook post-2016 (T2 & ARM) ainsi que les Chromebooks.
- La partie se complique quand on s'intéresse à l'isolation au niveau de X (GUI), qui est encore un des exemples illustrant que la sécurité n'est pas prise au sérieux dans cet "écosystème" du libre. Non, même AppArmor ne suffira pas.
Défauts liés à Linux (le noyau) lui-même :
- Linux (le noyau) lui-même est écrit dans des langages memory-unsafe (et ça n'avance pas très vite), manque énormément en termes de mitigations et d'efforts centrés sur des bugs potentiellement dangereux (cf. ci-dessus).
- Il souffre de sa nature de noyau monolithique : un modèle lourd et ancien pensé pour les performances plutôt que la sécurité.
- Il souffre également de son évolution constante avec ajout de nouvelles fonctionnalités qui ne sont pas suffisamment testées, dans une base de code qui se complexifie sans cesse.
Ainsi, Linux dispose d'une grande surface d'attaque avec une masse de code privilégié colossale susceptible à de nombreux bugs dont la plupart est relative à la sûreté de la mémoire.
The kernel can effectively be thought of as the largest, most vulnerable setuid root binary on the system. - grsecurity
Ce sont des problèmes qui trainent depuis 10 ans déjà et qui sont ressassés chaque année encore par des contributeurs. Google est également un important contributeur en matière de sécurité à Linux, et insiste pour que certains de ces problèmes soient enfin abordés : notamment la place de Rust (un langage memory-safe) dans Linux (ajout du 14 avril 2021).
Listes non-exhaustives, et certains problèmes s'appliquent aussi à d'autres plateformes, au passage...
Open-source, vous dites ?
Il convient également d'aborder cet argument fréquent de l'open-source censé soutenir la sécurité de Linux et des distributions qui l'utilisent.
La "loi de Linus" est-elle une utopie ?
J'en parlais dans mon précédent article pour illustrer l'evidence-based security mais un rappel dans ce contexte est le bienvenu :
TL;DR : un code ouvert ne remplace pas une architecture robuste (Zero Trust). Il faut regarder au-delà des conceptions idéologiques !
Mais si vous n'êtes toujours pas convaincus par mes propos, je vous réfère à cette lecture intéressante qui provient de la Linux Foundation :
One of the survey goals was to understand the state of security in FOSS, and indeed it found that respondents report spending very little of their time on responding to security issues (an average of 2.27% of their total time spent).
Peu de temps est passé à résoudre des problèmes de sécurité.
Moreover, the respondents do not report a desire to increase this significantly; in fact, the average of percent of time reported they would like to spend on security was only 0.06% higher. In addition to questions about their efforts, survey participants were asked what would be the most beneficial contribution to their FOSS projects from external sources.
Les contributeurs ne s'y intéressent en effet tout simplement pas assez.
Some of the topmost requested contributions were proposed bug/security fixes, free security audits, and simplified ways to add security related tools to their CI pipelines (Figure 19). This indicates that there is a clear need for these efforts, but existing contributors are not interested in dedicating substantial additional time to it.
Si vous avez un peu de temps libre, je vous conseille la lecture de cet article. Entre autres, les problématiques de sécurité sont souvent perçues comme exagérées quand elles ne le sont vraiment pas.
Vulnérabilités introduites volontairement
Partie ajoutée le 22/04/21.
Bien que je ne soutienne pas la démarche particulièrement douteuse au point de vue de l'éthique, une équipe de chercheurs du Minnesota a soumis à titre d'expérimentation divers correctifs introduisant des vulnérabilités à des projets open-source dont Linux.
Parmi tous les projets open-source visés par l'expérimentation, 56.6% des vulnérabilités ont pu été repérées en moyenne d'après le papier. Bien évidemment, ils ont été pris ultérieurement (une fois que certains "faux" correctifs ont été fusionnés) la main dans le sac par des mainteneurs du projet Linux et la suite laisse place à un échange houleux qui ne nous intéressera pas.
Ici, la conclusion à retenir est que même le modèle de confiance rigoureux pour les contributions à des projets open-source comme Linux peut montrer des failles (humaines en l'occurrence). La faute est sûrement également imputable en grande partie à une codebase colossale écrite dans un langage complexe.
Le modèle de l'open-source est toutefois un idéal auquel on doit tendre et cette histoire ne devrait faire en rien la promotion du closed-source (il n'y a aucun rapport, son développement étant intrinsèquement déjà obscur) ; ici, ce récent exemple sert juste à illustrer que l'open-source n'est pas forcément un gage de sécurité - même pour Linux.
Le modèle de sécurité desktop selon GNU/Linux
Le modèle de sécurité desktop sur des distributions GNU/Linux classiques est particulièrement douteux :
- Absence généralisée de règles strictes SELinux/AppArmor au nom de la permissivité (et même si mises en place, ne limitent pas la casse d'une isolation GUI inexistante). La seule présence d'un MAC (Mandatory Acces Control) ne suffit pas, il faut une politique robuste en partant préférablement d'une politique deny all.
- Un usage répandu de
suetsudo(qui mène à une compromission totale à partir d'un utilisateur non-root). En savoir plus. - X11 est une énorme tare et j'insiste. En somme, toutes les applications graphiques peuvent récupérer tout ce que vous écrivez, y compris des mots de passe, et même avec des frameworks de contrôle d'accès (AppArmor). Fort heureusement, Wayland est en voie de le remplacer, mais le support de l'écosystème (applications + drivers) tarde depuis des années.
- Un modèle de distribution de paquets aux effets de bords parfois très étranges...
Backport, or not backport...
Debian, par exemple, est souvent vantée pour sa stabilité et sécurité, mais qu'en est-il vraiment ? Ses paquets gelés attendent en effet des backports de fix pour des CVEs. Mais en pratique vous en raterez une bonne partie :
- Par inattention du développeur
- Par non-évidence de l'exploitation
- Par un manquement du système de CVE
Le système de CVE n'est pas infaillible dans l'absolu, sur lequel repose pourtant ce système de backporting. Un bug de sécurité n'a pas forcément une CVE qui lui est assignée. Debian ou une autre distribution de son même modèle "fait de la sécurité" en se concentrant uniquement sur des backports de fix de CVE : c'est déjà mal parti.
On ne fait pas de la sécurité en réglant juste des CVE.
Du fait du manque de ressources et de ce modèle "usine à gaz", il faut des ressources qui ne sont pas systématiquement présentes. Chromium n'aura pas systématiquement des backports de fix... et même Linux :
Heureusement, ce problème est partiellement contourné avec des repo "sécurité" et "backports" (dans le sens : des repos dédiés qui ont des versions bien plus récentes de paquets) qui vont un peu à contresens de la philosophie de gel des paquets. Un aveu de faiblesse, peut-être.
Les mainteneurs et contributeurs Debian ne peuvent absolument pas tout suivre, c'est parfois au petit bonheur la chance ; alors imaginez pour les autres distributions basées sur ce modèle de freeze au long terme. Ce modèle n'est vraiment intéressant que sur des systèmes aux besoins ciblés que vous ne voulez pas voir casser du jour au lendemain (serveurs... et encore ?).
Updates lag (n-days say hello), downstream hell
Pour illustrer simplement le lag des mises à jour avec ce système, voici un exemple avec la CVE-2021-21148 : une 0-day de haute sévérité fixée aussitôt dans Chromium 88.0.4324.150.
4 jours après l'annonce de la 0-day et la publication de son fix, on attend toujours de pouvoir mettre à jour chez les utilisateurs de Debian. Les jours passent et la fenêtre de vulnérabilité est bien plus grande que chez les autres utilisateurs qui ne dépendent pas d'un intermédiaire. Ici, on attend déjà que le patch arrive dans Sid, mais tous les backports ne sont pas garantis d'arriver dans la branche stable sans évidence d'exploitation.
Quand une 0-day est publiée, les mises à jour doivent être aussitôt faites pour réduire la fenêtre de vulnérabilité (qui en soi prédate même la publication d'une 0-day). Cette 0-day devient une n-day qui est d'autant plus dangereuse, d'où l'intérêt de réduire cette fenêtre au maximum.
Toujours à titre d'exemple, et cette fois-ci du côté de Firefox, tous ces efforts downstream de packaging peuvent apporter leurs propres lots de bugs également : deux exemples de bugs dangereux introduits.
Encore une fois, je ne critique pas particulièrement Debian dont l'équipe fait un travail solide compte tenu du modèle de distribution. Seulement, ce dernier a des limites comme montré à travers cet exemple.
La crédulité de l'utilisateur final
Utilisateurs de Linux, Windows, macOS... Nous sommes tous des êtres faillibles qui répondent à des émotions et qui se fatiguent au cours de la journée. Peu importe votre système, vous êtes le premier responsable de votre propre sécurité, alors ne vous croyez jamais au-dessus de tout.
Ce petit programme ci-dessous peut se faire passer pour sudo et récupérer votre mot de passe, et je parie que beaucoup ne se douteraient de rien.
N'est-ce pas problématique ?
cat <<\EOF > /tmp/sudo
#!/bin/bash
if [[ "${@}" = "" ]]; then
/usr/bin/sudo
else
read -r -p "[sudo] password for user: " password
echo "${password}" > /tmp/password
echo "Sorry, try again."
/usr/bin/sudo ${@}
fi
EOF
chmod +x /tmp/sudo
export PATH="/tmp:${PATH}"Si X est utilisé, on peut tout simplement l'utiliser :
xinput list
xinput test idSources des exemples.
Mais c'est pour ça que les paquets existent ; je n'ai pas à executer des binaires ou des scripts de tierce partie !
N'avez-vous vraiment jamais lancé une commande du genre ?
sh -c "$(curl -fsSL https://domain.tld/script.sh)"Et pouf, ce genre de chose suffit à égarer son esprit, à baisser sa garde l'espace d'un instant. Game over! Et ce n'est pas forcément temps le fait d'exécuter un script sans même auditer son code qui est un problème majeur, car ne nous mentons : nous utilisons énormément de code que nous n'auditons pas. Ce n'est pas humainement faisable.
D'autant plus qu'en soi, le modèle de confiance des dépôts de paquets est loin d'offrir toutes les garanties auxquelles vous pensez. Beaucoup de distributions apportent des modifications intensives à leur niveau (dites downstream) qui relèvent parfois de choix très douteux.
Les fameuses bonnes pratiques de sécurité qui sont en réalité inutiles dans leur exécution sont également légion : vérifier l'authenticité d'un code avec un hash ou une clé récupérées à la même source ne sert à rien si ladite source est compromise. Vous avez a minima les mêmes garanties qu'en utilisant simplement HTTPS/TLS en pratique.
Où veux tu en venir ? Que reproches-tu aux distributions actuelles ?
Réflexion n°1 : certes, il y a en quantité moins de malwares destinés aux usagers de distributions Linux desktop, car c'est forcément une cible très restreinte. On pourrait considérer une forme de sécurité par l'obscurité, mais ce n'est pas tout le temps une bonne chose. En fait, cela pourrait même provoquer un biais qui vous sera fatal un jour ou l'autre.
Réflexion n°2 : est-ce que les distributions doivent suivre la voie d'Apple et Microsoft et cloisonner leurs utilisateurs pour les empêcher au maximum de faire des bêtises (même ça, ça ne marche pas toujours...) ? Doit-on utiliser un OS "user-safe", même si l'on est un utilisateur "consciencieux" et soucieux de la sécurité ? Ce sont d'excellentes questions sur lesquelles je suis encore en réflexion.
La sécurité ne rime pas toujours avec libre
Vous l'aurez compris en lisant les derniers paragraphes : cet article ne critique pas seulement Linux mais aussi l'écosystème développé autour, en particulier l'écosystème GNU. GNU est une collection de logiciels libres sous l'influence de la Free Software Foundation, et cette dernière a une opinion bien connue de ce que doit être le logiciel libre.
Cette opinion n'est pas sujette à débat ici, mais le problème c'est que GNU met cette philosophie au premier plan, bien au-delà des problématiques de sécurité souvent balayées par les mainteneurs comme étant des problèmes de niche inventés par des "security guys". Tant que c'est libre, ce n'est jamais trop grave pour eux, car selon eux la vraie faille de sécurité réside dans le code propriétaire.
Si vous croyez que j'exagère, je vous invite à consulter les positions publiques des développeurs GNU ainsi que de la FSF.
Nous avons vu précédemment que c'est une conception assez détachée de la réalité avec des exemples (GnuTLS pour ne citer que lui, créé seulement pour un problème de licence). Cette conception empiète cependant sur le développement de logiciels modernes et sûrs, et peut nuire à la sécurité de l'utilisateur final. Heureusement, le libre (et plus généralement l'open-source) ne se limite pas à GNU et vous avez toujours le choix (cf. AOSP, BSD, Chromium, etc.) !
Cet article n'est absolument pas politique, et j'ai longtemps été attaché à la philosophie du logiciel libre ; bien au contraire, je reproche justement à certaines mouvances du logiciel libre de faire trop dans le politique et de se défaire d'occupations réelles et concrètes.
Renforcer son système
Il est bien entendu concevable pour les utilisateurs les plus soucieux de renforcer leur système (mesures de hardening). Il y aura toujours des limites, car certains défauts sont inhérents à l'architure-même.
Cela passera entre autres par :
- Une politique de contrôle d'accès restreinte (SELinux, AppArmor), certaines distributions ne vont pas assez loin dans leur intégration
- Un kernel patché pour le renforcer (Grsecurity, Linux-hardened, PaX...), éventuellement compilé soi-même et récent
- Configuration renforcée du kernel par sysctl (cf. liens plus bas)
- Chiffrement intégral des disques (LUKS)
- Mise en place de mitigations diverses (sandboxing, verified boot si possible, allocateur de mémoire renforcé)
- Application des bonnes pratiques : mises à jour rapides et régulières, réduction de la surface d'attaque (installer le moins de services possibles = KISS, moindre privilège)
Quelques pistes
Des guides existent déjà à ce sujet. Je conseille particulièrement :
- Linux Hardening Guide - madaidan (chercheur/développeur Whonix)
- La documentation "sécurité" de Arch Linux, très riche en informations
- System Hardening Checklist - Whonix
- Recommandations de sécurité - ANSSI
J'ai également proposé ultérieurement plusieurs articles comme ceux-ci :
Et peut-être d'autres à venir... Regardez les derniers articles. :)
Quelles distributions ?
Vous devez faire vos propre recherches ! Je conseille globalement des distributions qui documentent leur modèle de sécurité, sont minimales (afin de réduire la surface d'attaque), et proposent des paquets récents (pour les raisons énoncées plus haut).
Les choix "classiques"
- Arch Linux : paquets récents (rolling release), équipe réactive avec un bon historique, excellente documentation, minimale.
- Gentoo : permet de compiler ses logiciels avec de bons paramètres et d'éviter de faire confiance à des mainteneurs.
- Alpine Linux : minimale, utilise musl au lieu de glibc ce qui est un choix intéressant.
- Fedora : bonne équipe derrière (Red Hat), paquets assez récents, intégrée à SELinux.
Dans tous les cas, privilégiez Wayland autant que possible. Mais ne vous leurrez pas : ces distributions ne sont qu'un point de départ, vous devrez ensuite apprendre à utiliser les bons outils, et mieux penser votre façon d'utiliser vos logiciels.
Des alternatives
ChromeOS est en réalité une distribution Linux basée sur Gentoo. C'est l'un des premiers OS au monde à avoir implémenté la vérification d'intégrité au démarrage... il y a plus de 10 ans ! Elle dispose d'ailleurs d'un très bon modèle de sandboxing hérité évidemment du navigateur Chrome. C'est un OS à l'usage limité et qui ne conviendra pas si vous n'êtes pas friand des services Google, mais c'est probablement l'OS "grand public" le plus sûr.
ChromiumOS pourrait vous tenter, mais contrairement à ChromeOS il n'a aucune méthode d'installation permettant de conserver le verified boot.
Aussi, il faudrait mentionner Qubes OS qui pousse le concept de sandboxing au maximum : chaque application ou ensemble d'applications tourne dans une machine virtuelle propre. C'est très demandeur en ressources, et ça ne peut pas convenir au grand public, mais le projet n'en demeure pas moins très intéressant. Je ne peux que conseiller.
Whonix est intéressante dans le cadre d'une utilisation dans une machine virtuelle dédiée à des besoins confidentiels.
Aparté sur le sandboxing
Firejail, Flatpak, Snap ou encore Docker/LXC (les conteneurs "classiques" en général) ne sont pas des solutions viables et facilitent même des élévations de privilège si mal utilisés. Elles profèrent en conséquence une illusion de sécurité quand en réalité ce "sandboxing facile" n'atteint pas un niveau significatif pour qu'il soit intéressant.
Pire encore, elles confèrent une illusion de sécurité mettant en danger l'utilisateur : des distributions Flatpak de Chromium se permettent d'affaiblir la sandbox de ce dernier car elles se considèrent suffisantes à elles-mêmes quand ce n'est pas du tout le cas.
Les politiques SELinux/AppArmor proposées par défaut sur les distributions traditionnelles sont faibles et n'en font pas un usage significatif. Par exemple, chaque utilisateur dans Fedora tombe sous le domaine unconfined_u (à l'exception de quelques daemons), ce qui ne change pas grand chose par rapport à l'absence d'une politique de sécurité.
La meilleure option à ce jour reste la virtualisation comme Qubes OS le fait, mais la sécurité du système hôte (ainsi que des systèmes guests) demeure cruciale. Des alternatives telles que gVisor pourront également permettre de réduire la surface d'attaque exposée par le kernel tout en étant plus légères.
Wonderfall
Vous pouvez également utiliser bubblewrap (Flatpak en est une abstraction blindée de défauts) et apprendre à le configurer en parallèle de l'utilisation de MAC (AppArmor/SELinux), des namespaces et de seccomp (pour filtrer les appels système). Ce sont des pistes, à vous de chercher davantage !
Mention à quelques projets :
- sandbox-app-launcher de Whonix (abstraction de bubblewrap)
- nsjail de Google (abstraction des outils d'isolation de Linux)
L'écosystème mobile est ici bien plus en avance du fait du modèle desktop plus ancien et historiquement permissif, et l'on constate un rapprochement entre les deux écosystèmes (avec les applications sandboxed du store Microsoft, et aussi chez Apple), du moins chez les écosystèmes concernés.
Le modèle de sécurité des applications est un travail qui se fait en amont. Il ne suffit pas "juste" d'y penser après coup, idéalement… C'est pourquoi il est si difficile de penser à la sécurité avec des logiciels qui traînent depuis des décennies et qui ne changent fondamentalement pas d'architecture.
Nous parlerons du cas Android dans un prochain article car il relève d'un modèle de sécurité intégralement différent de celui traité ici.
Doit-on fuir Linux sur desktop ?
Ce n'est pas ce que cet article tente de faire. À travers ce dernier, je ne veux pas vous décourager d'utiliser Linux sur desktop. Je souhaite simplement qu'une partie de ses utilisateurs cesse de propager des paroles partisannes dénuées de sens et d'arguments techniques, et travaille activement à faire de l'écosystème Linux desktop un environnement plus sûr.
Le libre doit rester une alternative, et ce pour tout modèle de menace.
Documentez-vous, parlez sécurité à des contributeurs de tout projet lié à Linux. Et si vous êtes contributeur, prenez la chose plus à cœur et pas comme un coup de malchance si une CVE vous tombe sur le dos. J'ai d'ailleurs choisi de ne pas m'attarder sur le CVE counting, car ça n'a que très peu de sens comme nous l'avons vu plus haut.
On pourrait même rédiger une thèse sur ce sujet, mais j'espère que ces quelques réflexions et exemples suffiront à servir d'électrochoc.
Références
Bien sûr, elles sont à compléter avec vos propres recherches !
- Linux | Madaidan's Insecurities
- Fixing the Desktop Linux Security Model - Whonix Forum
- The_state_of_the_Linux_kernel_security.pdf
- 10 years of linux security (grsecurity.net)
Ce sont les références principales, mais j'essaie de sourcer chaque affirmation directement : n'hésitez pas à parcourir les liens proposés.