L'OS de confiance, c'est un système d'exploitation que même le mal incarné ne pourrait r00ter, ou peut-être Jake 2.0, mais on s'en fout, parce que c'est un gentil et qu'il triche. Une espèce de super machine inmourable donc, un véritable IDDAD[1] pour le système tout entier. Mais alors comment ça marche ?! À vrai dire, on ne sait pas encore, ça fait l'objet de recherches intensives. Mais grosso modo, les solutions semblent prendre deux chemins bien distincts.

Les premiers se concentrent sur un blindage maximum, au niveau du noyau, avec des tonnes de trucs comme du méchant contrôle d'accès, des détecteurs d'intrusion embarqués, de la super compartimentation, et tutti quanti. J'ai l'air un peu moqueur comme ça, mais ne vous fiez pas aux apparences. Il y a des choses là-dedans dont on connait l'efficacité (et le contraire aussi). Ceci étant, est-ce que c'est vraiment user proof en terme de configuration ?

L'autre chemin, c'est celui de la virtualisation. Ce que d'aucuns appellent le Ring -1. Oui oui, le Ring -1. Si vous en avez marre de vous secouer la nouille en mode noyau, adoptez un Ring -1. C'est tout pareil, mais en dessous, si vous voyez ce que je veux dire. Non, je rigole. Le Ring -1, c'est finalement un hôte minimum dont le boulot est de faire tourner des sandbox virtualisées dans lesquelles viendront tourner les applications. On connait déjà ça dans Java, et à quelques[2] erreurs d'implémentation près, le modèle marche plutôt bien. Si bien que nos fondeurs préférés ont décidé d'ajouter ça à leurs processeurs. Évidemment, on va prier très fort pour la segmentation tienne mieux la route que l'hyperthreading sous peine de ne pas en tirer grand chose.

Mais alors deux questions se posent[3]. La première de savoir qui va configurer tout ça. En effet, c'est bien beau de fournir des mécanismes de contrôle qui rul3z, de la virtualisation à gogo ou les deux même temps, il va bien falloir les configurer à un moment ou à un autre, ce qui implique un accès privilégié à un mode super-super-utilisateur. De deux choses l'une. Soit l'utilisateur y a accès, et il faudra se poser des questions sur la protection de ce super mode et on risque rapidement de se mordre la queue[4]. Soit l'utilisateur n'y a pas accès, et il faudra qu'il accepte de ne plus contrôler sa machine, ce qui entre dans la parfaite lignée de ce que certains voudraient faire des puces de sécurité type TCPA/TCG et NGSCB[5].

La seconde est tout simplement de savoir comment on va détecter les sales bêtes pour les tuer. La plupart des défenseurs de ces OS de confiance ont la critique facile envers les antivirus et autres IPS locaux. Mais au fond, que vont-ils faire de plus que détecter des comportements jugés malicieux par les bonnes vieilles méthodes que sont les signatures, les heuristiques et les violations de politiques ? Parfois on se le demande, mais rassurez-vous, ce sera mieux, promis juré.

Finalement, la solution ne serait-elle pas le LiveCD ? Genre je boote, je surfe, et quand j'éteins tout se perd dans le néant, et les éventuels malwares avec. Voir la machine ne préviens quand ça commence à aller mal[6] et je reboote et envoie tout le monde ad patres. Attrayant non comme concept ? Si on oublie quelques détails pratiques futiles comme les mises à jour qui obligent, sinon à downloader une nouvelle ISO[7], au moins à regraver une nouvelle galette, ou encore le fait que le chargement des applications soit lent à mourir, on pourrait effectivement se laisser tenter. Mais ce serait oublier un peu vite qu'un utilisateur a besoin de stocker des données, et que parmi ces données, on trouvera des préférences, des applets, des fichiers personnels, des fonds d'écran, des économiseurs d'écran, voire des applications sous formes diverses (.mo par exemple) qui seront utilisés par le LiveCD. Genre pleins de trucs dans lesquels un malware un minimum adapté à ce contexte nouveau pourrait se loger et se retrouver tout naturellement exécuté au démarrage.

Bref, même si le niveau de protection devient de plus en plus grand au fur et à mesure qu'on ajoute des couches, il faudra bien se rendre compte au final qu'on ne fait que déplacer le problème...

Notes

[1] IDDQD dans le texte

[2] J'aime bien faire dans l'euphémisme parfois...

[3] Voire plus, mais restons modestes

[4] Et de se faire un tour de reins

[5] À ce sujet, je vous conseille de regarder cette vidéo, peu objective ceci dit

[6] Humm, ça sent le problème déjà vu

[7] on peut patcher des ISOs Slax en utilisant les modules .mo