Limites de l'inspection de la pile

Ceci est un suivi du fonctionnement de l' inspection des piles? qui explore la notion plus en détail

L'inspection de la pile est un mécanisme permettant d'assurer la sécurité dans le contexte des machines virtuelles JVM et CLR lorsque des modules de code téléchargés en externe de différents niveaux de confiance peuvent s'exécuter ensemble. Ces bibliothèques système ont besoin d'un moyen de distinguer les appels provenant de code non approuvé des appels provenant de l'application approuvée elle-même. Cela se fait en associant au code le principal correspondant à son origine. Ensuite, les autorisations d'accès sont enregistrées sur la pile et chaque fois qu'un appel à une méthode système sensible est effectué, la pile est parcourue pour voir si les autorisations appropriées pour le principal effectuant l'appel sont présentes sur la pile.

Quelles sont les limites de l'inspection de la pile? Quels mécanismes ont été proposés pour le remplacer? Des modifications importantes ont-elles été apportées au modèle depuis son introduction à la fin des années 90?

L'inspection de la pile est nécessaire car les programmes sur la JVM et le CLR ont un accès par défaut aux opérations dangereuses, donc quelque chose doit être fait pour éviter les catastrophes. Par exemple, un programme non approuvé peut référencer une bibliothèque d'E / S et l'appeler:

using IO;
...
IO.DeleteFile("/home/foo/bla");

Donc, à chaque opération dangereuse effectuée, nous devons vérifier si elle est autorisée. Avec l'inspection de la pile, il est généralement compliqué de comprendre qui a accès à quoi. Cela rend également difficiles les optimisations telles que les appels en ligne et les appels de queue.

Un mécanisme supérieur consiste à ne pas donner à chaque programme un accès automatique aux opérations dangereuses en premier lieu. Dans ce modèle, il n'y a aucun moyen d'importer une bibliothèque d'E / S. La seule façon d'accéder à une bibliothèque d'E / S est si quelqu'un d'autre vous l'a donnée. C'est ce qu'on appelle la sécurité des capacités. Une introduction peut être trouvée ici .

Au lieu de cela, nous écririons le programme précédent comme ceci:

Main(IOLibrary IO){
  IO.DeleteFile("/home/foo/bla");
}

La bibliothèque d'E / S est un paramètre du point d'entrée du programme, et cela s'appelle une capacité (car elle donne à utiliser une certaine capacité, dans ce cas à faire des E / S). Pour pouvoir exécuter ce programme, nous devons avoir accès à une capacité d'E / S nous-mêmes et exécuter le programme en appelant Main(ourIOlibrary). Si nous exécutons un programme non approuvé, nous ne lui transmettons tout simplement pas notre bibliothèque d'E / S, car il pourrait utiliser cette bibliothèque pour supprimer nos fichiers. Dans certains cas, nous voulons donner à un programme non approuvé un accès limité au système de fichiers. Dans ce cas, nous créons un wrapper autour de notre propre bibliothèque IO qui autorise uniquement l'accès à un certain répertoire et le transmettons au programme non approuvé au lieu de la bibliothèque IO complète

Donc, si nous avons besoin d'une capacité d'E / S pour invoquer un programme qui a besoin d'une capacité d'E / S, cela signifie également que tout ce qui a invoqué notre programme devait avoir accès à une capacité d'E / S pour pouvoir nous le donner. D'où vient donc sa capacité d'E / S? Eh bien, il y a finalement un moment où l'homme qui fait fonctionner l'ordinateur a invoqué un programme. Cet humain a accès à toutes les capacités du système, il a donc pu transmettre la capacité IO. Si cet humain ne fait pas confiance au programme qu'il exécute, il ne lui transmettra tout simplement pas sa capacité d'E / S.

Vous pouvez probablement facilement imaginer d'autres types de capacités: accès à Internet, accès pour dessiner des choses sur votre écran, etc. Par exemple, un système de plug-in de navigateur sécurisé peut donner une capacité graphique à un plug-in non fiable qui ne lui permet de peindre des graphiques que dans un rectangle prédéfini. sur la page.

Une limitation de l'inspection de pile telle qu'elle est traditionnellement mise en œuvre est qu'elle rompt les appels de queue appropriés. En particulier, les implémentations typiques doivent conserver la «pile» entière à tout moment. Clements et Felleisen montrent comment ce problème peut être résolu en utilisant une technique appelée «marques de continuation» dans leur article A Tail-Recursive Semantics for Stack Inspections in ESOP 2003.