URL: https://linuxfr.org/news/oswatcher-suivre-l-evolution-des-systemes-d-exploitation-au-cours-du-temps Title: OSWatcher : suivre l’évolution des systèmes d’exploitation au cours du temps Authors: Wenzel Benoît Sibaud, palm123, bubar🦥, Davy Defaud et ZeroHeure Date: 2018年11月01日T18:23:08+01:00 License: CC By-SA Tags: fosdem, ubuntu, neo4j, libvirt et système_d'exploitation Score: 45 Bonjour [_LinuxFr.org_](https://linuxfr.org/). J’aimerais te faire part d’une idée qui me trottait dans la tête depuis quelques années, puis de sa concrétisation il y a quelques mois en un vrai [projet](https://github.com/Wenzel/oswatcher). Les questions qui ont fait germer cette idée sont les suivantes : - quels sont les binaires UNIX présents sur toutes les distributions modernes ? - quels sont les fichiers en communs sur tous les Windows de XP à 10 ? - est‐ce que les systèmes d’exploitation (OS) distribuent les binaires avec les meilleures options de compilations ? - quelles sont les bibliothèques chargées par défaut sur Ubuntu 16.04 ? - quelles sont les différences de configuration par défaut entre les grandes distributions ? Pourrions‐nous y trouver des choses intéressantes ? - etc. ---- [OSWatcher sur GitHub](https://github.com/Wenzel/oswatcher) ---- # Présentation En somme, l’objectif du projet est de nous donner une vision plus haut niveau sur tout l’historique de nos système d’exploitation. Voyez cela comme une sorte de « _DistroWatch_ sous stéroïdes ». 😃 Le cœur du projet repose sur la **capture** des **caractéristiques** d’un système fraîchement installé, afin de les mettre dans une base de données. Une fois ceci fait, nous pourrions créer des _diffs_ entre ces mêmes caractéristiques, et ainsi nous permettre de comparer deux versions d’un même système d’exploitation, et donc de le suivre au cours de ses **évolutions**. La collecte de ces caractéristiques se fera en deux modes : hors ligne « _offline_ » et en ligne « _online_ » : ## Offline - arborescence du système de fichiers ; - propriétés des fichiers : - drapeau `setuid`, - options de compilation des exécutables ; - nombre de scripts shell, Perl et Python ; - tableau des appels système ; - configuration du noyau ; - tâches planifiées (`cronjobs`) ; - configuration des services dans `/etc`. ## Online - consommation mémoire `IDLE` ; - processus lancés par défaut ; - bibliothèques chargées en mémoire ; - ports ouverts et services/processus associés ; - requêtes DNS envoyées ; - _sockets_ `unix` ; - trafic D-Bus ; - règles de filtrage `iptables` ; - modules/pilotes chargés. # Objectifs Le projet pourra à terme desservir plusieurs grands objectifs : - base de données de **référence** : être capable d’effectuer des requêtes sur n’importe quelle caractéristique sur chaque système d’exploitation et, grâce à la mise à disposition d’une API, quiconque pourra trouver son propre usage et construire ses scripts par‐dessus ; - **sécurité** : en extrayant les options de compilation, il est possible de vérifier que les distributions appliquent les meilleures options sur les binaires ; en outre, il serait possible de scanner tous les scripts shell, Perl et Python avec un « _linter_ » pour faire ressortir des erreurs et mauvaises pratiques de manière automatisée ; cela a déjà été étudié avec le [Cyber‐Independant Test Lab](https://sarah-zatko.squarespace.com/), organisation avec laquelle j’ai tenté une collaboration (affaire à suivre) ; - suivi et **évolution** : but principal du projet, suivre les changements d’un même système d’exploitation au cours du temps grâce à des `diffs` entre des mêmes caractéristiques ; de plus, il serait possible de suivre les correctifs de Windows et de fournir aux chercheurs en sécurité un _diff_ binaire via une simple `URL`. 😃 # Outils ## SEE [_Sandboxed Execution Environment_](https://github.com/F-Secure/see) est un cadriciel Python développé par l’un de mes collègues à [F-Secure](https://www.f-secure.com). Conçu à la base pour analyser des binaires inconnus, il permet de définir un protocole (une suite de signaux) qui vont déclencher des [_hooks_](https://fr.wikipedia.org/wiki/Hook_(informatique)) (crochets logiciels). Basé sur le _pattern_ `Observer`, le fonctionnement est simple et permet notamment : - la définition d’un protocole pour une analyse ; - le découplage entre ce protocole et les actions qui vont en découler (`Observer` _pattern_) ; - les actions sont modulaires et chargées dynamiquement sous forme de crochets (`hooks`). J’ai réutilisé ce cadriciel dans OSWatcher, en définissant la capture d’un système d’exploitation comme on analyserait un binaire. J’ai défini un [protocole](https://github.com/Wenzel/oswatcher/blob/master/oswatcher/capture.py#L79) à suivre : ```Python def protocol(environement): context = environement.context config = environement.configuration['configuration'] context.trigger('protocol_start') context.trigger('offline') # start domain logging.info("Starting the domain") context.poweron() # wait until desktop is ready time.sleep(config['desktop_ready_delay']) context.trigger('desktop_ready') # shutdown context.poweroff() context.trigger('protocol_end') ``` Et j’ai implémenté les actions sous forme de _hooks_ : [`hooks.filesystem.py`](https://github.com/Wenzel/oswatcher/blob/master/hooks/filesystem.py) ```Python from see import Hook class FilesystemHook(Hook): def __init__(self, parameters): super().__init__(parameters) self.context.subscribe('offline', self.capture_fs) ``` Note : Les `hooks` peuvent eux‐mêmes déclencher de nouveaux signaux. → [GitHub](https://github.com/F-Secure/see) → [Documentation](https://see.readthedocs.io/en/latest/) ## Neo4j Côté base de données, j’avais commencé avec un bête MySQL, n’ayant pas entendu parler des bases de données orientées graphe. Les performances de parcours d’un système de fichiers étaient atroces, évidemment. Aussi j’ai basculé sur Neo4j, pour stocker l’arborescence et tout le reste des caractéristiques, ce qui m’a grandement simplifié la vie. # Ébauche Voilà où j’en suis concrètement sur le projet : ## Extracteur L’extracteur comporte les _hooks_ suivants : - `FileSystemHook` : basé sur `libguestfs` pour parcourir le système de fichiers ; - `MemoryDumpHook` : utilise l’API `libvirt.coreDumpWithFormat` pour générer un vidage mémoire, puis lance une session avec l’outil d’analyse d’image mémoire [`Rekall`]() : - `ProcessListHook` : extrait les processus avec le greffon `pslist` de `Rekall`, - `SyscallTableHook` : extrait les appels système avec le greffon `ssdt` de `Rekall` ; - `OperatingSystemHook` : crée le nœud principal dans `Neo4j`, fait le lien avec les données des autres _hooks_. Ci‐dessous un exemple de l’extracteur lancé sur une machine virtuelle Ubuntu 16.04, avec le `FilesystemHook` configuré : ![extracteur_ubuntu_filesystem](https://user-images.githubusercontent.com/964610/47535862-14ddbb00-d8c6-11e8-88cd-efa5db339bb8.jpg) Exemple de configuration des `hooks` : ```json { "configuration": { "delete": true, "desktop_ready_delay": 90 }, "hooks": [ { "name": "hooks.system.OperatingSystemHook" }, { "name": "hooks.filesystem.FilesystemHook", "configuration": { "delete": true, "enumerate": true, "log_progress": true, "log_progress_delay": 10, "inode_checksums": false } }, { "name": "hooks.memory.MemoryDumpHook" }, { "name": "hooks.syscall.SyscallTableHook" }, { "name": "hooks.process.ProcessListHook" } ] } ``` ## Base de données Ci‐dessous un exemple de ce à quoi peut ressembler un système de fichiers dans Neo4j (vue de `/etc`) : ![etc_neo4j](https://user-images.githubusercontent.com/964610/47535864-18714200-d8c6-11e8-885b-27d17c8d6235.png) ## Interface Web Et, enfin, mes tentatives à faire un frontal Web : - `VueJS` ; - `vue-apollo` : pour discuter avec la BDD en `GraphQL` ; - `Buefy` : pour un cadriciel CSS ; - `neo4j-graphql` : _hook_ permettant d’exposer une API `GraphQL` sur Neo4j. ![Système de fichiers](https://user-images.githubusercontent.com/964610/47759052-82b72780-dcb6-11e8-9730-c0ea15783163.jpg) ![Processus](https://user-images.githubusercontent.com/964610/47759058-8c408f80-dcb6-11e8-8685-fe84d54104bc.jpg) ![Tableau des appels système](https://user-images.githubusercontent.com/964610/47759061-8ea2e980-dcb6-11e8-8f79-a3da26ed6bae.jpg) # Futur La suite du projet fera l’objet d’une discussion éclair (_lightning talk_) au [FOSDEM 2019](https://fosdem.org/2019/ "Free and open source software developers’ European meeting"), s’il est accepté ! J’avais pour prochain objectif de produire un diagramme camembert en D3js, donnant des statistiques sur chaque type de fichier présent (ex : `perl script: 0,5%`). Mais je ne suis définitivement pas un développeur Web, et je vais me contenter de créer un petit script Python qui exploite ma base de données et affiche les statistiques dans le terminal. Par ailleurs, j’aimerais recevoir vos retours et vos conseils pour mener à bien ce projet. 😃

AltStyle によって変換されたページ (->オリジナル) /