Afin de permettre à une localité de contrôler la provenance des processus qu’elle héberge, la construction goto k du calcul devra mentionner explicitement une autorisation : le processus
gotopk. P
invoque le passeport p pour demander à entrer dans la localité k et y exécuter sa continuation P . Par cette primitive, le processus qui veut migrer demande à la localité k d’autoriser cette migration eu égard au passeport p. De cette façon, k peut interdire l’accès à tout processus non dûment autorisé.
Cette vision simple des passeports permettra de les intégrer très naturellement au langage développé dans les chapitres précédents : ils seront représentés par des noms ou des variables, exactement comme les canaux et les localités. Ce choix garantira une grande homogénéité du calcul, tout en permettant de réutiliser la souplesse des communications de noms, notamment l’extension des portées, pour les passeports. En particulier, un processus client qui demande à un serveur situé dans la localité sv de calculer un résultat pourra s’écrire, en omettant pour l’instant les types :
clJgotopsvsv. req ! h(sv, cl), (question, rés, pass)i | . . . rés ? (x) PK
Le processus peut en effet transmettre, en plus de sa question et du canal sur lequel le résultat doit être rendu (rés dans cl), un passeport pass à utiliser pour entrer dans la localité cl afin d’y communiquer le résultat. Le serveur en question ressemblerait à :
svJ∗req ? ((xsv, xcl), (xquestion, xrés, xpass) : T) · · · calcul · · · gotoxpassxcl. xrés! hriK
où le passeport utilisé à la fin du traitement de la requête est une variable qui est instanciée lorsqu’un client transmet sa requête. Le client contrôle ainsi explicitement, à la fois les localités auxquelles il donne accès mais également à quel instant et sur quel canal cette permission est réellement transmise.
Afin de permettre au client de donner au serveur accès à sa localité, on rajoutera au calcul la possibilité de générer de nouveaux passeports. Tout comme newloc permet de créer dynamiquement de nouvelles localités et newchan de nouveaux canaux, newpass introduira de nouveaux passeports. À l’aide de cette nouvelle construction, on peut enrichir l’exemple précédent de la façon suivante :
clJnewpass pass in gotopsvsv. req ! h(sv, cl), (question, rés, pass)i | . . . rés ? (x) PK
Le processus commence par générer le passeport pass avant de le communiquer au serveur pour l’autoriser à venir donner sa réponse. Il va de soi que le passeport ainsi créé ne peut servir qu’à accéder à la localité cl dans laquelle la primitive newpass est exécutée. Dans le cadre très simple du contrôle présenté ici, les processus qui auront le droit de créer un nouveau passeport pour entrer dans une localité donnée seront exactement les processus qui s’y exécutent. Cette hypothèse se justifie par le fait que tout processus ayant réussi à pénétrer dans la localité dispose d’un passeport idoine, il doit « donc » être fiable.
En revanche, cet exemple suggère une petite modification pour traiter cette interaction de façon plus stricte : le passeport pass, qui est délivré au serveur pour qu’il puisse rapporter son résultat, pourrait n’être généré que dans ce but-là en permettant de vérifier au passage que les processus l’utilisant proviennent effectivement du serveur. On exprimera cette nouvelle contrainte de la façon suivante :
clJnewpass pass from sv in
gotop
svsv. req ! h(sv, cl), (question, rés, pass)i | . . . rés ? (x) PK Ce passeport pass ne sera alors utilisable que pour les migrations entre les localités sv et cl.
Bien entendu, cette méthode de contrôle n’empêche absolument pas un serveur voyou d’utiliser le passeport qui lui est donné pour attaquer le client. Cependant une utilisation plus précautionneuse des passeports permet d’éviter de compromettre toute la localité cl. Un client peut ainsi se protéger en générant une nouvelle localité servant d’intermédiaire, en procédant de la façon suivante :
clJ newloc (sas, réssas, passsas, passcl)
with réssas? (x) gotopassclcl. rés ! hxi
in gotop
kk. req ! h(sv, sas), (question, réssas, passsas)i
| · · · rés ? (x) P K
Dans cette version, au lieu de confier directement un passeport autorisant l’accès à la localité cl, le client ne communique qu’un passeport pour une localité temporaire, un sas créé pour l’occasion. C’est pourquoi il émet la requête (sv, sas), (question, réssas, passsas) au lieu de (sv, cl), (question, rés, pass). Il doit
par conséquent aussi placer un processus dans cette localité temporaire pour relayer la réponse en provenance du serveur. Pour que ce relais puisse fonctionner, il aura bien sûr besoin d’un passeport pour rentrer dans la localité du client cl. C’est pourquoi, lorsque la localité sas est générée, un passeport passcl est créé au
Fig. 4.1 Modifications et ajouts à la syntaxe des processus (voir figure 1.2)
P ::= Processus
gotovu. P Migration
newloc l, (~c), (~p), (~q) : L with Plin P Création de localité
newpass p from ˜u in P Création de passeport
newpass p from ? in P Création de passeport universel
passage, en plus du canal réssas de réponse et du passeport passsas permettant
d’accéder au sas. Il est indispensable que ces passeports soient créés en même temps que le sas, sans quoi il serait impossible de migrer entre ce sas et la localité cl du client.
Le fait que les passeports soient des identifiants comme les autres permettra de garantir que seules les deux continuations de la primitive newloc disposent de ce passeport. Il est par conséquent assez facile de se convaincre que, dans cet exemple, il n’y aura pas de fuite et que ce passeport restera inaccessible aux processus envoyés par le serveur et s’exécutant dans le sas. En procédant de cette façon et malgré la simplicité du modèle de sécurité, le client se prémunit d’un détournement du passeport qu’il transmet au serveur. En utilisant systé- matiquement cette technique, c’est-à-dire en ne délivrant jamais de passeport donnant accès directement à sa localité mais toujours à des localités temporaires, le client pourra ainsi garder le contrôle sur tous les processus qui rentrent dans sa localité principale.
En utilisant la même démarche que dans les chapitres précédents, l’usage d’un système de types permet d’effectuer une analyse statique des processus afin de savoir s’ils n’essayent pas de surpasser leurs droits. Dans ce cadre de contrôle des migrations, un surpassement supplémentaire devra être évité : la tentative par un processus d’entrer dans une localité sans disposer d’un passeport adéquat. Le système de types que nous allons voir ajoutera pour cela un nouveau type d’identifiant correspondant aux passeports. Cet ajout permettra aussi d’utiliser la technologie des équivalences observationnelles typées développée dans les chapitres précédents pour vérifier la fiabilité apportée par l’introduction des passeports : l’environnement Ω modélisant les connaissances de l’observateur pourra ainsi indiquer finement quelles sont les localités auxquelles il peut accéder en précisant l’ensemble des passeports à sa disposition pour effectuer ses observations.