Browse Source

chapters/what_is_sandboxing: reformulation et ajout de la partie accès

Alexandre Janniaux 7 years ago
parent
commit
20c5586123
1 changed files with 54 additions and 22 deletions
  1. 54 22
      chapters/what_is_sandboxing.tex

+ 54 - 22
chapters/what_is_sandboxing.tex

@@ -1,10 +1,13 @@
-Le sandboxing d'une application consiste à isoler l'application du système, en
-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, et plus précisément ses
-données si l'application venait à être compromise par un attaquant.
+\section{Définitions et objectifs du projet}
+
+Le sandboxing d'une application consiste à isoler l'application du reste du
+système, en 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, 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.
 
@@ -19,23 +22,26 @@ l'application revient à autoriser l'application à faire presque n'importe quoi
 en cas de compromission.
 
 Il est alors nécessaire de séparer l'application en plusieurs parties isolées.
-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.
+D'autant plus que l'on se place dans la pire situation où un bout entier de
+l'application est compromis, 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épendants. 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, c'est-à-dire en n'affectant pas les
+capacités de lecture de l'application.
 
-// TODO critère performance
+Afin de relier les parties ainsi séparer, il faudra implémenter un mécanisme de
+communication inter-processus, ou IPC.
 
 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é
+apportant les fonctionnalités dans l'application, et une base de code appelée
 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.
+core lui-même. Le côté intrusif de cette sandbox ne devra donc pas détruire le
+modèle actuel de modules mais plutôt venir le compléter.
 
 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
@@ -44,19 +50,45 @@ 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. En effet, dans ce dernier
+pas activés. Cela ne signifie évidemment pas que l'on peut désactiver la
+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.
 
+\section{Gestion des droits, permissions, accès, ressources}
+
+Dans la suite du document, nous allons utiliser plusieurs termes pour désigner
+les ressources ainsi que la façon de détérminer si l'utilisation de la ressource
+est autorisé.
+
 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)
-    \item Chaque bloc de données (qui sera un descripteur de fichier)
-    \item La permission de demander des fichiers
-    \item La permission de créer des sockets
+    \item Chaque descripteur de fichier, que ce soit un fichier ou un autre
+        objet.
+    \item Chaque bloc de données, qui sera un descripteur de fichier ou qui sera
+        émulé suivant d'autres méthodes.
+    \item La permission de demander l'accès à des fichiers.
+    \item La permission de créer des sockets réseaux.
+    \item La permission de créer des processus.
 \end{itemize}
 
+On va désigner par «accès» le fait de pouvoir effectuer des actions de lecture
+et écriture sur la ressource.
+
+On va désigner par «permissions» le fait que l'accès à une ressource soit donné
+selon une autorité ambiante, c'est-à-dire typiquement implicite dans
+le processus. Cela signifie généralement que l'ouverture de la ressource est
+soumise à un test des permissions.
+
+Enfin, on va désigner par «jeton d'accès» une ressource représentée sous la
+forme d'un objet et dont l'accès peut être transmis par le biais de ce jeton,
+sans pour autant que ce jeton soit forgeable.
+
+Les jetons d'accès, ou plus couramment «capabilities», constituent l'une des
+meilleures méthodes de description des accès et évitent des problématiques comme
+le «confused deputy problem» dans la littérature. La comparaison entre
+l'implémentation Linux et les tentatives d'implémentation sous Windows vont
+révéler cette nature dans la suite.