소스 검색

misc:correction diverses

Alexandre Janniaux 6 년 전
부모
커밋
1fbaa3c718
4개의 변경된 파일63개의 추가작업 그리고 42개의 파일을 삭제
  1. 28 25
      chapters/vlc_explanations.tex
  2. 1 1
      chapters/vlc_introduction.tex
  3. 27 12
      chapters/what_is_sandboxing.tex
  4. 7 4
      chapters/why_sandboxing.tex

+ 28 - 25
chapters/vlc_explanations.tex

@@ -30,11 +30,11 @@ Actuellement, le développement de VLC est beaucoup centré sur son approche
 multi-thread, par exemple pour que les décodeurs et les sorties fonctionnent de
 manière indépendante et correctement synchroniser le temps. Le décodeur et la
 sortie vidéo fonctionnent ainsi de manière asynchrone. L'idée centrale est
-qu'avoir plusieurs entrées en lecture et plusieurs sorties simultanément ne
-doit pas être impossible. Une démonstration de ce fonction a d'ailleurs été mis
-en place en tant que «VLM», qui permet de contrôler plusieurs flux en entrées
-et de choisir comment les utiliser en sortie; que ce soit en les diffusant, en
-créant une mosaïque ou en affichant des flux dans de nouvelles sorties.
+qu'avoir plusieurs entrées en lecture et plusieurs sorties simultanément ne doit
+pas être impossible. Une démonstration de cette fonction a d'ailleurs été mis en
+place en tant que «VLM», qui permet de contrôler plusieurs flux en entrées et de
+choisir comment les utiliser en sortie; que ce soit en les diffusant, en créant
+une mosaïque ou en affichant des flux dans de nouvelles sorties.
 
 \section{Variables de configuration}
 
@@ -49,11 +49,11 @@ règles. On peut par exemple les créer avec une valeur par défaut, les créer
 leur donner de valeur ou bien les créer en les initialisant récursivement avec
 la valeur du parent.
 
-Ces variables portent ainsi une configuration qui est propre à eux, qui vient de
-la configuration imposée ou suggérée par leur parent, qui vient de la
-configuration donnée en ligne de commande ou qui vient du fichier de
-configuration de VLC. Il s'agit donc d'un mélange entre une interface
-utilisateur et une interface entre modules.
+Ces variables portent ainsi une configuration qui leur est propre, venant de la
+configuration imposée ou suggérée par leur parent, qui vient de la configuration
+donnée en ligne de commande ou qui vient du fichier de configuration de VLC.\@
+Il s'agit donc d'un mélange entre une interface utilisateur et une interface
+entre modules.
 
 \section{Modules}
 
@@ -66,6 +66,8 @@ l'application.
 Les modules sont manipulés à travers les \inltype{vlc_plugin_t} qui eux-même
 manipulent les \inltype{module_t} contenant la représentation interne du module.
 
+% TODO: décrire plus exactement ce qu'il faut highlight, en particulier
+% chargement des modules dans la sandbox, stockage des options, etc
 \begin{code}{c}{Structure d'un plugin}
 typedef struct vlc_plugin_t
 {
@@ -127,7 +129,8 @@ struct module_t
 };
 \end{code}
 
-De l'autre côté, \inltype{module_t} est réellement la description d'un module.
+De l'autre côté, \inltype{module_t} contient la description d'un module, qu'il
+soit chargé dynamiquement ou non.
 
 Chaque module dispose d'une priorité, qui correspond au score \inltype{i_score}
 dans \inltype{module_t}.
@@ -141,9 +144,22 @@ priorité qui est capable de se charger sans erreur.
 contenu d'une variable au lieu d'une recherche hardcodée.
 \end{itemize}
 
+Les détails de ces fonctions sont décrits ici car il s'agit de l'interface
+exposée par VLC pour charger un nouveau module. C'est donc un point d'entrée
+potentiel pour l'injection des abstractions de la sandbox.
+
+\begin{code}{c}{API de requête de module}
+module_t *vlc_module_load(vlc_object_t *obj, const char *capability,
+                          const char *name, bool strict,
+                          vlc_activate_t probe, ...);
+
+module_t *module_need(vlc_object_t *obj, const char *cap, const char *name,
+                      bool strict)
+\end{code}
+
 Ces fonctions sont généralement appelées après avoir créé un objet correspondant
 au type du module en question. Si dessous, on peut voir un exemple au sein de
-l'api de gestion des documents XML.
+l'api de gestion des documents XML.\@
 
 \begin{code}{c}{Création d'objet VLC puis chargement de modules}
     /* from src/misc/xml.c */
@@ -165,16 +181,3 @@ de type \inltype{xml_reader}.
 % TODO: parler de libvlc et vlc_object
 + parler des variables VLC
 
-
-\begin{code}{c}{API de requête de module}
-module_t *vlc_module_load(vlc_object_t *obj, const char *capability,
-                          const char *name, bool strict,
-                          vlc_activate_t probe, ...);
-
-module_t *module_need(vlc_object_t *obj, const char *cap, const char *name,
-                      bool strict)
-\end{code}
-
-Les détails de ces fonctions sont décrits ici car il s'agit de l'interface
-exposée par VLC pour charger un nouveau module. C'est donc un point d'entrée
-potentiel pour l'injection des abstractions de la sandbox.

+ 1 - 1
chapters/vlc_introduction.tex

@@ -1,5 +1,5 @@
 Ce rapport formalise mon stage ingénieur de fin d'étude, réalisé de février
-2018 à aout 2018. Il retrace l'ensemble de mon travail au sein de l'entreprise
+2018 à août 2018. Il retrace l'ensemble de mon travail au sein de l'entreprise
 VideoLabs, en prenant comme sujet principal la transformation de VLC pour
 introduire un modèle multi-processus à travers un fil d'ariane dédié au
 sandboxing.  Le sandboxing consiste à isoler les parties de l'application en

+ 27 - 12
chapters/what_is_sandboxing.tex

@@ -3,7 +3,8 @@ totalité ou en partie. L'objectif est de définir un contexte restreint
 d'exécution pour l'application, de façon à limiter son impact potentiel sur le
 reste du système dans le cas où elle serait compromise. Il n'est ici pas
 question de protéger l'application d'une menace extérieure à la sandbox mais
-bien de protéger l'utilisateur final en dernière mesure.
+bien de protéger l'utilisateur final en dernière mesure, et plus précisément ses
+données si l'application venait à être compromise par un attaquant.
 
 %TODO> Sandbox rule no 1: le sable reste dans le bac à sable.
 
@@ -11,32 +12,46 @@ bien de protéger l'utilisateur final en dernière mesure.
 
 Le cas d'une application comme VLC montre les limites d'un sandboxing
 non intrusif, effectué application par application. VLC peut se connecter au
-réseau pour télécharger un flux vidéo, l'enregistrer sur le disaque et en même
+réseau pour télécharger un flux vidéo, l'enregistrer sur le disque et en même
 temps le décoder et l'afficher en rendu direct via le GPU, sans compter le
 fenêtrage et la rediffusion. Trouver des règles génériques pour toute
 l'application revient à autoriser l'application à faire presque n'importe quoi
-en cas d'exécution de code arbitraire.
+en cas de compromission.
 
 Il est alors nécessaire de séparer l'application en plusieurs parties isolées.
-Étant donné que l'on se place dans la situation où n'importe quel code peut être
-exécuté, il faut non seulement l'isolation des ressources et permissions mais
-également de la mémoire. La solution naturelle est donc de les séparer dans des
-processus indépendant. Le défi est alors d'apporter cette architecture
+D'autant plus que l'on se place dans la situation où n'importe quel code peut
+être exécuté, il faut non seulement l'isolation des ressources et permissions
+mais également de la mémoire. La solution naturelle est donc de les séparer dans
+des processus indépendant. Le défi est alors d'apporter cette architecture
 multiprocessus dans VLC, en restant multiplate-forme et en ayant le moins
 d'impact possible sur les perfomances.
 
 // TODO critère performance
 
-Il est également hors de question de devoir trop modifier les modules, ceux-ci
-comptant pour dix fois plus de code que le core lui-même. La solution doit
-s'intégrer dans le core de VLC et être désactivable.
+De plus, VLC est composé d'un ensemble de plusieurs centaines de modules
+apportant les fonctionnalités dans l'application, et une base de code appelé
+libvlccore ou bien simplement le core, qui orchestre ces modules et leur fournit
+des opérations communes.
+
+Il est alors coûteux de devoir trop modifier les modules eux-même lors de
+l'intégration de la sandbox, ceux-ci comptant pour dix fois plus de code que le
+core lui-même.
+
+Enfin l'implémentation de la sandbox doit pouvoir être désactivable, soit pour
+lire certains formats ne pouvant être lu sans, soit pour faciliter le débogage
+de l'application pendant le développement. La solution doit donc s'allier au
+core de VLC de façon dynamique sans laisser d'ouverture possible.
 
 La désactivation de la sandbox signifie que les mécanismes nécessaires à son
 utilisation, la séparation des processus et les mécanismes d'isolation ne sont
 pas activées. Cela ne signifie évidemment pas que l'on peut désactiver la
-sandbox «en vol», pendant l'exécution du programme.
+sandbox «en vol», pendant l'exécution du programme. En effet, dans ce dernier
+cas, si un bout de l'application se retrouve corrompu, il ne doit pas être
+capable de s'échapper du cadre que la sandbox a établi au démarrage. Si ce bout
+de code était capable de désactiver la sandbox, on se retrouverait avec la même
+situation que si aucune mesure n'avait été appliquée dès le départ.
 
-Parmi ce qu'on a appelé permissions et accès, on va en particulier retrouver
+Parmi ce qu'on a appelé permissions et accès, on va en particulier retrouver:
 
 \begin{itemize}
     \item Chaque descripteur de fichier (que ce soit un fichier ou un autre objet)

+ 7 - 4
chapters/why_sandboxing.tex

@@ -9,7 +9,7 @@ plus de garanties de sécurité. Après tout, s'il n'y a pas de faille possible,
 n'y a pas besoin de se protéger de ses failles.
 
 Dans le monde réel, ces deux objectifs de sécurité, le sandboxing et la
-réduction des failles, sont totalement orthogonal et les deux efforts doivent
+réduction des failles, sont totalement orthogonaux et les deux efforts doivent
 être réalisés en même temps. Corriger des brêches dans la sécurité de
 l'application permet de s'assurer que le samdboxing fonctionne plus
 efficacement, tandis qu'isoler les différentes parties de l'application permet
@@ -18,8 +18,10 @@ de limiter l'impact d'une faille potentielle avant qu'elle soit corrigée.
 Le sandboxing joue ici le rôle de réduction de la surface d'attaque, qui est un
 mécanisme classique. Le code en lui-même de la sandbox est censé être plus
 facilement auditable, beaucoup plus court et moins dépendant du domaine lié à la
-solution qu'apporte le logiciel. C'est donc particulièrement intéressant dans le
-cas du multimédia qui demande une palette de compétences assez large.
+solution qu'apporte le logiciel, c'est-à-dire ne pas forcément saisir les
+spécificités liées au multimédia dans notre cas. C'est donc particulièrement
+intéressant dans le cadre de logiciels comme VLC ou Chromium qui demande une
+palette de compétences assez large.
 
 Il faut néanmoins ne pas oublier qu'il ne s'agit pas d'un patch magique. Une
 sandbox intrusive introduit du nouveau code et de nouvelles interactions avec le
@@ -30,6 +32,7 @@ mettre une attention particulière à la vérification des mesures mises en plac
 
 \section{Dans VLC}
 
+% TODO expliquer ce qu'est une CVE
 Le sandboxing apporte particulièrement une plus grande confiance dans VLC qui a
 déjà subit plusieurs CVE. Ces CVE touchent en grande partie les modules de
 demux, qui permettent de récupérer les différents flux, audio, vidéo et
@@ -54,7 +57,7 @@ lié au travail multimédia réalisé par VLC.
 
 \section{Exemples d'attaques}
 
-Si les objectifs et besoin décrits au dessus paraissemt trop thérique, il est
+Si les objectifs et besoins décrits au dessus paraissemt trop théorique, il est
 possible de prendre des exemples de la vraie vie pour se convaincre d'avoir
 besoin de ces mesures. L'exemple le plus connu de sandbox intrusive est celle
 de Chromium, qui s'appelle lui-même «The Most Secure Browser.» Le développement