Obtention de capacit´es

Nous nous int´eressons maintenant `a l’origine des capacit´es. Le syst`eme assure qu’une capacit´e ne peut pas ˆetre « forg´ee » par l’utilisateur : toute capacit´e est obtenue soit par le noyau cr´eant une nouvelle capacit´e vers un objet, soit par le noyau copiant une capacit´e existante.

Le noyau assure ´egalement que les capacit´es ne sont plus modifi´ees une fois cr´e´ees. Ces propri´et´es sont impl´ement´ees en segmentant la m´emoire : les pages m´emoires contenant les C-lists ne sont accessibles que par le noyau, jamais directement. 3.3.4.1 Cr´eation de capacit´es

On ne cr´ee une nouvelle capacit´e que lorsque l’on cr´e´ee un nouvel objet. Toutes les autres capacit´es vers un objet sont obtenues en copiant cette capacit´e. Inversement lorsqu’on cr´ee un objet, on est assur´e que tout acc`es `a cet objet se fait par la capacit´e cr´e´ee simultan´ement (ou une de ses copies). Cette correspondance est importante : on s’en sert pour garantir formellement qu’un domaine n’a pas l’autorisation d’acc´eder `a un objet (il ne peut acc´eder `a un objet que s’il y a un moyen par lequel on lui aurait copi´e une capacit´e vers cet objet). Cela permet d’assurer l’isolation des ressources entre diff´erentes tˆaches.

La cr´eation de capacit´e vers un service serv se fait en invoquant la m´ethode create capsur une capacit´e sur le domaine serv, qui dispose du droit CREATE CAP. En particulier, la cr´eation de capacit´e n’est pas forc´ement faite depuis serv. Cela permet `a un service de politique de cr´eer de nouvelles capacit´es sans notifier le service de m´ecanisme, comme dans le protocole de la section 3.2.2.2.

L’impl´ementation est la suivante. Cette m´ethode prend en param`etre l’index i o`u on d´esire que la nouvelle capacit´e soit stock´ee, un param`etre rights, un param`etre data, et une adresse virtuelle vaddr. La m´ethode cr´ee une capacit´e dans la c-list `a

14

Hydra utilisait cette convention pour v´erifier des droits lors de l’invocation sans avoir `a les interpr´eter, tandis que nous l’utilisons pour restreindre les droits lors de la copie.

3.3.4. Obtention de capacit´es

l’endroit i indiqu´e par l’appelant, en remplissant les champs destination, data, et rightspar respectivement serv, object et rights.

Le syst`eme incr´emente un compteur d’estampille global 64 bits pour r´ecup´erer une nouvelle date, et la stocke dans le champ date de la capacit´e, et `a l’adresse vaddr15.

Pour le protocole de s´eparation politique/m´ecanisme, cela demande juste `a ce que les dates des objets soient accessibles en ´ecriture aux services de politique ; nous mettons en place de la m´emoire partag´ee entre les services de politique et de m´ecanisme pour ce faire16

.

Ce m´ecanisme est simple, flexible et efficace, mais nous nous sommes rendus compte par la suite qu’il posait un probl`eme de confidentialit´e. Il est possible de communiquer par canal cach´e en incr´ementant le compteur d’estampille `a un certain rythme. Cela n’a n´eanmoins pas d’importance pour la s´ecurit´e au sens partitionnement avionique.

Il y a diff´erents moyens d’´eviter cela. Un premier serait de resynchroniser le compteur `a chaque d´ecision d’ordonnancement : les premiers bits contiendraient la date, et seuls les derniers seraient incr´ement´es `a chaque utilisation. Cela efface les informations sur les pr´ec´edents incr´ements du compteur, et donc coupe le canal cach´e. Une autre possibilit´e est d’utiliser un compteur processeur, qui garantit ˆetre incr´ement´e `a chaque fois qu’il est lu. Le compteur de cycles (timestamp counter) du Pentium pr´esente cette garantie. Enfin, on pourrait faire la « partie service » de l’invocation par le noyau pour cacher les valeurs du compteur d’estampille.

3.3.4.2 Copie de capacit´e

La copie de capacit´e est le deuxi`eme m´ecanisme par lequel une capacit´e peut ˆetre obtenue. C’est notamment grˆace `a lui qu’on va pouvoir impl´ementer le partage des ressources.

La copie d’une capacit´e c n´ecessite plusieurs conditions. Il faut que :

1. c soit accessible (i.e. soit dans la C-list du domaine courant ou celle du thread courant)

2. c aie le droit COPY RIGHT, qui est un des droits r´eserv´es par le noyau ; 3. que l’on dispose d’une capacit´e c′

sur la C-list de destination (e.g. sur un objet thread ou domaine), qui aie le droit MODIFY CLIST.

Quand ces conditions sont r´eunies, on invoque la m´ethode copy cap sur c′

avec en param`etre l’index i o`u se trouve c, l’indice i′

o`u placer la capacit´e une fois copi´ee, et un masque de droit mask. La m´ethode copie c avec tous ses champs `a l’emplacement i, sauf le champ rights, pour lequel la valeur de l’expression rights & mask est stock´ee.

15

Nous arrangeons l’espace d’adressage afin que le noyau puisse s’assurer facilement qu’il n’est pas dangereux d’´ecrire `a une adresse virtuelle donn´ee.

16

Cette m´emoire partag´ee est la raison principale pour laquelle nous avons restreint la hi´erarchie des politiques `a deux niveaux, dont le premier est statique

Le param`etre mask permet d’affaiblir les droits donn´es `a une capacit´e copi´ee. Par exemple, une capacit´e sur un buffer en lecture/´ecriture pourra ˆetre transmis en lecture seule. Cet affaiblissement des capacit´es suit le principe du moindre privil`ege (§ 2.2.2.4). Notons qu’il est important que la copie ne puisse qu’affaiblir des privil`eges existants, et non les augmenter ; sinon un domaine pourrait acc´eder `a des privil`eges non pr´evus par simple copie de capacit´e. Le fait que la pr´esence de privil`ege soit toujours repr´esent´ee par un 1, permet au noyau de garantir que les privil`eges sont toujours affaiblis sans que lui-mˆeme aie `a interpr´eter ces privil`eges (§ 3.3.3.2). 3.3.4.3 Contrˆole de la propagation des capacit´es

Du fait que l’utilisation d’une des deux m´ethodes ci-dessus est n´ecessaire pour obtenir une capacit´e, il r´esulte que toute capacit´e vers un objet est obtenue soit au moment de la cr´eation de l’objet, soit par copies successives de cette capacit´e initiale. Cette propri´et´e va notamment permettre de prouver qu’une ressource n’est ni partag´ee, ni partageable, entre deux partitions. Il suffit pour cela que la politique ne fournisse une capacit´e qu’`a une des partitions, et de s’assurer que cette partition ne puisse transmettre sa capacit´e `a l’autre.

Avoir une politique qui ne fournisse une ressource qu’`a une partition est simple. Nous nous int´eressons au contrˆole de la propagation.

La m´ethode principale consiste `a limiter les canaux permettant de copier une capacit´e. Si une capacit´e c est pr´esente dans une C-list C, elle ne peut ˆetre copi´ee que de trois mani`eres :

1. directe, si C poss`ede une capacit´e vers une autre C-list ; 2. indirecte, si C poss`ede une autre capacit´e c′

, l’invocation de c′

permet la transmission de capacit´es vers le service gestionnaire de c′

;

3. indirecte inverse, s’il est possible d’invoquer le domaine qui contient C. En dessinant la configuration initiale du syst`eme, on peut trouver par transitivit´e quels domaines peuvent acc´eder `a quelle capacit´e [MYS03]. En particulier, notre syst`eme ´etant structur´e sous la forme d’un arbre (Figure 3.1 page 86), la propagation de capacit´es entre partitions n’est possible que par la complicit´e des services partag´es.

Une autre mani`ere pour restreindre la copie d’une capacit´e est de retirer son droit COPY RIGHT. Mais on peut d´esirer qu’une capacit´e puisse ˆetre copi´ee librement dans une partition, mais pas `a l’ext´erieur de cette partition (par exemple pour une politique de s´ecurit´e MLS) ; dans ce cas cette m´ethode est trop restrictive. On l’utilise surtout par s´ecurit´e, pour ´eviter que des capacit´es transmises lors d’une invocation ne puisse se propager (permet d’´eviter la propagation indirecte).

La derni`ere m´ethode consiste `a assurer qu’il n’y a pas de capacit´e existante sur une C-list avec le droit MODIFY CLIST. Ainsi, il est impossible d’ajouter une capacit´e vers cette C-list. Cette m´ethode est ´egalement tr`es restrictive, mais il arrive souvent qu’on sache qu’un domaine n’utilisera pas plus de capacit´es, en particulier pour la plupart des services ; ainsi suivant le principe du moindre privil`ege, on peut retirer tout droit d’ajouter une capacit´e `a ce service. Cela garantit l’absence de propagation par l’interm´ediaire des services partag´es.