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...

Linux et la sécurité, tel un désert et un oasis ?

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 s'intéresse au Rust et explique pourquoi
  • 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 :

Evidence-based security
En écho à la “broscience” (usuellement de la désinformation scientifique par des personnes non-compétentes), je souhaite m’adresser dans cette série d’articles à des mythes persistants de la sécurité informatique, qui n’ont jamais été corrects, ou bien obsolètes.

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é introduites 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)
  • Un usage dangereux de su et sudo (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
Dmitry Vyukov

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 :

Information on source package linux (debian.org)

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 ce "freeze".

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. Au passage, il n'y a rien de partial dans le choix de ce navigateur comme exemple...

Capture d'écran du security tracker Debian au 09/02/21

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 soit 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.

Au 12/02/21, soit J+7 : le patch n'est toujours pas dans la branche stable...

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 intouchables.

Ce petit programme ci-dessous peut se faire passer pour sudo et récupérer votre mot de passe, et 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}"

Encore plus drôle, en profitant du serveur X...

xinput list
xinput test id

Sources 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!

D'autant plus qu'en soit, 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.

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.

GNU est-il anti-sécurité ?

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). Elle empiète cependant sur le développement de logiciels modernes et sûrs, et nuit à 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 (presque) toujours le choix (cf. AOSP par exemple) !

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’s Insecurities

Aussi, vous pouvez vous inspirer de ces documentations :

Security - ArchWiki
Security Hardening Checklist
Security hardening instructions for Whonix ™ and Qubes-Whonix ™. Improving Linux, Windows and macOS host computer security and networking configurations. Safe Tor, Tor Browser and other online activities.

Dans un registre plus formel, l'ANSSI offre ses recommandations :

Publication : Recommandations de sécurité relatives à un système GNU/Linux
Les systèmes GNU/Linux offrent un grand nombre de combinaisons possibles. Des règles de configuration incontournables, recommandées par l’ANSSI, permettent d’obtenir un système raisonnablement sûr, tout en conservant les fonctionnalités requises, par le respect et l’application de certains principes…

J'ai également proposé ultérieurement plusieurs articles comme ceux-ci :

Quelques bricoles pour renforcer Linux : ASLR, lockdown, PTI (Spectre/Meltdown)...
Linux a lui aussi droit à son confinement ! Nous allons voir quelques paramètres non-exhaustifs pour renforcer sa sécurité.
Touche pas à mon root
Sur les systèmes UNIX et ses dérivés, le compte root est le super-administrateur du système. Il dispose des pleins pouvoirs sur l’ensemble du système. Cet article se concentre sur des façons employées pour sécuriser son accès.

Et peut-être d'autres à venir...

Quelles distributions ?

Vous devez faire vos propre recherches ! Je conseille globalement des distributions qui documentent leur modèle de sécurité, sont minimales (musl au lieu de glibc par exemple), et proposent des paquets récents (pour les raisons énoncées plus haut).

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 desktop "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.

Qubes security domains - Qubes OS - Wikipedia

Mention honorable à Alpine Linux qui est une des rares distributions à utiliser musl en lieu et en place de la glibc. Selon moi, musl doit être préféré puisqu'il est bien moins bloated, donc facile à maintenir avec une surface d'attaque moins grande. C'est la distribution de choix pour les conteneurs, mais je ne sais pas ce qu'elle donne pour une utilisation desktop. On peut mentionner Void Linux qui permet d'utiliser musl également.

Enfin, Gentoo comme certains le savent déjà est une distribution où il faut à peu près tout compiler soi-même. Tout comme Arch Linux en quelque sorte, on peut construire son système en implémentant directement des bonnes pratiques et bénéficier d'une surface d'attaque par défaut relativement faible.

Dans tous les cas, et si votre utilisation le permet, utilisez Wayland pour remplacer Xorg.

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, ou encore Docker/LXC (les conteneurs en général) ne sont pas des solutions viables et facilitent même des élévations de privilège si mal utilisés. Cf. cet article ainsi que les solutions proposées :

gVisor & Kata : des sandbox pour renforcer l’isolation des conteneurs
Les conteneurs apportent sur le papier un environnement réplicable et léger avec un espace utilisateur isolé, loin de la lourdeur des machines virtuelles. En réalité, l’isolation est une problématique qui doit être considérée de plus près : nous verrons ici des solutions proposées...

La meilleure option à ce jour reste la virtualisation comme Qubes OS le fait, mais la sécurité du système hôte 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.

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 :

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...

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 !

Ce sont les références principales, mais j'essaie de sourcer chaque affirmation directement : n'hésitez pas à parcourir les liens proposés.