\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.

%TODO: Ajouter image

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 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 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 pire situation où un bout entier de
l'application est compromis, il faut alors 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.

Afin de relier les parties ainsi séparées, 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é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. 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 lus avec, 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és. Cela ne signifie évidemment pas que l'on peut désactiver la
sandbox \og{}en vol\fg 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 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 \og{}accès\fg{} le fait de pouvoir effectuer des actions de lecture
et écriture sur la ressource.

On va désigner par \og{}permissions\fg{} 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 \og{}jeton d'accès\fg{} 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 \og{}capabilities\fg{}, constituent l'une des
meilleures méthodes de description des accès et évitent des problématiques comme
le \og{}confused deputy problem\fg{} \cite{ConfusedDeputy} dans la littérature. La
comparaison entre l'implémentation Linux et les tentatives d'implémentation sous
Windows vont révéler ceci dans la suite, Linux permettant bien plus facilement
de construire ces jetons. Nous tenterons tout particulièrement de concevoir
de tels objets pour décrire l'API entre nos processus\cite{ObjectsAsCaps}.