| 123456789101112131415161718192021222324252627282930313233343536 |
- \section{Motivation}
- Une première méthode de cloisonnement qui n'a pas beaucoup été explorée est de
- cloisonner l'application par module et non par objet de libvlccore.
- Cette méthode permet d'arriver plus rapidement à une situation où l'ensemble
- des modules de VLC est cloisonné, mais libvlccore ne profite pas du tout de ce
- cloisonnement et il nous reste alors environ 100 000 lignes de code à auditer
- pour s'approcher de loin de la méthode précédente. Il est intéressant de
- mentionner cette technique du point de vue de l'architecture, étant donné
- qu'elle montre une autre façon de procéder à l'injection de la sandbox dans les
- modules et peut souligner de nouveaux défauts dans la conception du code.
- Comme on l'a vu dans les premières parties, VLC fonctionne à travers libvlccore
- en instanciant des modules, stockés dans des \inltype{vlc_object_t}. Chaque
- module étant créé puis détruit par le core, tout en fournissant une API commune
- au type de module, il peut être tentant de proposer de nouveaux modules avec un
- type similaire à celui demandé mais qui jouerait le rôle de passerelle vers le
- module réel dans un autre processus.
- Avec cette technique, le sandboxing est plus facile à intégrer dans
- l'application mais moins efficace.
- \section{Implémentation}
- La partie \og{}injection\fg{} consiste à complètement rediriger \inltype{module_need}
- vers le cœur de la sandbox pour transformer les requêtes de module vers des
- modules proxies. Le nom du module ou de la classe de module peut correspondre à
- une politique et permet ainsi de décider très finement et automatiquement quel
- module doit être redirigé vers un autre processus, nouveau ou déjà existant.
- C'est à ce moment que les étages définis précédemment vont intervenir pour
- permettre d'écrire le code de façon naturelle.
- Néanmoins, cette technique n'a pas été implémenté à cause des défauts
- d'isolation qu'elle possédait.
|
