Réflexion sur les OS

Une petite prise de recul sans prétention sur les différences entre les OS traditionnels et les OS modernes. Ce que j'en fais en pratique.

Réflexion sur les OS

Ne vous attendez pas à un article avec de nouvelles informations, mais c'est plutôt une réflexion, voire une synthèse autour d'éléments déjà vus.

Au fil de mes derniers articles, je faisais souvent la mention implicite que les systèmes d'exploitation de bureau sont moins sûrs que leurs homologues mobile. Fondamentalement, qu'est-ce qui différencie un OS dit desktop d'un OS dit mobile ? Tout d'abord, je vous invite à consulter cet article :

Le modèle de sécurité mobile : Android, iOS, “Linux phones”
Petite incursion dans le monde de la sécurité mobile. Qu’en est-il de son modèle de sécurité ? Quels sont les moyens mis en oeuvre par ses acteurs principaux ?

Vous devriez comprendre à ce stade que ce sont deux paradigmes opposés : l'un plus ancien et permissif, et l'autre plus moderne et perçu comme plus restrictif. Par modernité j'entends particulièrement, dans ce contexte, la sécurité aussi bien que la vie privée.

Un peu d'histoire

L'histoire des systèmes d'exploitation modernes commence vraiment à partir des années 60 avec l'émergence des systèmes Unix : les premiers OS portables (destinés à fonctionner sur plusieurs plateformes) écrits dans des langages encore massivement utilisés aujourd'hui tels que le C.

Nous pourrions également mentionner au passage l'importance des normes POSIX apparues dans les années 80, visant à définir l'interopérabilité entre différents systèmes d'exploitation.

Aujourd'hui, l'héritage Unix est encore très présent, par exemple :

  • Les systèmes BSD en sont directement les héritiers.
  • Les systèmes Linux en sont fortement inspirés (Unix-like).
  • Les systèmes Apple reposent sur Darwin (XNU, Unix-like).
Ne vous faites pas avoir par les acronymes "* is not Unix". Ce sont souvent des systèmes très proches d'Unix en réalité, mais pas strictement identiques.
History of Unix - Wikipedia

Plus éloigné mais partageant tout de même une tranche d'histoire commune, on peut mentionner Microsoft également. MS-DOS fut toutefois bien différent des systèmes Unix, n'adoptant pas la même approche d'un système modulable, multi-utilisateurs et multitâches comme Unix.

Bien avant donc Windows NT qui dominera le marché des ordinateurs personnels, on peut dire qu'Unix définissait les standards des systèmes actuels, bureau ou mobile.

Les OS de bureau : la sécurité au second plan ?

Je ne sais pas si l'on peut vraiment dire qu'il y a eu un moment-clé définissant la naissance OS "classiques" de bureau. En fait, c'est bien là tout le problème, il n'y a pas eu de réflexion au-delà du "tant que ça marche, c'est une évolution". Ils sont très permissifs, car il ne fallait pas - dans un premier temps - mettre des bâtons dans les roues pour les développeurs.

Fondamentalement, il n'y a donc aucun réel modèle de sécurité pensé au départ, en dehors de la séparation entre les utilisateurs. La sécurité est ensuite pensée après coup, telle une affaire ultérieure que l'on tente de rendre compatible avec un modèle trop permissif au départ.

Mais évidemment, ça ne peut pas fonctionner ainsi. La sécurité doit être pensée dès le départ dans le cycle de développement d'une architecture logicielle ou autre.

Ces systèmes ont choisi dans un premier temps la facilité de développement et les performances, ce qui est bien entendu compréhensible. Peut-être aussi un manque de recul ? C'est sûr, c'est plus simple de juger après des décennies... Par exemple, le choix des noyaux monolithiques tels que Linux et BSD, car un noyau monolithique est considéré comme plus performant.

Wikipédia

Nous y reviendrons en détails un autre jour ! Promis.

Plus généralement, il n'a pas été pensé dès le départ que chaque programme soit réellement isolé des autres. C'est le modèle de données traditionnel où l'ensemble des programmes partage les mêmes ressources, sans limitations. Bien entendu, des mitigations ont été pensées, mais elles sont ce qu'elles sont et ne remplacent pas vraiment un modèle avec la sécurité pensée dès le début. Pour résumer avec une touche humoristique :

xkcd: Authorization

Aujourd'hui, que vous utilisiez une distribution Linux desktop ou Windows 10, vous êtes exposés à de gros risques dès lors que vous exécutez un programme tiers. Pire encore, le serveur d'affichage X sur Linux, encore massivement utilisé, est complètement obsolète et permet à chaque application de pouvoir espionner ce que vous faites sur une autre, y compris des mots des passe.

# Récuperez l'ID de votre clavier
xinput list

# A partir de là, vous pouvez tout récupérer
xinput test id

Ce n'est pas vraiment une faille de X, c'est simplement by design. Les développeurs de X eux-mêmes reconnaissent que X doit être enterré car il n'a jamais été pensé avec l'isolation lors de sa conception.

Windows, lui, n'est pas si mieux loti avec ses applications Win32 qui permettent sensiblement la même chose depuis plus de 20 ans. Ces applications peuvent by design enregistrer toutes les frappes au clavier ainsi qu'enregistrer l'écran-même ou prendre contrôle de la souris et du clavier...

Démonstration d'espionnage Win32 (pas de moi, flemme de lancer une VM)

Outre Linux avec Wayland, macOS est plutôt bon élève : il n'autorise pas ce genre de chose sauf si explicitement autorisé par un administrateur via une API (Accessibilité, etc.).

L'isolation des applications entre elles est ce qu'on appelle le sandboxing. Dans l'idée, chaque application dispose donc de son propre bac à sable, de ses propres ressources, et n'a pas à toucher (du moins par défaut) aux ressources d'une autre application sauf exception explicite. C'est important : non seulement pour la sécurité, mais aussi la vie privée.

Aujourd'hui, l'état est le suivant :

  • Sur Windows 10, les applications UWP sont contenues dans une sandbox. Quant aux applications Win32, il est suggéré de les lancer dans une VM ou Windows Sandbox (qui le fait vraiment ?).
  • Sur macOS, les applications doivent demander des accès explicites à certaines permissions sensibles. Les applications de l'App Store disposent d'une sandbox davantage renforcée.
  • Sur les distributions classiques Linux, Flatpak est vanté comme une solution comparable mais elle est très imparfaite. Du coup à ce stade, il convient d'utiliser des VM autant que possible.
  • Sur ChromeOS, toutes les applications sont sandboxées. Mais je considère ChromeOS comme un OS atypique qui ne relève pas vraiment du modèle traditionnel de bureau.

Ce n'est que la partie émergée de l'iceberg.

Les OS mobiles : mieux pensés dès le début

Les OS mobiles n'étaient pas forcément parfaits dès le départ. En fait, je vais me concentrer principalement sur iOS et Android qui partagent une évolution et histoire commune, bien plus qu'on ne le pense. Cette histoire commence à partir de la fin des années 2000 jusqu'à de nos jours.

En fait, je n'aime pas tant parler d'OS mobile, mais c'est ce qu'on comprend le mieux. Je préfère parler d'OS moderne ("mobile") en opposition aux OS traditionnels ("bureau").

Du fait des contraintes importantes imposées par un appareil mobile (écosystème applicatif, sécurité physique, nid à capteurs sur nous en permanence, l'enjeu de l'interconnection...), les OS mobiles doivent par nature montrer la voie d'un OS qui applique des mesures rigoureuses de sécurité : sandboxing, chiffrement, vérification d'intégrité au démarrage...

Il y a un réel modèle de sécurité pour les applications :

  • Chaque application sur Android moderne ou iOS moderne dispose par exemple de son propre espace de stockage. Il est au possible au cas par cas d'y faire des exceptions granulaires, permettant la productivité (contrairement à une permission obsolète qui autorisait l'accès total).
  • L'utilisation en arrière-plan devient de plus en plus restreinte (de données, de capteurs), ce qui a toujours été plus ou moins le cas sur iOS, mais ça le devient également sur Android.
  • Le modèle de permissions s'affine de plus en plus : on peut donner accès à un certain fichier/dossier seulement, à une localisation imprécise, des accès aux capteurs qui ne seront valides qu'une seule fois, et/ou seulement quand l'application est en premier plan.
  • Les applications sont signées, obtenues depuis une source de confiance (en théorie), et ne peuvent pas retourner à une version antérieure. Les mises à jour peuvent être distribuées automatiquement.
  • Les applications sont d'ailleurs bien plus souvent écrites dans des langages modernes et plus sûrs tels que Java, Kotlin ou Swift.
Buffer overflow & consort : tout ce que vous devez savoir
De nombreuses vulnérabilités dans les systèmes informatiques sont liées à des erreurs de gestion de la mémoire, permises entre autres par l’utilisation de langages de bas-niveau répandus tels que le C et le C++. En 2019, elles constituaient pour Microsoft environ 70% des vulnérabilités traitées.

Des mitigations importantes sont également mises en place :

  • La vérification d'intégrité au démarrage, qui permet de ne jamais démarrer un OS à l'état compromis en vérifiant son état d'intégrité. Une protection à la fois utile contre des attaquants physiques mais aussi distants, qui pourraient implémenter des malwares persistants (rootkits, bootkits).
  • Le chiffrement, qui se fait aujourd'hui au niveau du fichier plutôt qu'au niveau du disque. Le chiffrement au niveau des fichiers (FBE = file-based encryption) est bien plus moderne et efficace qu'au niveau du disque (FDE = full disk encryption) : ce dernier est particulièrement complexe et vulnérable, moins granulaire.
  • La sécurité passant aussi par le hardware : des IOMMU configurés de façon stricte, des enclaves sécurisées, résistantes et isolées de l'OS et du SoC pour traiter des opérations critiques. Et évidemment, l'absence de x86 (au profit d'ARM) : une architecture vieille, complexe, victime de sur-ingénierie.

La sécurité actuelle des appareils mobiles est supérieure en tous points à la sécurité actuelle des appareils de bureau. La sécurité est intégralement pensée dans un modèle de sécurité propre au logiciel ainsi qu'au matériel.

Quand le bureau s'inspire du mobile

Bien évidemment, il serait trop binaire de simplement opposer deux paradigmes sans reconnaître l'évolution des OS de bureau qui s'inspirent du mobile. Nous l'avons vu récemment avec Windows 10 et ses applications UWP et Secured-Core :

Windows 10 : son modèle et ses fonctionnalités de sécurité
Windows a longtemps été moqué pour sa sécurité supposément dérisoire ; il va sans dire que cela a sans doute été le cas pour ses précédentes moutures. Puis Windows 10 est arrivé, avec son lot de bonnes choses : Microsoft prend-il enfin la sécurité au sérieux ? Faisons le tour...

L'héritage Win32 semble encore persister, mais il est en même temps difficile de passer l'éponge quand le public lui-même ne comprend pas l’intérêt d'UWP. Et Windows 11 qui accueillera des applications Win32 dans son Store, mais j'attends de voir ce qu'il en est avant d'interpréter cette annonce.

C'est sensiblement la même chose pour macOS qui est potentiellement plus avancé dans son modèle de sandboxing, et propose de grandes avancées matérielles avec l'avènement d'Apple Silicon qui personnellement me remplit d'espoir dans l'idée de me débarrasser complètement d'x86. Ce n'est peut-être pas Apple qui y a pensé en premier, mais c'est Apple qui l'a si bien réussi, en espérant que d'autres suivent.

Qu'en est-il de Linux ? Wayland tout d'abord est en passe de nous débarrasser de ce dinosaure de X11. On entend parler de Wayland depuis des années mais son adoption peine à suivre parmi les développeurs de logiciels et constructeurs qui doivent proposer des pilotes (NVIDIA, réveillez-vous ?).

Mais c'est un problème parmi bien d'autres que nous avons abordés (que dis-je, effleurés) dans cet article :

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

Vous pouvez foutre du SELinux, du bubblewrap, du seccomp-bpf... C'est déjà bien difficile de le faire correctement, mais ça ne remplacera jamais un modèle de sécurité applicatif pensé de bout en bout dans le cycle de développement. La meilleure solution, aussi radicale soit-elle, est visiblement de contenir les applications dans des machines virtuelles. C'est un peu ce que fait QubesOS, finalement, même s'il manque lui-même certaines mitigations.

De manière générale, les OS traditionnels s'entêtent à conserver la rétrocompatibilité avec des logiciels et du matériel d'un autre âge. Vous ne pouvez pas disposer à la fois d'une telle rétrocompatibilité et d'un modèle de sécurité robuste. Vous pouvez avoir l'un, mais pas les deux !

La clé, c'est la la compartimentalisation

La sécurité telle qu'imposée par les OS mobiles "modernes" a un prix : les restrictions perçues peuvent nuire à l'idée de la productivité que les OS classiques nous ont inculqué toutes ces années.

Avec une grande liberté, il y a de grandes responsabilités.

Je ne le nie pas moi-même : je ne conçois pas utiliser des OS mobiles pour absolument tout. Mais est-ce que tout le monde a besoin d'une si grande permissivité pour 95% de leurs tâches (qui aujourd'hui consiste surtout à passer son temps dans un navigateur) ? Et est-ce que j'en ai besoin moi-même pour mes tâches du quotidien ?

Mon raisonnement est donc d'éviter l'utilisation d'OS de bureau pour des besoins personnels : lectures de mail sensibles, consultation de ma banque, navigation classique, veille technologique, discussions sur Signal ou autre plateforme E2EE. Tout ce que je peux faire dans un bon modèle de sécurité, je le fais.

Si c'est pour utiliser des applications Electron qui sont basiquement des Chromium affaiblis (CFI/CSP cassés), non merci de toute façon.

Si je veux jouer à des jeux seulement disponibles sur Windows, ainsi soit-il. C'est mieux car, de toute façon, de nombreux mécanismes de protection anti-DRM et anti-triche nécessitent littéralement un accès privilégié au système pour vous permettre de simplement jouer. Ces accès peuvent constituer un risque de sécurité et de vie privée que je ne veux pas faire courir à mes autres activités : ici, pas de problèmes, puisque je choisis de limiter ce système à l'activité de jouer.

Ou une console pour jouer, ça fait l'affaire aussi.

Et si j'ai envie de développer et de contribuer à des projets ? Je dois donc avoir à ma disposition un environnement Linux (Arch Linux étant ma préférence), qui sera limité seulement au développement. Je peux même utiliser X11, peu m'importe : je ne l'utiliserai pas pour autre chose que du développement en fait.

Il est de toute façon déconseillé de développer sur le même système qui héberge des données très sensibles pour des raisons franchement évidentes. C'est en ce sens que Visual Studio Code a récemment reçu une mise à jour vous avertissant des risques de travailler sur un projet tiers (sans doute suite à cette histoire d'exfiltration avec des macros Rust).

Je conçois qu'il n'est pas simple pratiquement et économiquement de devoir jongler entre plusieurs appareils, mais c'est ce que je perçois comme idéal.

Tout le reste, je le fais sur mon smartphone sous GrapheneOS ou bien mon iPad. L'iPad est clairement plus confortable en tant que remplaçant direct à un laptop classique, l'écosystème Android ne se prêtant malheureusement pas assez bien au format (même si je le souhaiterais). Android et iOS permettent une compartimentalisation intrinsèque du fait de leur modèle de sandboxing robuste.

Quelques conseils, vos options

Je vous invite à faire de même quand vous en avez la possibilité : jonglez habilement entre les systèmes selon vos besoins et ne cherchez pas à absolument intégrer une paroisse. Le logiciel libre, aussi louable soit-il, n'est pas un remplaçant d'une architecture robuste. Je suis adepte d'une philosophie davantage pragmatique, même si je sais que je n'arriverai jamais forcément à convaincre la masse, ce qui n'est pas mon but de toute façon.

Chacun ses besoins, chacun son modèle de menace, chacun ses préférences, mais il serait présomptueux de penser que vous pourriez vous passer d'un OS simplement mieux conçu pour ces tâches car "vous êtes une personne avertie des dangers d'exécuter un programme tiers".

Mon conseil, utilisez un OS mobile/moderne autant que possible :

  • En smartphone : un Google Pixel avec GrapheneOS, ou un iPhone
  • En tablette/laptop : un iPad, ou un Chromebook (oui, je sais)

Globalement, ce sont vos meilleures options actuellement. Nous avons vu que les autres constructeurs ont tendance à faire un peu n'importe quoi, voire dans le pire des cas s'apparenter à une escroquerie (Purism notamment, mais c'est loin d'être le seul) mais pourtant vendue comme de bonnes choses pour des raisons qui me dépassent.

Je l'ai déjà abordé en partie dans cet article, mais c'est au plaisir si je dois aller jusqu'à leur dédier une soirée pour arrêter de perdre mon temps à l'expliquer. J'en ai un peu marre des "vendeurs du libre" comme si une idéologie vendue à prix de luxe était la réponse quand elle est elle-même trompeuse et catastrophique.

Je ne conseille pas forcément un Chromebook que je considère assez invasif dans le fait-même de vous authentifier avec un compte Google. Cependant, force est de constater que c'est un OS intéressant techniquement parlant, proposant la vérification d'intégrité au démarrage depuis des années, ainsi qu'un modèle de sandboxing isolant sites et applications entre eux. Puis il est même possible de lancer des applications Android et Linux, donc en termes d'usabilité, on a vu bien pire.

Pour ma part j'ai opté comme vous le savez peut-être pour GrapheneOS, qui est accompagné par mon iPad. Pour vous donner une idée de mon setup :

  • Mon Pixel sous GrapheneOS est l'appareil auquel je fais le plus confiance. Il dispose d'une sécurité et d'une vie privée inégalées, tout en étant très agréable à utiliser grâce à l'écosystème d'applications Android compatibles.
  • Mon iPad, c'est ce qu'on peut appeler comme mon ordinateur personnel, aujourd'hui armé de son Magic Keyboard. Sa productivité est excellente en 2021 : je peux y traiter mes photos RAW, faire du montage photo comme sur un vrai PC, et même un peu de développement (git, vim, Python, Wasm) et d'administration (SSH). Plus limité certes, mais "fun" aussi en même temps.
  • Pour jouer, c'est mon PC fixe et ma Nintendo Switch qui me suffisent amplement. Enfin, qu'aurais-je besoin de plus ?
  • Pour développer plus lourdement, j'ai un accès à des distributions classiques Linux sur mon fixe, et j'ai des laptops classiques pour toutes sortes de choses.
Le futur ? Non, ne vous inquiétez pas, je ne suis pas un "Apple shill" à ce point.

Plot twist : j'écris cet article (majoritairement) depuis mon iPad. Je compte faire un article qui ira bien plus en détails pour résumer cette expérience avec ses aspects positifs et négatifs.

Le mot de la fin

Les références principales que je vous conseille de lire sont les suivantes :

Ces chercheurs en sécurité dressent plus ou moins le même constat. Je pense qu'avec un peu de bon sens et les bonnes informations à disposition, on se rend compte forcément de l'état des lieux.

Considérez ce présent article comme une discussion ouverte où j'y exprime surtout mon point de vue, et je ne compte pas vraiment le partager sur les réseaux. Je serais ravi de connaître vos avis et expériences pour les quelques personnes qui liront et sont intéressées par la démarche.