un modèle de contrôle d'accès générique et sa réalisation

HAL Id: tel-00004841https://tel.archives-ouvertes.fr/tel-00004841

Submitted on 18 Feb 2004

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, estdestinée au dépôt et à la diffusion de documentsscientifiques de niveau recherche, publiés ou non,émanant des établissements d’enseignement et derecherche français ou étrangers, des laboratoirespublics ou privés.

Un modèle de contrôle d’accès générique et sa réalisationdans la mémoire virtuelle répartie unique Arias

Christian Damsgaard Jensen

To cite this version:Christian Damsgaard Jensen. Un modèle de contrôle d’accès générique et sa réalisation dans lamémoire virtuelle répartie unique Arias. Réseaux et télécommunications [cs.NI]. Université Joseph-Fourier - Grenoble I, 1999. Français. �tel-00004841�

https://tel.archives-ouvertes.fr/tel-00004841

https://hal.archives-ouvertes.fr

UNIVERSITÉ JOSEPHFOURIER–GRENOBLEISCIENCES& GEOGRAPHIE

��

THÈSE

pourobtenirle gradede

DOCTEUR DE L’UNIVERSITÉ JOSEPHFOURIER

Discipline : INFORMA TIQ UE

Présentéeetsoutenuepubliquement

par

ChristianDamsgaardJENSEN

Le 29octobre1999

Un modèledecontrôle d’accèsgénériqueet saréalisationdansla mémoirevirtuelle répartie unique Arias

Directeurdethèse:

SachaKRAKOWIAK

COMPOSITION DU JURY :

M. RolandBalter PrésidentM. ClaudeBétourné RapporteurM. Bertil Folliot RapporteurM. DanielHagimont Co–directeur

Thèsepréparéeauseindu laboratoireSiracdel’INPG, l’INRIA Rhône–Alpeset l’UJF

Remerciements

Jetiensà remercierl’ensembledespersonnesqui, parleursconseils,leursencouragementsou leuraide,ontcontribuéà l’aboutissementdecetravail :

SachaKrakowiak, Professeurà l’Uni versitéJosephFourier, qui aencadrécetravail ;RolandBalter, Professeurà l’Uni versitéJosephFourieret Directeurdu projetSIRAC, qui

m’a fait l’honneurd’accepterdeprésiderle jury ;.ClaudeBétourné,Professeurà l’Uni versitéPaul Sabatier, et Bertil Folliot, Professeurà

l’Uni verstéPierreet Marie Curie,qui ont acceptéd’être rapporteursdema thèse,et par leurscritiquesconstructivesm’ont permisdel’améliorer;

DanielHagimont,Chargéderechercheà l’Institut NationaldeRechercheenInformatiqueet Automatique,qui a co–dirigécettethèse,pour l’inspiration, sesnombreuxconseilssur larechercheet nosnombreusesdiscussionsnocturnessur le balcon.L’occasiondetravailler avecDaniel et sousla direction de Sacha,m’a encouragéà poursuivre mesétudesdansun paysétrangeretdansunelanguequeje maîtriseàpeine;

L’équipequi a mis enplacela plate–formeArias : Alain, Elizabeth,Frederic,Jay, Maryan-nick, Olivier, Pascalet Thierry et l’ensembledespersonnesdu projet SIRAC pour la chaleu-reuseambiancequi a régnéedansnoslocaux.Jetiensen particulierà remerciermesvoisinsdebureauAlain, Ibaa,Maryannicket Olivier (Olaf) pour leur patience,leursconseilsdanslesmatièresscientifiquesetmétaphysiqueset lesnombreuxservicesqu’ils m’ont rendus;

Enfin,et nonlesmoindres,mafemmeLenaet mafille Michalapourleur patiencependantla préparationdecettethèse.

3

àLenaetMichala

5

Tabledesmatières

1 Intr oduction 171.1 Contextedu travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Objectifs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.4 Apportsdu travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.5 Organisationdudocument . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Sécuritédanslessystèmesrépartis 212.1 Introductionà la sécuritéinformatique . . . . . . . . . . . . . . . . . . . . . . 21

2.1.1 Terminologiedela sécurité. . . . . . . . . . . . . . . . . . . . . . . . 222.1.2 Objectifsdela sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1.3 Menacescontrela sécurité . . . . . . . . . . . . . . . . . . . . . . . . 242.1.4 Particularitésdessystèmesrépartis. . . . . . . . . . . . . . . . . . . . 25

2.2 Confidentialité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Confinement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.1 Canauxdestockage. . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3.2 Canauxdecommunicationlégitimes. . . . . . . . . . . . . . . . . . . 272.3.3 CanauxCachés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Authenticité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.5 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.7 Politiquesdesécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.7.1 Politiquesdesécuritéphysique. . . . . . . . . . . . . . . . . . . . . . 312.7.2 Politiquesdesécuritéadministrative . . . . . . . . . . . . . . . . . . . 312.7.3 Politiquesdesécuritélogique . . . . . . . . . . . . . . . . . . . . . . 322.7.4 Politiquesd’autorisation . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.8 Mécanismespourmettreenœuvrela sécurité . . . . . . . . . . . . . . . . . . 332.8.1 Authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.8.2 Autorisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.8.3 Communicationsûre . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.9 Évaluationdela sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.9.1 Le LivreOrange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.9.2 LesITSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.9.3 Lescritèrescommuns . . . . . . . . . . . . . . . . . . . . . . . . . . 362.9.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.10 Récapitulationetdiscussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7

8 TABLE DESMATIÈRES

3 Contrôle d’accès 413.1 Introductionaucontrôled’accès . . . . . . . . . . . . . . . . . . . . . . . . . 413.2 La structuredesécuritémilitaire . . . . . . . . . . . . . . . . . . . . . . . . . 433.3 Lesbesoinsdela sécuritédanslessystèmescivils . . . . . . . . . . . . . . . . 443.4 ModèledeBell etLaPadula. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4.1 Variationsdumodèle . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 Modèlediscrétionnaired’Unix . . . . . . . . . . . . . . . . . . . . . . . . . . 483.5.1 Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.5.2 Politiquedeprotectionpardéfaut . . . . . . . . . . . . . . . . . . . . 493.5.3 Mécanismesdeprotectiondiscrétionnaire. . . . . . . . . . . . . . . . 493.5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.6 Modèledecontrôled’accèsbasésurlesrôles . . . . . . . . . . . . . . . . . . 503.6.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.7 Modèledela murailledeChine. . . . . . . . . . . . . . . . . . . . . . . . . . 523.8 Mécanismesdecontrôled’accès . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.8.1 Matricedecontrôled’accès . . . . . . . . . . . . . . . . . . . . . . . 533.8.2 Listedecontrôled’accès . . . . . . . . . . . . . . . . . . . . . . . . . 533.8.3 Listedecapacités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.8.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.9 Particularitésdesapplicationsréparties. . . . . . . . . . . . . . . . . . . . . . 553.9.1 Suspicionmutuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.9.2 Contrôled’accèsdessujetsnon–identifiés. . . . . . . . . . . . . . . . 563.9.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56


4 Protectionpar capacités 594.1 Introductionhistoriqueauxsystèmesà capacités. . . . . . . . . . . . . . . . . 594.2 Définitionsdessystèmesàcapacités . . . . . . . . . . . . . . . . . . . . . . . 60

4.2.1 Capacitésmarquées. . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.2.2 Capacitésconfinées. . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.3 Capacitéschiffrées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2.4 DéfinitionoriginaleselonDennisetVanHorn . . . . . . . . . . . . . . 624.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3 Quelquesrésultatsthéoriques. . . . . . . . . . . . . . . . . . . . . . . . . . . 634.3.1 Un modèleformeldessystèmesàcapacités. . . . . . . . . . . . . . . 634.3.2 Unetaxinomiedessystèmesàcapacités. . . . . . . . . . . . . . . . . 644.3.3 Unenouvelle taxinomiedessystèmesàcapacitésrépartis. . . . . . . . 664.3.4 Capacitésaugmentées. . . . . . . . . . . . . . . . . . . . . . . . . . 704.3.5 ICAP — l’identité inclusedansla capacité . . . . . . . . . . . . . . . 714.3.6 Capacitésactives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.4 Systèmescentralisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724.4.1 CambridgeCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4.2 Hydra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.4.3 Discussiondessystèmescentralisés . . . . . . . . . . . . . . . . . . . 77

4.5 Systèmesrépartis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

TABLE DESMATIÈRES 9

4.5.1 Amoeba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.5.2 Mach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.6 Lesmémoiresvirtuellesrépartiesuniques . . . . . . . . . . . . . . . . . . . . 824.6.1 Opal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.6.2 Mungi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 854.6.3 Angel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90


5 Présentationgénéraled’Arias 935.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 935.2 Objectifs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.3 Vued’ensembled’Arias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.4 Modèled’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.5 Réalisationd’Arias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.6 Conditionsrequisespourla protectiond’Arias . . . . . . . . . . . . . . . . . . 995.7 Récapitulationetdiscussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6 Modèledeprotectionproposépour Arias 1016.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1016.2 Objectifs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.2.1 Généricitédumodèle. . . . . . . . . . . . . . . . . . . . . . . . . . . 1026.2.2 Facilitédeprogrammation. . . . . . . . . . . . . . . . . . . . . . . . 1026.2.3 Évolutivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1036.2.4 Réutilisabilitédescomposantslogiciels . . . . . . . . . . . . . . . . . 1036.2.5 Possibilitéd’intégrationdelogicielsconçusailleurs . . . . . . . . . . . 1046.2.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.3 Modèledescapacitéscachées. . . . . . . . . . . . . . . . . . . . . . . . . . . 1046.3.1 Vued’ensembledumodèle. . . . . . . . . . . . . . . . . . . . . . . . 1046.3.2 Domainesdeprotection . . . . . . . . . . . . . . . . . . . . . . . . . 1056.3.3 Changementdedomaine . . . . . . . . . . . . . . . . . . . . . . . . . 1076.3.4 Capacitésd’accès. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.3.5 Capacitésdechangementdedomaine . . . . . . . . . . . . . . . . . . 1086.3.6 Listesdecapacités . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.3.7 Interfacesdeprotection. . . . . . . . . . . . . . . . . . . . . . . . . . 1096.3.8 Changementdynamiquededomaine. . . . . . . . . . . . . . . . . . . 110

6.4 L’exempled’un serveurd’impression. . . . . . . . . . . . . . . . . . . . . . . 1116.5 Récapitulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7 Réalisationdu modèleproposé 1137.1 InteropérabilitéentreAriasetUnix . . . . . . . . . . . . . . . . . . . . . . . . 113

7.1.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.1.2 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1147.1.3 Domainesdeprotection . . . . . . . . . . . . . . . . . . . . . . . . . 1147.1.4 Modulesdecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

7.2 GestiondescapacitésdansArias . . . . . . . . . . . . . . . . . . . . . . . . . 115


7.2.1 Unepremièreétude. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.2.2 Stockagedescapacités. . . . . . . . . . . . . . . . . . . . . . . . . . 1177.2.3 C–listes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.2.4 Formatdescapacités. . . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.3 Créationdescapacités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1207.4 Délégationdescapacités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

7.4.1 Le droit dedélégation . . . . . . . . . . . . . . . . . . . . . . . . . . 1217.4.2 La politiquepardéfautd’Arias . . . . . . . . . . . . . . . . . . . . . . 121

7.5 Révocationdescapacités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1227.5.1 Révocationautomatique . . . . . . . . . . . . . . . . . . . . . . . . . 1227.5.2 Révocationexplicite . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

7.6 Créationd’un domainedeprotection . . . . . . . . . . . . . . . . . . . . . . . 1227.6.1 Créationd’un domainedeprotectioninitial . . . . . . . . . . . . . . . 1237.6.2 Créationd’un serveurdedomaine . . . . . . . . . . . . . . . . . . . . 124

7.7 Couplaged’un segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.8 Changementdedomaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

7.8.1 Interceptiondel’appel . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.8.2 Changementdedomaine: Vued’ensemble . . . . . . . . . . . . . . . 1287.8.3 Changementdedomaine: l’appeldeclient . . . . . . . . . . . . . . . 1297.8.4 Changementdedomaine: Cotéserveur . . . . . . . . . . . . . . . . . 1307.8.5 Changementdedomaine: retourauclient . . . . . . . . . . . . . . . . 1327.8.6 Surchargedesinterfacesdeprotection . . . . . . . . . . . . . . . . . . 1337.8.7 Changementdynamiquededomaine. . . . . . . . . . . . . . . . . . . 1347.8.8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.9 Interfacesdeprotection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1357.10 Récapitulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

8 Évaluation 1378.1 Objectif del’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1378.2 Généricitédumodèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

8.2.1 Réalisationd’unepolitiquedecontrôled’accèsmandataire. . . . . . . 1388.2.2 Réalisationd’unepolitiquedecontrôled’accèsdiscrétionnaire. . . . . 1418.2.3 Réalisationd’unepolitiquedecontrôled’accèsbasésurlesrôles . . . . 1428.2.4 Réalisationdela politiquedela murailledeChine . . . . . . . . . . . 1438.2.5 Récapitulationetdiscussion . . . . . . . . . . . . . . . . . . . . . . . 144

8.3 Facilitédeprogrammation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1458.3.1 Architectureslogicielles . . . . . . . . . . . . . . . . . . . . . . . . . 1458.3.2 Programmationparétapes . . . . . . . . . . . . . . . . . . . . . . . . 1468.3.3 RéalisationdeNIS surArias . . . . . . . . . . . . . . . . . . . . . . . 1468.3.4 Réalisationd’un éditeurcoopératifsurArias . . . . . . . . . . . . . . 1478.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

8.4 Évolutivité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1498.4.1 Evolutiondesdroitsd’accès . . . . . . . . . . . . . . . . . . . . . . . 1498.4.2 Évolutiondela sécuritéd’uneapplication . . . . . . . . . . . . . . . . 150

8.5 Réutilisabilitédescomposantslogiciels . . . . . . . . . . . . . . . . . . . . . 1508.6 Possibilitéd’intégrationdelogicielsconçusailleurs . . . . . . . . . . . . . . . 152

TABLE DESMATIÈRES 11

8.7 Sécuritédela réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1528.7.1 Interopérabilitéavecle systèmehôte . . . . . . . . . . . . . . . . . . . 1528.7.2 Communicationsurle réseau. . . . . . . . . . . . . . . . . . . . . . . 1528.7.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

8.8 Evaluationdeperformances. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1538.8.1 Coûtd’ensembledela protection . . . . . . . . . . . . . . . . . . . . 1538.8.2 Surcoûtsliésà l’implantation . . . . . . . . . . . . . . . . . . . . . . 154

8.9 Récapitulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

9 Conclusions 1579.1 Principauxrésultats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

9.1.1 Rappeldesobjectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . 1579.1.2 Satisfactiondesqualitésrequises. . . . . . . . . . . . . . . . . . . . . 1579.1.3 Apportsdu travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

9.2 Évaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1599.2.1 Expressiontransparentedela protection. . . . . . . . . . . . . . . . . 1599.2.2 Supportpourlesapplicationscoopératives. . . . . . . . . . . . . . . . 1599.2.3 Performances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

9.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1609.3.1 ApplicationdumodèledansArias . . . . . . . . . . . . . . . . . . . . 1609.3.2 Applicationdumodèledansd’autressystèmes . . . . . . . . . . . . . 1609.3.3 Applicationdela taxinomie . . . . . . . . . . . . . . . . . . . . . . . 1619.3.4 Preuve formelledela généricitédumodèle . . . . . . . . . . . . . . . 161

A Langagededéfinition desinterfacesdeprotection 163A.1 Rappeldesobjectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163A.2 Grammairedu langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164A.3 Changementdynamiquededomaine . . . . . . . . . . . . . . . . . . . . . . . 165A.4 Récapitulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

B Interface deprogrammation descapacités 167B.1 Administrationdusystème . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167B.2 Domainesdeprotection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167B.3 C–listes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

C NIS : Network Information Service 169C.1 DescriptiongénéraleduNIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 169C.2 La mécaniqueduNIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169C.3 AvantagesduNIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170C.4 Problèmeslié auNIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Tabledesfigures

2.1 Lespérimètresdela sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2 La différenceentreunsystèmerépartiet dessystèmescoopérants. . . . . . . . 252.3 Éliminationdela contaminationdesinformationsintègresparlesinformations

moinsintègres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1 Le modèledebaseducontrôled’accès. . . . . . . . . . . . . . . . . . . . . . 413.2 La matricedecontrôled’accès . . . . . . . . . . . . . . . . . . . . . . . . . . 423.3 Le modèledela murailledeChine . . . . . . . . . . . . . . . . . . . . . . . . 523.4 Lesdifférentesclassesd’environnements. . . . . . . . . . . . . . . . . . . . . 55

4.1 Le formatd’unecapacitémarquée . . . . . . . . . . . . . . . . . . . . . . . . 604.2 Formatd’unecapacitéconfinée. . . . . . . . . . . . . . . . . . . . . . . . . . 614.3 Le formatd’unecapacitéchiffrée . . . . . . . . . . . . . . . . . . . . . . . . . 614.4 Un systèmesimpleàcapacités . . . . . . . . . . . . . . . . . . . . . . . . . . 634.5 Contrôled’accèsmandataire . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.6 Le modèledescapacitésactives . . . . . . . . . . . . . . . . . . . . . . . . . 724.7 Le formatdescapacitésdeCAP . . . . . . . . . . . . . . . . . . . . . . . . . 734.8 Le formatsimplifiédescapacitésd’Hydra . . . . . . . . . . . . . . . . . . . . 754.9 Le formatd’unecapacitéd’Amoeba . . . . . . . . . . . . . . . . . . . . . . . 784.10 Le formatdescapacitésd’Opal . . . . . . . . . . . . . . . . . . . . . . . . . . 834.11 Le changementdedomainedansOpal . . . . . . . . . . . . . . . . . . . . . . 844.12 L’arbredescapacitésdeMungi . . . . . . . . . . . . . . . . . . . . . . . . . . 854.13 La hiérarchiedescapacitésdérivées . . . . . . . . . . . . . . . . . . . . . . . 864.14 Le schémadecontrôled’accèsd’Angel . . . . . . . . . . . . . . . . . . . . . 89

5.1 Vued’ensembled’Arias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 955.2 L’espaced’adressageArias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 965.3 Vueglobaled’uneexécutionArias. . . . . . . . . . . . . . . . . . . . . . . . . 975.4 L’architecturelogicielled’Arias . . . . . . . . . . . . . . . . . . . . . . . . . 98

6.1 Applicationsd’Arias protégées. . . . . . . . . . . . . . . . . . . . . . . . . . 1056.2 Lesdomainesdeprotection. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1066.3 La structureduchangementdedomaine . . . . . . . . . . . . . . . . . . . . . 1076.4 L’exempled’un correcteurd’orthographe . . . . . . . . . . . . . . . . . . . . 1116.5 Serveurd’impression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7.1 Formatd’unecapacitéd’accès . . . . . . . . . . . . . . . . . . . . . . . . . . 1187.2 Formatd’unecapacitédechangementdedomaine. . . . . . . . . . . . . . . . 119

13

14 TABLE DESFIGURES

7.3 Formatd’unecapacitéderedirection . . . . . . . . . . . . . . . . . . . . . . . 1197.4 Formatd’unecapacitésuruneC–liste . . . . . . . . . . . . . . . . . . . . . . 1197.5 Domaineinitial et lesdomainesapplicatifs. . . . . . . . . . . . . . . . . . . . 1237.6 Créationd’un serveurdedomaine . . . . . . . . . . . . . . . . . . . . . . . . 1247.7 Vérificationdescapacités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.8 Changementdedomaineparcouplaged’un talon . . . . . . . . . . . . . . . . 1287.9 Changementdedomaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.10 Changementdedomaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1317.11 Changementdedomaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

8.1 Contrôled’accèsmandataire . . . . . . . . . . . . . . . . . . . . . . . . . . . 1398.2 L’arborescencederôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1438.4 L’architectureduserviceNIS surArias . . . . . . . . . . . . . . . . . . . . . . 1478.3 FormatdesentréespasswddeNIS . . . . . . . . . . . . . . . . . . . . . . . . 1478.5 L’éditeurcooperatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1488.6 Interfacesdeprotectiondel’éditeurcoopératif. . . . . . . . . . . . . . . . . . 1498.7 L’interfaceducode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1508.8 L’interfaced’un servicedenoms . . . . . . . . . . . . . . . . . . . . . . . . . 1518.9 L’interfaced’un serveurdeprotection . . . . . . . . . . . . . . . . . . . . . . 151

Liste destableaux

2.1 Classificationdu livreorange. . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2 Résumédesparticularitésdessystèmesrépartis . . . . . . . . . . . . . . . . . 39

3.1 Classificationmilitaire desinformations . . . . . . . . . . . . . . . . . . . . . 43

4.1 Lesdroitsgénériquesd’un objetHydra . . . . . . . . . . . . . . . . . . . . . . 764.2 Classificationdessystèmesabordésdanscechapitre. . . . . . . . . . . . . . . 91

8.1 Coûtd’ensembledela protection. . . . . . . . . . . . . . . . . . . . . . . . . 1538.2 Coûtdescomposantsduchangementdedomaine . . . . . . . . . . . . . . . . 1548.3 Coûtdedifférentsmécanismesd’appelinter-domaine . . . . . . . . . . . . . . 154

A.1 La grammairedu langagededéfinitiondesinterfacesdeprotection . . . . . . . 164A.2 Modificationsnécessairespourle supportduchangementdynamiquededomaine165

15

16 LISTE DESTABLEAUX

Chapitre1

Intr oduction

1.1 Contextedu travail

Le travail présentédanscedocumentaétéeffectuédansle cadreduprojetSystèmesInformatiquesRépartispourApplicationsCoopératives(SIRAC1) [Balter95].L’objectifprincipalduprojetestla conceptionet la réalisationdesoutilset supportssystèmespourlaconstructiondesapplicationsréparties.Enparticulier, l’étudeprésentéeici sesituedansle cadredela conceptionetdela réalisationd’uneplate–formeoffrantunservicedegestiondesdonnéespartagées,complexes,structuréesetà longueduréedevie.

1.2 Moti vations

Lessystèmesrépartispermettentauxutilisateursdepartagerl’ensembledesressourcesdusystème,cequi nécessiteunegestionglobaledecesressources.Pendantlesannées1980,larecherchedanscedomaines’estconcentréesurla gestionglobaledesressourceschèrescommelesdisquesdurs(lessystèmesNFS[Sandberg85,Sun89] ouAFS[Satyanarayanan85, Spector89]) ou l’unité centrale(la répartitiondechargeaétéétudiéedansle cadredessystèmesCondor[Litzkow87], Sprite[Douglis91] etUtopia[Zhou91] ouparsimulation[Ferrari86, Eager88,Kunz91]).L’arrivéedesréseauxrapidesetdesarchitectures64bitsaprovoquéun intérêtpourla gestionglobaledela mémoirevirtuelle.Lesréseauxrapides,commeATM [Dutton95],Myrinet [Boden95]etGigabitEthernet[IEEE98]ou lesinterfacesréseauxqui permettentdeconsulterla mémoireàdistancesansinterromprele processeurcommeMemoryChannel[Fillo97] etSCI [IEEE92,Omang98], réduisentle tempsdecommunicationentremachineset rendentainsila paginationàdistancefaisable.Aveccestechnologies,letempsd’accèsàunepageenmémoired’unemachinedistantedevientpluséconomiquequel’accèsaudisquelocal [Feeley95,Koch98]. Outrecetteaugmentationdevitessedesréseaux,lagestiond’un espacevirtuel uniquedansunsystèmerépartiestrenduepossibleparlesarchitecturesà adressageétendu(64bits)où lesadressesvirtuellesnesontplusuneressourcelimitéequi doit êtreéconomisée.Un calculsimplefait parBartoli et al. [Bartoli93] montreque

1SIRAC estunprojetcommunentrel’Uni versitéJosephFourier, l’Institut NationalPolytechniquedeGrenobleet l’Institut NationaldeRechercheenInformatiqueetAutomatique

17

18 CHAPITRE1. INTRODUCTION

dansle casoùdix machinesallouent10Go/minutechacune,unespaced’adressageà64bitsnes’épuisepasavant300ans.Cecalculindiquequ’unespaced’adressageà64bitssuffiralargementpourunsystèmerépartiavecdesbesoinsmodérésd’allocationdemémoire(unsystèmeavecpeudemachinesouun faibletauxdeallocationet fragmentationdela mémoire).Il nedit cependantriensurl’adéquationdecettetechnologiepourunsystèmeà trèsgrandeéchelle.Unesimulationbaséesurlestracesd’allocationdemémoiredesapplicationsréelles[Kotz94] suggèrequelesarchitecturesà64bitssuffiront si le systèmed’exploitationarriveà limiter la fragmentationetà récupérerl’espaceallouéauxstructuresd’exécutionetauxvariablestemporaires.Cesdeuxévolutionstechniquesévoquéesci–dessus(arrivéedesréseauxrapidesetdesprocesseursàespaced’adressageétendu)adonnénaissanceàunenouvellegénérationdesystèmesrépartis: lesmémoiresvirtuellesrépartiesuniques.La conceptiond’un systèmerépartifondésurunemémoirevirtuelle répartieunique(MVRU)etpersistantea étéétudiéedansle cadredesystèmescommeAngel [Murray93a,Murray93b],Mungi [Heiser93,Heiser94, Heiser98]etOpal[Koldinger92, Chase92,Chase93, Chase95].Lesaspectsdedésignationetd’accessibilitéconstituentunedifférenceimportanteentrecetypedesystèmeet lessystèmesd’exploitationtraditionnels.Dansunsystèmetraditionnel,l’espaced’adressageestpropreauprocessuset le droit d’accèsàunobjetprotégéaétévérifiéavantquel’objet puisseêtredésignéenmémoireprincipale.Autrementdit, la capacitédedésignerunobjetenmémoireprincipaleimpliquele droit d’accéderà l’objet. DansuneMVRU, touslesobjetssontdésignésparuneadressevirtuelleuniquedanstouslesprocessusetsurtouteslesmachines.La capacitédedésignerunobjetparadressevirtuellenepeutplusavoir la mêmeimplication; il fautdoncséparerl’adressageet la gestiondesdroitsd’accès.Chaqueprocessusdoit avoir le droit d’accéderàcertainesrégionsdesonespaced’adressage(cellesqui correspondentaucodeetauxdonnéesduprocessus),maisnonàcellesqui sontutiliséesparlesautresprocessus.Le systèmedonneainsiàchaqueprocessusunefenêtresurlamémoirevirtuelleglobale; cesfenêtrespeuventêtredifférentesd’un processusà l’autre.Ceciimpliqueuncontrôled’accèsauniveaudela mémoireprincipale.L’étuded’un mécanismedecontrôled’accèsqui réaliseunetelleséparationentrel’adressageet le droit d’accèsestle sujetdecettethèse.

1.3 Objectifs

Le supportexpérimentaldecetravail aétéle systèmeArias,unsystèmedegestiondedonnéespersistanteset réparties,réalisécommeunemémoirevirtuelle répartieuniquesurunréseaudemachines.L’objectif denotretravail estdefournir unmécanismedebasequi permetla réalisationdeplusieurspolitiquesdeprotectionsurArias.Cemécanismedoit séparerla définitiondelaprotectionet le coded’applicationpourlesraisonssuivantes:

Facilité deprogrammation. Le programmeurs’occupeuniquementdel’algorithmiquedel’application.La spécificationdela protectionestfaiteparunadministrateursystèmeouunresponsabledela sécurité.

Réutilisation descomposantslogiciels.Lesmêmescomposantslogicielspeuventêtreutilisésdansdescontextesetdesapplicationsdifférents.

1.4. APPORTS DU TRAVAIL 19

Évolution de la protection.La spécificationdela protectiond’uneapplicationpeutchangerpendantla duréedevie del’application,sansrecompilationouré-éditiondeliens.

Protectionde logicielsconçusailleurs. Leslogicielsconçusailleurspeuventêtreencapsulésafindeprotégerl’environnementlocal.

Généricitédu mécanisme.La conceptiondumécanismedoit êtregénériquepourpermettrela réalisationdesdifférentespolitiquesdeprotectionrequisesparlesapplications.La généricitéestunobjectifgénérald’Arias.

1.4 Apports du travail

Lesapportsdecettethèsesontlessuivants:

1. Uneétudedesmodèlesdecontrôled’accèset leursréalisationsdanslessystèmesrépartisexistants.

2. La définitiond’unetaxinomiepourfaciliter la descriptiondessystèmesàcapacitésrépartis.

3. La propositiond’un modèleétendudumodèleàcapacitéscachées.

4. Uneanalyse(informelle)decemodèle,pourvérifierquecemodèlepermetla réalisationdespolitiquesdeprotectionexistantes.

5. La réalisationdecemodèledansla mémoirevirtuelle répartieuniqueArias.

6. Uneévaluationdumodèleproposé.

1.5 Organisationdu document

Cettethèseestorganiséeentroispartiesprincipales: la premièrepartie(chapitres2, 3 et4)passeenrevuelesproblèmesliés à la sécuritédanslessystèmesinformatisésengénéralet lessystèmesrépartisenparticulier, ainsiquelesmodèlesetmécanismesproposéspourrésoudrecesproblèmes.La deuxièmepartie(chapitres5 et6 décritunmodèledecontrôled’accèsproposépourleslogicielscoopératifset saréalisationdansunsystèmerépartibasésurunemémoirevirtuelle répartieunique.La troisièmepartie(chapitres8 et9) présenteunepremièreévaluationdecemodèleet lesconclusionsgénéralesdecettethèse.

20 CHAPITRE1. INTRODUCTION

Chapitre2

Sécuritédanslessystèmesrépartis

La sécuritédessystèmesinformatiquesévoquenormalementl’imaged’un jeunepiratetrèsdouéeninformatiquequi, toutseuldanssachambre,essaiedepénétrerlesmécanismesdesécuritéd’un systèmedistantpourvoleroudétruiredesinformationsstockéesdansle système.Cetteimageestlargementévoquéeparlesromansde“sciencefiction” qui introduisaientle“Cyberspace”et la “Matrice” commemétaphorespourl’Internet [Gibson84] et lesfilmspopulairesdesciencefiction comme“Wargames”[Badham83]ou“Terminator2” [Cameron91].DeuxexemplesréelsdecetypedepiratessontlesespionscapturésenAllemagneaumilieudesannées19801 et le groupedepirates“Global Hell (gH)” qui enmai1999forçait la MaisonBlancheet la policefédéraleaméricaine(le FBI) à fermerleursiteInternet[Meeks99a,Meeks99b].Lesexploitsdecespiratessontlargementdiffusésparla presse.Decefait, il estgénéralementadmisquel’objectif dela sécuritéestd’empêchercespiratesdepénétrerle système,parexempleeninstallantdespare–feu[Soinne98,CheckPoint99, AXENT99].Enréalité,lespiratesnesontpasresponsablesdeplusde30%despertesduesauxdéfaillancesdela sécurité[Power99].La plupartdesdéfaillancesdesécuritésontduesauxattaquesvenantdel’intérieur, parexemplepardesemployésinsatisfaits.Lesattaquantsinternessontnormalementplusdifficilesàdécouvriretplusdifficilesàpoursuivreenjustice.Danscechapitre,nousétudionsla sécuritéinformatiqueetenparticulierla sécuritédanslessystèmesrépartis.D’abord,nousdonnonsuneintroductiontrèsgénérale,puisnousétudionssesobjectifset sesmenaces.Enfin,nousvoyonsplusendétaillesdispositifspossiblespourassurerla sécuritéet l’évaluationdela sécuritéd’un système.

2.1 Intr oduction à la sécuritéinformatique

La définitionla plusgénéraledela sécuritéinformatiqueestd’assurerle bonfonctionnementd’un systèmeinformatique.Toutedéfaillanced’un systèmepeutêtreattribuéeà unefaille dansla sécurité.Du pointdevued’un utilisateurqui n’arrivepasà travailler ouqui aperdusesfichiers,le problèmerestele mêmequ’il soit causéparunpirateouparundéfautdesauvegarde.

1La découverteet la poursuitedecespiratessontdécritesdans“Le nid ducoucou”parClifford Stoll [Stoll89].

21

22 CHAPITRE2. SÉCURITÉDANS LESSYSTÈMESRÉPARTIS

Le nombredesujetsqui doiventêtreétudiéspourassurerla sécuritéd’un systèmeinformatiqueesttrèsgrand.La sécuriténecouvrepasuniquementle contrôled’accèsauxdonnées,maisaussiungrandnombred’aspectsmoinsprestigieuxcommeparexemple: déchiqueterlesdocumentssensiblesavantlesmettreà la poubelle,stocker lessauvegardeshorssitepourprévenir lesincendies,installerdesonduleursdecourantélectrique,construiredesbâtimentsanti–sismiques,concevoir deslogicielsfiables(spécificationformelleet vérificationdelavaliditéducode).Dansle cadredecettethèsenousnousintéressonsprincipalementà la protectiondel’information. Lesproblèmesdesécuritéphysiqued’uneentrepriseet l’installationet lagestiondesmachinessurunsitesonttraitéspardesagencedugouvernement.Un exposédecesproblèmesetdesrecommandationspourlesrésoudreaétépubliéparLe ServiceCentraldela SécuritédesSystèmesd’Information(SCSSI)[SCSSI91a, SCSSI91b, SCSSI93]. Uneautresourced’informationestle “IT–Grundschutzhandbuch” publiéparle “BundesamtfürSicherheitin derInformationstechnik”[BSI97] qui traitecesproblèmeset lesdispositifsadéquatspourlesrésoudreendétail.

2.1.1 Terminologiede la sécurité

La sécuritédanslessystèmesinformatiquespossèdemaintenantsapropreterminologiebienétablie.

Limite du systèmeet périmètre desécurité. Le systèmen’estnormalementpasuneentitébiendéfinie,il comprendl’ensembledesressources(ordinateurset réseaux)qui sontà ladispositiondesutilisateursoudesapplications.La limite dusystèmedésignel’ensembledesressourcessurlesquellesl’administrateurexigeunminimumdecontrôle.Cellesqui sontfondamentalesà la sécuritédoiventêtregéréesuniquementparl’administrateurderrièrelepérimètredesécurité.L’administrateurnedoit jamaisabandonnerle contrôled’uneressourcederrièrecepérimètredesécurité.

Moniteur de référence. Le moniteurderéférenceestunmédiateurincontournabledanstouteslesrelationsentresujetsetobjets(cf. Protection).Le moniteurderéférenceestresponsabledel’autorisationdel’accèsà unobjetparunsujet.

Protection. La protection2 consisteàcontrôlerl’accèsauxentitéspassives(lesdonnéesoulesressourcesconsommablesdusystème— réseau,tempssurl’unité centrale,etc.)parlesentitésactives(lesutilisateursou lesprocessusdusystème).Lesentitéspassivessontnormalementappeléeslesobjetset lesentitésactivessontappeléeslessujetsou lesprincipaux.3 Remarquonsqu’unsujetpeutaussijouerle rôled’un objet,parexemplequandunprocessusenvoieunsignal/message/événementàunautreprocessus.

Sous–systèmedesécurité. Lessystèmesinformatiquessecomposentnormalementd’uncertainnombredesous–systèmes.Certainsdecessystèmesn’apportentrienà la sécurité,par

2Dansla littératurede la sécurité,les termesautorisation,protectionet contrôled’accèssontpresquesyno-nymes,nousnefaisonspasdedistinctionentrecestermesici.

3Nousnefaisonspasdedistinctionentresujetsetprincipauxdanscettethèse.

2.1. INTRODUCTIONÀ LA SÉCURITÉINFORMATIQUE 23

contred’autresmettentenœuvrela sécuritédirectementouoffrentdesservicespourla créationd’applicationssûres.L’ensembledessous–systèmessurlesquelsla sécuritéd’uneapplicationsûrereposeestnomméle sous–systèmedesécurité(“TrustedComputingBase”ou“TCB”). Lesous–systèmedesécuritéestnormalementunsous–ensembledusystèmed’exploitation.La relationentrela limite dusystème,le périmètredesécurité,le sous–systèmedesécuritéetle moniteurderéférenceestillustréedansla figure2.14.

sujets

Limite du système

Périmètre de la sécurité

Système d’exploitation

Sous-système de sécurité

Moniteur de référence

Utilisateurs, stations de travail, l’Internet, ...

objets

services

serveurs

programmes des utilisateurs

FIG. 2.1:Lespérimètresdela sécurité

La figuremontrecommentl’accèsauxobjetspardessujetstraverselesdifférentspérimètresdusystème.Le noyaud’un systèmesûrestle moniteurderéférencequi contrôlel’accèsà touteslesressourcesdusystème.Le systèmed’exploitationfournit unensembledeprimitivesqui permetderéaliserdesserviceset lesserveurs.Le sous–ensembledecesprimitivesqui sontvitalespourla sécuritédusystèmes’appellele sous–systèmedesécurité.Lesprimitivesmisesenœuvreparle systèmed’exploitationpermettentderéaliserlesserveursqui gèrentlesobjets.Lesystèmed’exploitationet l’ensembledesserveursvitauxpourla sécuritéconstituela périmètredela sécurité.Lesentitésderrièrecepérimètrenesontpasforcémentsurla mêmemachine,maisellesdoiventimpérativementêtresousle contrôledel’administrateurdusystème.Lalimite dusystèmedéfinit la frontièreentrelesentitésmanipuléesdirectementparle systèmeetle mondeextérieur.

2.1.2 Objectifs de la sécurité

Normalementla protectionestdécritedanslestermessuivants:

La confidentialité desinformations.La confidentialitégarantitquel’information danslesystèmeestuniquementaccessibleauxutilisateursautorisés.Desmécanismesdoiventêtreprésentsgarantissantcetteconfidentialitéentreutilisateursetentreutilisateursetsystème.

4Cettefigureestuneadaptationpourlessystèmesrépartisd’unefiguretrouvéedansle livre“Building aSecureComputerSystem”parMorrie Gasser[Gasser88].


Le bon usage(“privacy”) desinformations.Le bonusagegarantitquelesinformationssontutiliséesuniquementpourle but danslequelellessontdonnées.Cettenotionressembleausecretprofessionneldesavocatsoumédecins,où l’information obtenuenepeutpasêtredivulguéeàquelqu’unqui n’a pasbesoindela connaître.La différenceentrela confidentialitéet le bonusageestquela premières’appliquedirectementàl’information et l’autres’appliqueà l’utilisation del’information.

L’authenticité desinformations.L’authenticitégarantitqu’unsujet(utilisateur,processus,système,etc.)estceluiqu’il prétendêtreetquelesinformationsreçuesdecesujetsontidentiquesàcellesfournies.

L’intégrité desdonnées.L’intégritéévitela corruptionou la destructiondesdonnéestraitéesparle système.Il fautd’abordempêcherdesutilisateursmalveillantsd’accéderauxdonnéesnonautorisées(assurerla confidentialitéet l’isolation desinformations)maiségalementassurerquelesdonnéessontaccédéesdefaçoncohérente(parexempleavecunaccèstransactionnel).

La disponibilité desressourcesdusystème.La disponibilitéestla garantiequelesdonnéeset lesservicesdusystèmesontdisponiblesauxutilisateursautorisés.Il fautpourcelaempêcherunutilisateurmalveillantd’arrêteroudebloquerunservice(“Denial ofServiceattacks”).

Chacundecesobjectifsestexaminéplusendétailplusloin.

2.1.3 Menacescontre la sécurité

Afin depouvoir analyserlesdispositifsà mettreenœuvrepourassurerla sécurité,il fautd’abordanalyserlesmenaceset lesdifférentsmoyensd’attaquerunsystèmeinformatique5.

Interceptiondesdonnées.L’attaquantinterceptelesinformationssecrètessansrienmodifier(celas’appellequelquefois l’écoutepassive).Il a troispossibilités: lire lesdonnéesstockéesenmémoiresecondaire(surdisqueoubande),lire lesdonnéestransmisessurle réseauouanalyserle rayonnementélectromagnétiquedespériphériquestelsquel’écranou le clavier.

Modification desdonnées.L’attaquantsupprimeoumodifielesdonnéesstockéesenmémoiresecondaireou transmisessurle réseau.

Fabrication desdonnées.L’attaquantfabriquedesdonnéeset lespasseausystèmecommesi ellesétaientcrééesparquelqu’und’autre.La fabricationmenaceprincipalementlesapplicationsqui communiquentà traversun réseau(cf. 2.1.4),maisellemenaceaussilesapplicationsqui tournentsurunseulsite.

Divulgation desinformations.L’attaquantpeutavoir uncomplice(unutilisateurlégitime)qui divulguel’information. La préventiondela divulgationestunproblèmetrèsdifficile etcorrespondà la garantiedubonusage.Ceproblèmeestconnudanslalittératuresousle nomduproblèmedeconfinement(cf. 2.3).

Déductionpar inférence. L’attaquantcombinelesinformationsobtenuespardifférentsmoyens(légitimesou illégitimes)afind’inférerdenouvellesinformations.Parexemplesi onneconnaîtpasla formule � duCocaCola,maisquel’on connaîttouteslesmatièresachetéesparl’usinepourle produire,la compositionde � peutêtreinférée.

5Lesmenaceset lesattaqueslistésici sontunsous–ensembledeceuxidentifiésparla SCSSI[SCSSI94].

2.1. INTRODUCTIONÀ LA SÉCURITÉINFORMATIQUE 25

Mascaradeoudéguisement.L’attaquant(ouunprogrammequi travaille pourlui) essaied’agir avecl’identité (et lesdroitsd’accès)dequelqu’unautre.Le but peutêtred’intercepter, demodifieroudefabriquerdesdonnéesstockéessurle site.Un casdemascaradeparunprogrammeestgénéralementappeléuncheval deTroie6.

Lesdifférentsparamètresdesécuritésonttraitésplusloin avecuneanalysedesmenacesentermesdesattaquesdécritesci–dessus.

2.1.4 Particularités dessystèmesrépartis

Uneparticularitédessystèmesrépartisestqu’il n’existepastoujoursunsous–systèmedesécuritécommunsurtouslessites.Un systèmerépartipeutêtrestructurésoit commeunensemblederessourcesgéréesparunsystèmed’exploitationréparti,soit commeunensembledesystèmesindividuelsqui coopèrentpoursupporterlesapplicationsréparties.Danslessystèmesd’exploitationrépartis,le sous–systèmedesécuritéfait partiedusystèmed’exploitation.Alors lesinformationssurlessujetset leursdroitsd’accèsauxobjetssontrépartisetaccessiblessurtouslessites.Ceciapourconséquencequele droit d’accèsàunobjetpeutêtrevérifié localement,sansconsulterle sitequi stocke l’objet.Lessystèmesd’exploitationcoopérantscoordonnentlesidentitésdessujetsetdesobjets,maisils gèrentchacunleurspropresinformationsconcernantlesdroitsd’accès.Decefait, lesobjetssontaccessiblespartout,maisla vérificationdudroit d’accèssefait toujourssurle siteoùl’objet setrouvephysiquement.La différenceentrecesdeuxtypesdesystèmesestillustréesurla figure2.2.

Site 2 Site 3Site 1

Système d’exploitation réparti

Sous-système de sécurité réparti

Applications réparties

i) Systèmed’exploitationréparti

Site 3Site 1

Applications réparties

Sous-systèmes de sécurité coopérants

Systèmes d’exploitation coopérants

Site 2

ii) Systèmescoopérants

FIG. 2.2:La différenceentreunsystèmerépartietdessystèmescoopérants

6Un cheval de Troie peutégalementêtreun programmequi parait innocent,mais introduit un problèmedesécuritédansle système.


La figuremontrelesrelationsentrelesapplications,lessystèmesd’exploitationet lessous–systèmesdesécuritédanslessystèmesrépartis2.2 i) et lessystèmescoopérants2.2ii).Pourpouvoir réaliserunsystèmed’exploitationrépartisûr, il fautquel’ensembledessitespuisseêtreconsidérécommeuneunitéblindée,c’est–à–direquel’accèsdirectauréseausoitimpossibleetquedenouvellesmachinesnepuissentpasêtreintroduitesarbitrairementdanslesystème.L’avantaged’un tel systèmeestla possibilitédemettreenvigueurunepolitiquedeprotectionglobale.Danslessystèmescoopérantsla décisiond’autoriserl’accèsàunobjetparunsujetestpriselocalementsurla machinequi gèrel’objet. Alors cesdécisionspeuventdifférerselonlessites.Parexemplel’utilisateur root sousUnix peutmodifiertouslesfichiersstockéssurlesdisqueslocaux,maisil n’a paslesdroitsspéciauxpourlesdisquesd’un autresite.Un autreproblèmecommundanslesdeuxtypesdesystèmesrépartisestle contrôled’accèsauréseau.Si l’attaquantarriveàavoir unaccèsdirectauréseau,il peutlire, modifieret fabriquerlesinformationsqui passentsurle réseau.Alors, il fauttoujourss’assurerquel’interlocuteurdistantestbienceluiauquelonpense.Nousreviendronsauxsolutionsàceproblèmedanslessections2.8.1et2.8.3.

2.2 Confidentialité

La garantiedela confidentialité(“secrecy”) desinformationsstockéessurunsystèmeinformatiqueestsouventconsidéréecommela plusimportantequalitéd’un systèmesûr. Lesutilisateursdusystèmedoiventavoir l’assurancequele systèmenedivulguepasleursinformationssensibles(secretsindustriels,dossiersmédicaux,secretsd’État)àdespersonnesnonautorisées.La confidentialitéestla premièrepréoccupationpouruneinstallationmilitaire. Unegrandepartiedela recherchesurla miseenœuvredela confidentialitéaétéfinancéepardesprojetsmilitairesetestdestinéeàdesinstallationsmilitaires.C’estpourquoicetterechercheutilisesouventunmodèled’accèsauxinformationssemblableàceluiquel’on trouvedansle mondemilitaire.Afin d’assurerla confidentialité,le systèmedoit disposerd’un mécanismequi permetd’établirl’identité detouslesagents.

2.3 Confinement

Le confinementconsisteàéviterla divulgationvolontaired’information.Ceproblèmeestdonccomplémentaireà la confidentialitépourassurerle bonusagedesinformations.Le problèmeàétédéfiniparLampson[Lampson73] comme“le problèmedeconfinerunprogrammependantsonexécutionpourqu’il arriveuniquementà transmettredel’informationauprogrammequi l’a lancé”.Alors le confinementgarantitqu’unsujetn’arrivepasàdivulguerle contenudesobjetsauxquelsil aaccèsà quelqu’unqui n’a pasle droit d’y accéder.Il existetroiscanauxpossiblespourla divulgationdel’information. Cescanauxsont:

– Lescanauxdestockagequi permettentdetransférerdel’information à traversdesobjetsqui sontécritsentoutelégalitéd’un cotéet lus entoutelégalitédel’autre,parexempleunfichier;

2.3. CONFINEMENT 27

– Lescanauxdecommunicationlégitimesqui permettentà unprocessusd’envoyerunmessageàunautreprocessusenutilisantlesmécanismesdecommunicationentreprocessus(“IPC”), parexempleunappelRPC;

– Lescanauxcachésqui permettentla communicationentreprocessusendehorsdemécanismesnormaux.

Si onarriveàmontrerqu’unsystèmen’a pasdecanauxcachés,c’estqu’il n’estpasvulnérableauxchevauxdeTroie.Nousallonsexaminerlescanauxcachésplusendétaildansla suite.

2.3.1 Canauxdestockage

La divulgationà traversdesobjetspersistantsnécessitequ’il y ait uneintersectionnonvideentrel’ensembled’objetsmodifiablesparceluiqui divulgueet lesobjetslisiblesparceluiquisouhaiteprofiterdela divulgation.Cecis’appliqueaussiauxautresobjetsqui sontvisiblesà traversle systèmedepersistanceparexemplelesfichierstemporaires(dans/tmp ) dansunsystèmeUnix. Alors il nes’agit pasuniquementdecontrôlerl’accèsauxobjetsexistants,maisil fautaussicontrôlerlesobjetspersistantscréésparle programmeconfiné.Lesobjetscréésparunprogrammeconfinénedoiventpasêtrevisiblesà l’extérieurdela zonedeconfinement.Un grandnombredemécanismesdifférentsdeconfinementpourlescanauxdestockageaétéproposédansla littérature[Wahbe93,Goldberg96, Jensen98d].

2.3.2 Canauxdecommunication légitimes

Pouréviterla divulgationparlescanauxdecommunicationlégitimes,le systèmedoit vérifiertoutmessageenvoyéparunprogrammeconfiné.La politiquedubacà sable(“sandbox”)réaliséeparle gestionnairedesécuritépardéfautdansla machinevirtuelledeJava(“JavaVirtual Machine”ou “JVM”) [McGraw99] réaliseunetellepolitique.Lesapplets(petitsprogrammesmobilesécritsenJava)nesontautoriséesqu’àouvrir uneconnexion surle réseauaveclesserveursdepuislesquelsellesontététéléchargées.L’idéeestd’éviterqu’uncheval deTroiestockésurunserveurrespectablen’arriveàenvoyerdel’information à unpirateen–dehors.La politiquenegarantitpasle confinementtotal carl’appletarrive toujoursàcommuniqueravecle serveurdepuislequelellea ététéléchargée,maissi onn’a pasconfiancedansceserveur, il valaitmieuxnepastéléchargerl’applet.

2.3.3 CanauxCachés

Il existetrois typesdecanauxcachésdifférents: canauxtemporels,canauxd’inférenceetcanauxdefabrication[SCSSI94] .

Canaux temporels

Lescanauxtemporelspermettentàunprocessusdetransmettreunmessageàunautreprocessusenmodulantla consommationdesesressourcessystèmesafinquelesvariationsdestempsderéponsepuissentêtreobservées.Un exempled’un canaltemporelestunprocessusqui s’arrangepourquela chargedusystèmesoit élevée,parexemplesupérieurà15,quandil


souhaited’envoyer le bit 1 et inférieurequandil souhaited’envoyer le bit 0. Il peutainsicommuniqueruneinformationàunobservateurextérieur.

Canauxd’infér ence

Lescanauxd’inférence7 permettentàunprocessusdedéduiredel’information à laquelleil n’apasnormalementaccès.Le messagedivulguésecomposedel’intersectiondel’ensembledesinformationsnonclasséesenvoyéesentrelesdeuxinterlocuteurs.Alors il nes’agitplusuniquementdecontrôlerle fluxdesinformationsconfidentielles,maistouslesflux d’informationspeuventêtreutiliséscommecanauxcachés.

Canauxde fabrication

Lescanauxditsde“f abrication”permettentdecréerdel’information enformantdesagrégatsqui nepeuventêtreobtenusdirectement.

Solution au confinement

Lampsonproposeunesolutionauproblèmeduconfinement.Il fautd’abordquele programmeconfinésoit sansmémoirec’est–à–direqu’il nelaissepasdetracesentreplusieursexécutions.Dansunsystèmesansmémoirele confinementpeutêtregarantitparla règlesuivante:

Isolation totale duprogramme.Le programmeconfinénedoit paspouvoir appelerunautreprogramme.

L’isolation totalen’estpastoujourspratique; la conditionpeutêtreallégéesi le confinementesttransitif.Alors la règledeconfinementallégépeutêtredéfinie:

Transitivité de l’isolation duprogramme.Si unprogrammeconfinéappelleunautreprogrammedanslequelonnepeutpasavoir confiance,le programmeappelédoit êtreégalementconfiné.

Pourquecetterèglesuffiseàéviterla divulgation,il fautbienévidemmentd’abordmaîtriserlescanauxdestockageet lescanauxdecommunicationlégitime,parexempleparfiltrage(“masking”)detouteslesentrées/sortiesduprogrammeconfiné.Pouréviterlescanauxcachés,il fautquele systèmemetteenplacedesmesurescoercitives(“enforcement”)afind’assurerquele comportementduprogrammecorrespondàunespécificationdonnée.Parexemplelesystèmepeutralentirle programmeougénérerdefauxaccèsaudisquedurpourbrouiller lecodaged’un messagetransmispardesaccèsaudisque.Le coûtduconfinementgarantipeutêtrecher. Alors quelquesfois, onsecontentedelimiter labandepassanted’un canalcaché.

2.4 Authenticité

L’authenticitéconsisteàgarantirquelesdonnéeslivréesàunutilisateursontcellesqu’ildemandait,c’est–à–direquel’expéditeurestbienceluiqu’il prétendêtreetquelesdonnéesne

7Lescanauxd’inférencesontquelquefois appeléslescanauxderaisonnement.

2.5. INTÉGRITÉ 29

sontpasmodifiéesenrouteentrel’expéditeur(le servicedestockagesecondaireouunsystèmedistant)et le programmelancéparl’utilisateur.Dansunsystèmecentralisé,l’existenced’un moniteurderéférenceet la correctiondusous–systèmedesécuritépeuventgarantirqu’il n’y apasmoyendemodifierlesdonnéesentredeuxentitésdusystème.Dansla plupartdessystèmesrépartis,le cheminentrele stockagesecondaireet lesapplicationsetentredeuxprocessuscommunicantspasseparplusieurssous–systèmes.Enpassantparleréseau,le messagerisqued’êtremodifiéparunattaquant.Alors il fautunmécanismequipermetd’envoyer lesmessagesdefaçonàceque:

1. l’expéditeurnepuissepasnier l’envoi dumessage,

2. le récepteurpuissevérifier l’identité del’expéditeur,

3. le récepteurnepuissepasfabriquerle messagelui même.

Cesobjectifspeuventêtreatteintsparle chiffrementasymétrique(cf. 2.8.3)ouparlessignaturesdigitales[Rivest78, Schnorr91,NBS94].

2.5 Intégrité

Unedéfinitiondel’intégrité est“la capacitédusystèmeinformatiqueàempêcherla corruptiondesinformationspardesfautesaccidentellesou intentionnelles”[Nicomette96]. Lescasdefautesaccidentellessontnormalementrésolusparlestransactions[Lomet77, Lampson81]. Encequi concernelesfautesintentionnelles,lesattaquesvisentà modifierousupprimerdesinformationsdansle systèmeouà introduiredefaussesinformations,normalementpourunprofit personnelouprofessionnel(parexemplelesfraudesinformatiques).Le modèled’intégritéle plusconnuestprobablementceluiproposéparBiba [Biba77].Cemodèleintroduitunenotationformelle(mathématique)pourdécrirelesrestrictionsnécessairesà imposersurlesmodificationsdedonnéespourgarderleur intégrité.Le modèleséparelessujetset lesobjetsendifférentesclassesd’intégrité(“integrity levels”) —uneclassificationd’intégrités’appliqueauxsujetsetauxobjets.Ensuiteil définitunerelationdedomination,celle–ciconstitueunordrepartielqui estdéfinisurtouteslesclassesd’intégrité.Pourgarantirl’intégrité desdonnées,cemodèledéfinitdeuxconditions8 :

1. Un sujetpeutmodifierunobjetuniquementsi la classed’intégritédusujetdominecelledel’objet � intégritésimple�

2. Un sujetpeutlire unobjetuniquementsi la classed’intégritédel’objet dominela classed’intégritédusujet � intégritéconfinée�

Cesconditionsgarantissentqu’unobjettrèsintègre(“high integrity object”)nepeutpasêtrecontaminépardesinformationsobtenuesparunobjetmoinsintègre(“low integrity object”).Cesconditionssontillustréesdansla figure2.3.

8Cesconditionsressemblentauxconditionsdela sécuritémulti–niveauproposéesparBell & LaPadula(cf. 3.4)maisla confidentialitéet l’intégrité sontenréalitéorthogonaleset lesclassesdeconfidentialitéet lesclassesd’in-tégritésontdifférentes.


moins intègres

Objets Sujets

très

intègres

moins

intègres

Objets�� très intègres

FIG. 2.3:Éliminationdela contaminationdesinformationsintègresparlesinformationsmoinsintègres

Il existebeaucoupd’exemplesdedonnéesqui sontpubliques,maisoù le systèmedépenddeleur intégrité,parexemplelesfichiersdeconfigurationd’un systèmeUnix. Aveclesmécanismesadéquatspourvérifier lesconditionsci–dessus,beaucoupdetâchesd’administrationdusystèmepourraientsefairesansprivilègeparticulier. Malheureusementlessystèmesd’exploitationréalisentrarementlesmécanismespermettantdegarantirl’intégritédesdonnées.

2.6 Disponibilité

Il s’agit d’assurerla disponibilitédusystèmelui mêmeetdesinformationsstockéesdanslesystème.L’accèsausystèmepeutêtreinterrompupardescausesnonvolontaires: unefautedeprogrammationdansuneapplication,unepannegénéraledusystèmeoubienunévénementplusgrave(parexemplecoupured’électricité,incendieou tremblementdeterre).Il peutégalementêtreinterrompupardesactionsvolontaires,parexempleunesurconsommationdesressources.Cesactionssontnormalementappeléeslesperturbations(“Denial of Service”ou“DoS”).Uneméthodetrèsrépanduepourgarantirla disponibilitéestdelimiter la consommationdesressourcesparchaqueprocessusetutilisateur. Si unseulutilisateurn’arrivepasàsurchargerlesystème,suffisammentderessourcesdoiventresterpourpouvoir garantirla disponibilité.Iln’estpaspossiblededistinguerle casoùplusieursutilisateurscoopèrentensurchargantlesystèmeducasoù le systèmeestréellementsurchargé,alorsnousregardonscecascommeunproblèmedeconceptionouconfigurationdusystème.Unix estunbonexempledesystèmequi limite la consommationdesressourcesdechaqueutilisateurpourpouvoir garantirla disponibilité.Le quota(1) limite l’utilisation deressourcessurle disqueet l’ ulimit(1) limite la consommationd’autresressourcescommela mémoirevirtuelle, le nombredesprocessusqui peuventêtreexécutésenparallèle.La disponibilitépeutêtrevuecommeunparamètredequalitédeservice(la non–disponibilitéoffre unservicedetrèsmauvaisequalité).Le problèmeadoncaussiétéétudiédansle contextedessystèmesqui offrentunegarantieparrapportà la qualitédeservice.Dansle systèmeAlta [Tullman98] touteslesressourcessontallouéesselondesréservationsfaitesà l’avanceparlesutilisateurs(normalementenpayantpourl’utilisation decesressources).Le problèmedela disponibilitén’a pasencoreétépris trèsausérieuxparla communautédelarechercheensécurité,maisl’intérêt del’industriepourlessystèmestempsréelvaprobablementchangerceladansle futur.

2.7. POLITIQUESDE SÉCURITÉ 31

2.7 Politiques desécurité

Lespolitiquesdesécuritédéfinissentl’ensembledespropriétésdesécuritéquel’on désireassurerdansunsystèmeainsiquelesdispositifspourlesassurer. La politiquedoit identifierlesobjectifsdesécuritédusystèmeet lesmenacesauxquellesle systèmedevrarésister.

“La politiquedesécuritéd’un systèmeestl’ensembledeslois, règlesetpratiquesquirégissentla façondontl’information sensibleet lesautresressourcessontgérées,protégéesetdistribuéesà l’intérieur d’un systèmespécifique”[ITSEC91]9.

La politiquedesécuritédécidedela validitédetoutaccèsauxobjetsprotégés.La définitiondela politiquedesécuritéestdoncvitalepourla sécuritédusystème.L’importancedecettedéfinitionestbiencaptéeparl’observationsuivantedeAmes,GasseretSchell:

“Un systèmedonnéestuniquement“sûr” par rapportà unepolitiquedesécuritéspécifique.” [Ames83]

Unepolitiquedesécuritésedivisenaturellemententroissous–politiques: la politiquedesécuritéphysiquequi contrôlele droit d’accèsphysiqueauxmachines,la politiquedesécuritéadministrativequi contrôlel’administrationdusystèmeet le personnelqui l’utilise et lapolitiquedesécuritélogiquequi contrôlelesdroitsd’accèsauxdonnéesparlessujetsdusystème.Cesdifférentessous–politiquessontdécritesdansla suite.

2.7.1 Politiques desécuritéphysique

Lespolitiquesdesécuritéphysiques’occupentdetoutcequi concernela situationphysiquedusystème.Enparticulier, ellesdéfinissentlesmesurescontrele cambriolage,lesincendies,lescatastrophesnaturelles,et lescoupuresd’électricitéoud’eau(pourla climatisation).Dansle casdesystèmesrépartis,cespolitiquessontdeplusenplusdifficilesàmettreenœuvreparcequelesresponsablescontrôlentdemoinsenmoinsla localisationphysiquedusystème.

2.7.2 Politiques desécuritéadministrati ve

Lespolitiquesdesécuritéadministrativetraitentdetoutcequi concernel’administrationdusystèmeetdesgensqui l’utilisent. Ellesdéfinissentlesresponsabilitésdechacun,parexemplele nomduresponsabledela sécuritéet le nomduresponsabledespostesd’incendie.Cespolitiquesdoiventaussidéterminerlespersonnesqui sontdignesdeconfiancepourcertainesopérations,etdoncàqui pourraêtreconfiéel’autorisationdelesexécuter.Enfin lespolitiquesdesécuritéadministratives’occupentdetouteslesprocéduresétabliesautourdusystème,parexemplepourla manipulationdesentrées–sorties(imprimantes,sauvegardes,etc.),l’installationetmaintenancedeslogiciels,l’installationdesnouvellesmachinessurle réseau,etc.Cesrèglesnepeuventpasêtrevérifiéesparle systèmelui même,alorsellesdoiventêtrevérifiéespardescontrôlesphysiques,parexempledesverrous,desgardiens,etc.

9TraductionselonVincentNicomette[Nicomette96].


2.7.3 Politiques desécuritélogique

Lespolitiquesdesécuritélogiquesontréaliséesparle systèmeinformatiquelui–même.Ellessedécomposentendeuxpolitiquesdistinctes: la politiqued’authentificationet la politiqued’autorisation.

La politique d’authentification déterminecommentlesutilisateurs(etprogrammes)s’identifientauprèsdusystèmeet la vérificationdecetteidentification.La politiqued’authentificationdécidequelmécanismed’authentificationutiliser (cf. 2.8.1).

La politique d’autorisation déterminelesdroitsquelessujetsontsurlesobjets.Lapolitiquespécifieégalementcommentcesdroitspeuventêtremodifiés.

Nousallonsétudierlespolitiquesd’autorisationdansla suite.

2.7.4 Politiques d’autorisation

Ondistingueentredeuxtypesdepolitiquesd’autorisation: lespolitiquesdiscrétionnairesetlespolitiquesmandataires10.

Politiques discrétionnaires

Dansle casd’unepolitiqued’autorisationdiscrétionnaire,lesdroitsd’accèspeuventêtremanipuléslibrementparlessujetseux–mêmes.Le droit demanipulerlesdroitsd’accèsàunobjetestnormalementconsidérécommeundroit d’accèsparticulierqui peutêtredéléguéàcertainssujets(le propriétairedel’information estnormalementparmicessujets).Ainsi ledroit dedéléguerlesdroitsd’accèsestconfiéà la discrétiondessujetset sebaselargementsurla confiancedanslessujets.Remarquonsquel’abusdecetteconfiancepeutamenerle systèmedansunétatnonsûr,c’est–à–direcontraireà la politiqued’autorisationdéfinie).Ainsi lessystèmesqui réalisentunepolitiqued’autorisationdiscrétionnairesontparticulièrementvulnérablesauxattaquescommele cheval deTroie.Lespolitiquesdiscrétionnairessonttrèsrépanduesdanslessystèmesd’utilisationcivils parexempleUnix etWindowsNT.

Politiques mandataires

Dansle casd’unepolitiqued’autorisationmandataire,lesinteractionsentresujetsetobjetssontdirigéespardesrèglesincontournables.Cesrèglesdéterminentlesdroitsd’accèsqu’unsujetparticulierpeutpossédersurn’importequelobjet.L’unedesfaçonsdespécifiercesrèglesestd’imposerunehiérarchiepourlessujetsetpourlesobjets; c’estle casdespolitiquesmulti–niveauxappliquéesparlesmilitaires[Landwehr81].Dansunetellepolitique,lesinformationssontclasséesselonleursensibilitéet lesutilisateurssonthabilitésàaccéderà l’information jusqu’àuncertainniveaudeclassificationdesécurité.Cesclassificationsethabilitationsdéfinissentunordretotal surlesinformationsstockéesdansle systèmeetsurlesutilisateurs.

10Une descriptiondespolitiquesdiscrétionnaireset mandatairessimilaire à celle donnéeici apparaîtdanslechapitre9 “Toléranceauxfautes,sécuritéet protection”(parY. Deswarte)dans“Constructiondessystèmesd’ex-ploitationrépartis”[Balter91].

2.8. MÉCANISMESPOURMETTREEN ŒUVRELA SÉCURITÉ 33

Lesinteractionslégalesselonlesrèglessuiventnormalementunmodèledeprotection,parexempleceluiproposéparBell & LaPadula(cf. 3.4).Mais il existeaussid’autrespolitiquesmandataires,parexemplele modèled’intégritédeBibadécritci–dessus.Danslespolitiquesmandataires,la confianceestremplacéeparle contrôle.Commedit le proverbe,“la confianceestbienmaisle contrôleestmieux”.

2.8 Mécanismespour mettreenœuvre la sécurité

Il fautuncertainnombrededispositifspourmettreenœuvreunepolitiquedesécuritédansunsystèmeréparti.Troismécanismesdebasesontnormalementidentifiésdansla littérature: unmécanismed’authentification,unmécanismed’autorisationetunmécanismedecommunicationsûr.

2.8.1 Authentification

Il estimpératifd’établir l’identité d’un interlocuteurqui souhaiteavoir accèsauxressourcesdusystèmeetdegarantirl’authenticitédesrequêteset réponsesentremachines.Lesbutsdel’authentification(“authentication”)estdevérifier l’identité detouslesutilisateursqui souhaitentutiliser le système,deleurattribuerun identificateursystèmeetdegarantirlavaliditédecetidentificateurentremachines,afindepouvoir déterminerl’initiateur (utilisateurougrouped’utilisateurs)detoutaccèsauxressourcesdusystème(y comprisl’envoi demessage).La vérificationconsisteàs’assurerquel’utilisateurestbienceluidontil présentel’identité, aumoyende:

– quelquechosequeconnaîtl’utilisateur (parexempleunmotdepasse),

– quelquechosequ’il possède(badge,cartemagnétique,carteà puce,etc.),

– quelquechosequi lui estpropre (empreintedigitale,voix, scanographiederétine,etc.),

– quelquechosequ’il sait faire (parexempleunesignature).

Pouraugmenterl’efficacité,unecombinaisondeplusieursdecesdispositifspeutêtreutilisée,parexemplel’identificationutiliséeparla CarteBleueutiliseunecombinaisond’unecarteàpuceetd’un motdepasse(le P.I.N. “PersonalIdentificationNumber”).La plupartdessystèmesutilisentaujourd’huile motdepassecommeseuldispositifdevérification.Parexemplele systèmeUnix maintientunfichieraveclesmotsdepassechiffrésdetouslesutilisateursenregistrés.La procédurede login(1) exigequel’utilisateurspécifiesonidentitéetsonmotdepasse,puisvérifiequelesdeuxcorrespondent.Il y adeuxproblèmesavecceschéma: lesutilisateurschoisissentsouventdesmotsdepassefacilesàdeviner(comme“password” ou“secret”)et lesmotsdepassesontvulnérableschaquefois qu’ils sontutilisés(beaucoupdesystèmestransmettentlesmotsdepasseenclair surle réseau).Pourrépondreauxdéfaillancesdesmotsdepasse,uncertainnombredemécanismesd’authentificationont étéproposés.La plupartdescesmécanismessebasentsurunprotocoled’authentificationproposéparNeedhametSchroeder[Needham78].Un exempled’un telsystèmeestle systèmeKerberos[Steiner88,Kohl93] — développéauMassachussetsInstituteof Technology(MIT) auxÉtatsUnis— qui esttrèsrépandudanslessystèmescommerciaux.Au momentdu login , le serveurd’identificationdeKerberosenvoieuncertificatà


l’utilisateur, chiffré avecle motdepassedel’utilisateur, qui doit entrersonmotdepassepourobtenirle certificatsurle posteclient; ainsile motpassedel’utilisateurnepassejamaisenclair surle réseau.Cecertificatestensuiteutiliséparl’utilisateurpours’identifierauprèsdesdifférentsserveursdusystème.Un modèledecontrôled’accèsqui sebasesurlescertificatsaétédéveloppépourl’utilisationdanslessystèmesrépartisparLampsonetal. [Lampson92]. Lessujetssontidentifiésparleurcléprivée,c’est–à–direleurcapacitéàchiffrer unechaînedecaractèresqui peutensuiteêtredéchiffréeparla clépubliquedeceluiqu’il prétendêtre.Le modèlepermetàunsujetdedéléguerunepartiedesesdroitsd’accèsàquelqu’und’autreavecuncertificatdedélégation.Le certificatdedélégationprouvequele fournisseurreprésenteceluiqui asignéle certificat.L’applicabilitédecemodèlea étémontréeparsaréalisationdansle systèmeTaos[Wobber94].D’autressystèmesd’authentificationqui sebasentuniquementsurlescertificatsont étéproposés[Aura99,Mazieres98].Cetyped’authentificationnécessiteuneinfrastructurequipermetauxserveurssoit devérifier le certificatqui déterminel’identité dusujet,soit defournirla clépubliquedel’utilisateurd’unefaçonsûre.Desexemplesdecetyped’infrastructuresontX.509[ITU93] proposéparl’Union Internationaledela Télécommunications(ITU, auparavantCCITT) etSPKI [Ellison98, Ellison99] qui estencoursdedéfinitionparl’InternetEngineeringTaskForce(IETF).L’avantagedecesschémasestderendrela délégationdesdroitsd’accèsplussouple,il suffitd’envoyerà quelqu’ununcertificatpourlui transférerle droit d’accéderauxressourcesprotégées.

2.8.2 Autorisation

L’autorisationviseàfixer lesrèglespourlesrelationsentresujetsetobjetsdansle systèmeetàgarantirquecesrèglessontrespectées.Un sujetestuneentitéactive (utilisateur, programme,etc.)etunobjetestuneentitépassive(fichier, écran,ressourcedecalcul,etc.)qui peutêtremanipuléepardessujetsautorisés.Nousreviendronssurl’autorisationdansle chapitresuivant.

2.8.3 Communication sûre

Quanddesinformationssensiblesdoiventêtretransmisesentredeuxsous–systèmesdesécuritédifférents,ellespeuventêtreinterceptéesoumodifiéesparunattaquant.Alors il fautunmoyenderendrelesinformationsincompréhensiblespourl’attaquantetdelesprotégercontrelesmodifications.Il existedeuxtechniquesdifférentespourrendrelesinformationsincompréhensibles: lastéganographieet le chiffrement[Rivest98].

La stéganographieconsisteàcacherunmessagedansunautremessagebeaucouppluslarge.Parexempleunmessagepeutêtrecachédansuneimageenutilisantlesbits lesmoinssignificatifsdechaquepixel commebitsdemessage.Le messagepasseenclairsurle réseau,donctout le mondepeutpotentiellementle lire, maistout le mondenesaitpascommenttrouver le message.

Le chiffr ementconsisteà transformerdesinformationsenclair (“clear text”) enuntextechiffré (“cipher text”) à l’aide d’uneclémaintenuesecrèteetunefonction(réversible)dechiffrement.La fonctioninverses’appellele déchiffrement.

2.9. ÉVALUATION DE LA SÉCURITÉ 35

La sténographieestrarementutiliséeparcequ’elle imposeunsurcoûtencommunicationpourcacherle messageenvoyé.Nousallonsdoncnousconcentrersurle chiffrementdansla suite.Il existedeuxclassesd’algorithmedechiffrement: chiffrementsymétriqueetchiffrementasymétrique.

Chiffr ementsymétrique

Lesalgorithmesdechiffrementsymétrique,commeparexempleDES[NBS77] ouIDEA [Lai92] utilisentla mêmeclépourle chiffrementet le déchiffrement.

Chiffr ementasymétrique

Le chiffrementasymétrique[Dif fie76, Rivest78] utiliseuneclépourle chiffrementetuneautrepourle déchiffrement.La clédechiffrement,qui estnormalementconnuepartout le monde(elles’appelleaussila clépublique), permetd’envoyerunmessagechiffré àquelqu’unquiconnaîtla clédedéchiffrement.Cetteclénedoit pasêtredivulguéeparle récepteur, etelles’appelledoncaussila clésecrète.

L’utilisation du chiffr ement

Le chiffrementétaitinterditparla loi enFrancesanspermissionpréalable.Dansuneconférencedepressele 19 janvier 1999[Jospin99], le premierministreannonçaitla libérationpartielleduchiffrement,et le chiffrementavecunelongueurdeclé jusqu’à128bitsestmaintenantlibre. La libérations’appliqueà l’importationet l’utilisation duchiffrement,mêmesi lesajoutsfaitsle 3 décembre1998à l’accorddeWassenaar[Wassenaar95]limitentl’exportationdesproduitsdechiffrementà l’étranger.LesproduitsdechiffrementlesplusrépandussontSSL(“SecureSocketLayer”) [Freier96]etPGP(“PrettyGoodPrivacy”) [Zimmermann95, Callas98].Pourensavoir plussurle chiffrement,nousrecommandonsle livre “AppliedCryptography”deBruceSchneier[Schneier96]qui estunouvragederéférencefort complet.

2.9 Évaluation de la sécurité

Pourquelesacheteurset lesutilisateurspuissentavoir l’assurancequeleurssystèmessontsûrs,uncertainnombredecritèresd’évaluationetdeclassificationdela sécuritéd’un systèmeinformatiqueontétéproposés.Nousallonsétudierlespluscourantspourdéterminerlestraitsdela sécuritélesplusrépandus.

2.9.1 Le Li vreOrange

Lescritèrespubliésparle ministèredela défenseaméricaine(“Departmentof Defence”ouDoD) dansle rapport“TrustedComputerSecurityEvaluationCriteria” [DoD85] (plusconnusousle nomdeTCSECou“le LivreOrange”11) sontprobablementlesplusconnus.En fait cescritèressontdevenusla référencecanoniqueenmatièredesécuritédessystèmesinformatiques.

11Le livre orangeestainsinomméparcequeil appartenaità unesériedelivressur la sécuritépubliéssousdescouverturesdescouleursdifférenteset la couverturedecelui-làétaitorange.


LescritèresfournissentuneclassificationenseptniveauxregroupésenquatreclassesdesécuritéA, B, C etD (A estle plussûr).Outresapropredéfinition,chaqueclasseréaliseaussilestraitsdesécuritédesclassesprécédentes.La classificationestdonnéedansle tableau2.1.Pourêtreévaluéàuncertainniveau(êtreassociéàuneclassedesécurité),le systèmedoitsatisfairetouteslesconditionsrequisesduniveauet toutescellesdesniveauxprécédents.Laplupartdessystèmesinstalléssurlesmicro–ordinateurssontclassifiéD ouC1,maisquelquessystèmesd’Unix ont atteintuneclassificationC2.La politiquemandataireimposéeparle livreorangeestcelledeBell & LaPadula(noustraitonscettepolitiqueenplusdedétaildans3.4).Cettepolitiqueréalisele modèled’accèsauxinformationsmilitaires,c’est–à–diregarantitle secretdesinformations.Cemodèlen’estpasforcémentle plusappropriépourlessystèmescivils, c’estpourquoiunnombred’autresmodèlesontétéproposéspourprendreencomptel’intégrité et la disponibilitédesdonnées.L’introductiondecesmodèlesaprovoquéla créationd’autrescritèresd’évaluation,notammentlesITSEC(“InformationTechnologySecurityEvaluationCriteria”) adoptésparl’UnionEuropéenne,lesCTCPEC(“CanadianTrustedComputerProductEvaluationCriteria” [CTCPEC93]) auCanadaet lesJCSEC(“JapaneseComputerSecurityEvaluationCriteria” [JCSEC92]) auJapon.

2.9.2 Les ITSEC

LesITSECsontle résultatd’unecollaborationentrequatrepayseuropéens: l’Allemagne,l’Angleterre,la Franceet lesPays–Bas[ITSEC91]. LesITSECintroduisentla séparationentrefonctionnalitéetassurance: ils définissentunnombredeclassesdefonctionnalité(commelelivreorange)etunnombredeniveauxd’assurance.Uneclassedefonctionnalitédécritlesfonctionnalitésqu’unsystèmedoit mettreenœuvrepourêtreévaluéàceniveau.LesITSECdéfinissentlesclassesF–C1,F–C2,F–B1,F–B2etF–B3correspondantauxclassesC1— B3 définiesparle livreorange.Un niveaud’assurancepermetdedécrirelespreuvesqu’unsystèmedoit apporterpourmontrerqu’il réaliselesfonctionsspécifiéesparla classedefonctionnalité.LesITSECdéfinissentseptniveauxd’assurancedeE0àE6.Chaqueniveaurajoutedesconditionsdesécurité(surtoutauniveaudespécificationetconformitéentreconceptionet réalisation)auniveaud’avantpourfinalementarriverà unespécificationformelledusous–systèmedesécuritéetdel’architecturegénérale.LesITSECintroduisentla notiondecibled’évaluation(“Targetof Evaluation”ou “TOE”)pourdésignerl’ensembledescomposantsdusystèmeévalués,c’est–à–direla politiquedesécurité,lesfonctionsrequisesdédiéesà la sécurité,la définitiondesmécanismesdesécuritérequiseset le niveaud’évaluationvisé.

2.9.3 Lescritèrescommuns

La diversitédescritèresd’évaluationrendla comparaisondela sécuritéentresystèmestrèsdifficile. Lescritèrescommuns(CC)ontétéproposéspourharmoniserlescritèresaméricains(TCSEC),canadiens(CTCPEC)eteuropéens(ITSEC).La version2.0decescritères[ISO15408] a étépromueNormeInternationaleparl’OrganisationInternationaledeNormalisation(ISO) le 8 juin 1999.

2.9. ÉVALUATION DE LA SÉCURITÉ 37

D Non classé– Lessystèmesdanscetteclassen’ont pasétésoumisà l’évalua-tion ou ils n’ont pasqualifiésà uneclassificationsupérieure. Ils offrentunesécuritéminimale.

C Protection discrétionnaire – Lessystèmesdanscetteclasseoffrent lesmé-canismespour la miseen œuvre d’une politique de protectiondiscrétion-naire. Il existedeuxsous–classes:C1 Accèsdiscrétionnaire – Cessystèmesoffrent uneséparationentredes

utilisateurset leursdonnéeset les mécanismespour protégerles don-néesd’un utilisateurcontrel’accèsnon–autoriséd’autresutilisateurs.

C2 Accèscontrôlé – Cessystèmesoffrent l’authentificationdesutilisa-teurs,l’audit desévénementsdesécuritéetunmécanismedeprotectionséparé.

B Protection mandataire – Dans cetteclassela sécuritéest réalisé par lesous–systèmedesécurité.Il doit vérifier l’accèsà touteslesdonnéeset ap-pliquerla politiquedesécurité.Lemoniteurderéférencedoit égalementêtreréalisé.Il y a troissous–classes:B1 Protection avec marquage – Cessystèmesmarquenttous les objets

avec leur classificationde sécuritéet imposentqueles objetspeuventuniquementêtreutiliséspardessujetsqui ontunehabilitationaumêmeniveauouàunniveausupérieur.

B2 Protectionstructurée– Cessystèmesontétéréalisésdèsle départavecune politique de sécuritédocumentée.Tous les canauxde communi-cation qui peuvent être exploités (mêmeles canauxcachéscf. 2.3.3)doiventêtreidentifiés.

B3 Domainesde sécurité– Le sous–systèmedesécuritédecessystèmesréalisele moniteurde référence.La notionde domainede sécuritéestintroduite.Un domainedesécuritésecomposede (i) uneliste d’utili-sateurs(ougroupesd’utilisateurs)qui peuventaccéderàunobjetet (ii)une liste d’utilisateurs(ou groupesd’utilisateurs)qui ne peuvent pasaccéderà l’objet.

A Protection vérifiée – Lessystèmesdanscetteclasseont étésoumisà uneconceptionformelle. Ils s’adressentà la gestiondesdonnéesclassifiées.A1 Conception vérifiée – Cessystèmesoffrent les mêmestraits que les

systèmesdansla classeB3, mais la conceptionformelle complètedusystèmeoffre unegarantiequele systèmesoitsûr.

TAB. 2.1:Classificationdu livreorange


LesCCreprennentla séparationentrefonctionnalitéetassurancedesITSEC,demêmequelanotiondecibled’évaluationqui désignele systèmeàévalueret l’objectif dela sécurité(“SecurityTarget” ou “ST”). La spécificationdel’objectif dela sécuritépeutcontenirunouplusieursprofilsdeprotection(“ProtectionProfiles”ou “PP”). Un PPdéfinitunexempled’exigencesdesécuritéetd’objectifs,indépendantsd’unequelconqueréalisation.Lesprofilsdeprotectionpermettentdespécifierlesobjectifsdela sécuritéentermesdeprofilsconnus.Cecirendla spécificationdel’objectif dela sécuritéplussimplepourle développeurquidemandel’évaluationdesonsystèmeetpourle clientqui achèteun tel système.LesnouveauxprofilsdeprotectionpeuventêtredéfinisàpartirdesPPexistantspourprendreencomptelesbesoinsdesécuritéparticuliers.UnepartieimportantedesCCestdoncconsacréeà laprésentationdétailléedesprofilsdeprotectionprédéfinis.

2.9.4 Conclusion

L’évaluationdela sécuritéd’un systèmepermetdesavoir àquelniveauonpeutlui faireconfiance.Engénéral,le systèmeévaluéauniveaule plussûrpeutrecevoir lesinformationslesplussensibles,maisceladépendbienévidementaussidel’environnementdusystèmeetdesmenacesauxquellesle systèmeestsoumis.La séparationentrela fonctionnalitéet l’assurancemontrel’importancedela réalisationpourla sécuritéd’un système.La fonctionnalitépeutsuffire pourréaliserunmodèledeprotectionparticulier, maissi le systèmen’estpasconçuet réaliséd’unefaçonsûre,cettefonctionnaliténevautrien.Engénérallesniveauxd’évaluationlesplussûrsrequièrentunespécificationformelledel’architectureetdela conceptiondusystèmeetunevérification(égalementformelle)quelaréalisationestconformeauxspécifications.

2.10 Récapitulation et discussion

Il existeaujourd’huitrèspeudesystèmessûrsendehorsdel’industriemilitaire oudequelquesdomainesspécialiséscommel’industrienucléaireou lestransports.Dansla plupartdessystèmesdisponiblessurle marché,la sécuritén’a pasfait partiedela conceptiondusystème.La sécuritéestunparamètreparmid’autresdansla conceptiond’un systèmeinformatique.Pourréaliserunsystèmebienéquilibré,il s’agitdetrouver le meilleurcompromispossibleentrecesparamètres.La sécuritéjoueunrôle trèsparticulier, parcequela moindredéfaillancepeutcompromettrele bonfonctionnementdusystème.Si l’algorithmed’ordonnancementmarchedans95%descas,maisn’estpaséquitabledans5%descas,le systèmecontinueàfonctionner. Si le systèmedesécuriténemarchequedans95%descas,les5%restantspeuventêtreexploitésparunadversaireet compromettretoutela sécuritédusystème.Danscechapitre,nousavonsidentifiéuncertainnombred’objectifspourla sécuritéetdesmenacescontrela sécuritédessystèmesrépartis.Lesobjectifslesplusimportantssont:

– La confidentialitédesinformationsstockéesdansle système

– L’intégritédecesinformations

– La disponibilitédesinformationsetdesressourcesdusystème

Pouratteindrecesobjectifs,le systèmedoit mettreuncertainnombrededispositifsenplace,notammentlesmécanismespour:

2.10. RÉCAPITULATION ET DISCUSSION 39

– L’identificationet l’authentificationdessujetsdusystème

– Le contrôled’accèsauxressources

– La communicationsûre

Le contrôled’accèsauxressourcesdusystèmeestspécifiédansla politiquedesécuritédusystème.Cettepolitiquespécifielescontrôlesphysiques,administratifset logiquesdusystème.Lesparticularitésdela sécuritédessystèmesrépartissontrésuméesdansle tableau2.2.

Système Système Systèmescentral d’exploitation coopérants

(mainframe) répartiidentification globale globale localeauthentification implicite dépenddusystème expliciteautorisation globale globale localecommunicationsûre implicite dépenddusystème explicitemodèledeconfiance globale globale localepolitiquedesécurité globale globale localeconséquencesd’unedéfaillance globales globales locales

TAB. 2.2:Résumédesparticularitésdessystèmesrépartis

Lessystèmesd’exploitationrépartisontétéconçuspourdonnerl’illusion d’un systèmecentralisé.La répartitionentreplusieurssitesnécessitedesmécanismesd’authentificationetdecommunicationsûrs,pourpouvoir maintenirla transparencedecetterépartition.Danslessystèmescoopérants,la répartitionestexplicite et lesapplicationspeuventréaliserleurspropresmécanismes.Dansunsystèmed’exploitationréparti,le domained’applicationdela politiquedesécuritéestglobal.Lessystèmescoopérantspeuventavoir unepolitiqueglobale,maisle domainedetouteslessous–politiquesestlocal.

Chapitre3

Contrôle d’accès

Le contrôled’accèsestindispensablepourla sécuritédanslessystèmesinformatiques.Paradoxalementsonétuden’a pasreçubeaucoupd’attentiondela partdela communautédelarecherche.Depuisle début desannées1980,la doctrinedespolitiquesmandatairesetdiscrétionnaires— établiedansle contextedessystèmesmilitaires— a lentementétéremiseencausecommebaseappropriéepourle contrôled’accèsdanslessystèmescivils [Sandhu96].Ensuitenousavonsvu l’introductiondedifférentsmodèlesdecontrôled’accès(parexemplelecontrôled’accèsbasésurlesrôlesou le modèledela murailledeChine)développéspourrépondreauxdifférentsbesoinsdeprotectiondanslessystèmescivils.Danscechapitrenousallonsd’abordintroduirela notiondecontrôled’accèsdansunsystèmeinformatique.Nousallonsensuitedécrirelesbesoinsdela sécuritémilitaire et lesbesoinsdelasécuritédanslessystèmescivils. Un certainnombredemodèlesdecontrôled’accèsontétédéveloppéspourrépondreauxproblèmesdesécuritémilitaires(notammentle modèledeBell & LaPadula)et civils (le modèlediscrétionnaired’Unix etdeuxmodèlesmandataires—le modèlebasésurlesrôleset le modèledela murailledeChine) ; nousdécrivonslesmodèleslesplusrépandus.Ensuitenousdécrivonslesdifférentsmécanismespourla miseenœuvreducontrôled’accès.Enfinnousdiscutonsle contrôled’accèsdanslessystèmesrépartisetprésentonsunerécapitulationetunediscussiondesmatièrestraitéesdanscechapitre.

3.1 Intr oduction au contrôle d’accès

La politiquedesécuritésecomposedetroissous–politiquesdecontrôle: d’accèsphysique,administratifet logique.Nousnousintéressonsplusparticulièrementà la politiquedecontrôled’accèslogiqueetauxmodèlesdeprotectionetmécanismesnécessairespourla réaliser.Le modèledebasedetouteslespolitiquesdecontrôled’accèsestmontrésurla figure3.1.

moniteur deréférence

Source RessourceGardeRequête

objetsujet opération

FIG. 3.1:Le modèledebaseducontrôled’accès

La figuremontreunsujetqui souhaitefaireuneopérationsurunobjet.Le systèmetransforme

41

42 CHAPITRE3. CONTRÔLE D’ACCÈS

l’opérationenunerequêtequ’il passeaumoniteurderéférencequi contrôlel’accèsauxressources.Si le sujetestautoriséàaccéderà l’objet selonla politiquedesécuritéenvigueur,l’accèsà l’objet vaêtreaccordéet l’opérationpeutsedéroulernormalement.La majoritédesidéesdebasesurle contrôled’accèsontétéfixéesaudébut desannées1970.EllessontlargementinspiréesparunarticledeButlerLampsonsurla protection[Lampson71].Cetarticleintroduit la notiond’unematricedecontrôled’accèsqui décritquelssontlesdroitsd’un sujetsurlesressourcesdusystème.La matricedecontrôled’accèsestunestructurequi contientuneligneparsujetetunecolonneparobjetdansle système.La celluleà l’intersectiond’uneligneetd’unecolonnedécritlesdroitsd’accèsdusujetsurl’objet. La figure3.2montreunexempledematricedecontrôled’accès.

ij

Objets

Sujets

s

o

ai

j

FIG. 3.2:La matricedecontrôled’accès

La matricereprésentéesurla figureci–dessusmontreunsujet �� qui possèdele droit d’accès� �� surl’objet �� .Le modèledecontrôled’accèsbasésurla matricedecontrôled’accèsneprévoit aucuneinterprétationparticulièredusujet,del’objet oududroit d’accès,maiscesontnormalementdesentitésprimitivesdusystème.La granularitédela définitiondusujetetdel’objet dépenddusystème.Quelquesdéfinitionsrépanduessont: unutilisateur, unprocessusouunemachinepourlessujetsetunfichier, unerelationdansunebasededonnéesouunevariabledansunprogrammepourlesobjets.Remarquonsquelessujetsontnormalementaussiuneentréecommeobjetdansla matrice.Cecipermetdecontrôlerle droit d’envoyerunmessageàunutilisateurouunévénementà unprocessus.Quelquesexemplesdesdroitsd’accèssont: le droit delire, écrire,rajouterà la fin ouexécuterunfichierpourunsystèmedefichiers,le droit delire oumodifierunerelationdansunebasededonnées,le droit d’envoyerourecevoir unmessagepouruncanaldecommunicationou ledroit delire oumodifierunevariabledansunprogramme.Un modèledeprotectionqui sebasedirectementsurla matricedecontrôled’accèsaétéproposéparHarrison,RuzzoetUllman[Harrison76].Ils donnentunedescriptionformelledumodèleetdéfinissentla sûretéd’un systèmecommela propriétéqu’il n’existepasdefuite des

3.2. LA STRUCTUREDE SÉCURITÉMILITAIRE 43

droitsd’accèsdansle système,c’est–à–direquele seulmoyend’entrerundroit d’accèsparticulierdansla matriceestl’insertiondudroit parunsujetautorisé.Leuranalysemontrequela sûretédumodèlen’estpasdéterministeengénéral,mêmesi la sûretéd’un systèmeparticulierdansuneconfigurationparticulièrepeutêtreprouvée.Ceciindiquequ’il vaprobablementêtredifficile deprouver la sûretéd’un systèmedeprotectionparticulierqui sebasesurla matricedecontrôled’accès.

3.2 La structur edesécuritémilitair e

Unelargepartiedela rechercheencontrôled’accèsaétéfaitedansle contextedessystèmesmilitaires; nousallonsdoncd’abordétudierlesobjectifsdecetterecherche,c’estàdire lastructuredesécuritémilitaire1.Lesinformationsmilitairessontclasséesselonleursensibilitépourla défensenationale.Laclassificationconsisteendifférentsniveaux(ouclasses)deconfidentialité(“securitylevels”)pourl’information. Chaqueclasseestnormalementdiviséeensous–classes(“compartments”)qui précisela naturedel’information. La classificationutiliséeenFrance[SCSSI91a] estmontréedansle tableau3.12.

InformationsclassifiéTrèssecretdéfense Réservéeauxinformationsdontla divulgationestdenature

ànuireà la Défensenationaleetà la sûretédel’État etquiconcernentlesprioritésgouvernementalesenmatièredeDéfense.

Secretdéfense Réservéeauxinformationsdontla divulgationestdenatureànuireà la Défensenationaleetà la sûretédel’État.

Confidentieldéfense Réservéeauxinformationsqui neprésententpaselles–mêmesuncaractèresecret,maisdontla connaissance,la réunionou l’exploitationpeuventconduireà la divulgationd’un secretintéressantla Défensenationaleet la sûretédel’Etat.

Informationsnon–classifiéSecret Lesindicationsdela confidentialitéd’un documentnon–classifié

portentnormalementunementionspécifiquedudomaineprotégéConfidentiel (personnel,médical,industrie, médical,industrie, commercial, etc.)

etuneprécisiondel’évolutiondela classificationdansleDiffusionrestreinte temps– à quelmomentlesinformationsdoiventêtredéclassées

TAB. 3.1:Classificationmilitaire desinformations

Unehabilitation (“clearance”)estassociéeàchaqueutilisateur. L’habilitationspécifieleniveaudesécuritéauquell’utilisateurestautoriséà accéder. Unelistedesous–classesautoriséesestnormalementassociéeà l’habilitation, qui limite lesinformationsauxquellesl’utilisateurhabilitépeutaccéder(“needto know principle”).

1La sourceprincipaledecettedescriptionestl’article deLandwehrdans“ComputingSurveys” [Landwehr81].2Il existeunehiérarchieanaloguepourlesinformationsdel’OTAN aveclesclasses: Trèssecretcosmic,Secret

OTAN, ConfidentielOTAN etDiffusionrestreinteOTAN.


Pourpouvoir accéderà l’information, le sujetdoit avoir unehabilitationégale(ousupérieure)àla classificationdel’information etavoir la sous–classedel’information danssalistedessous–classesautorisées.L’habilitationd’un sujetspécifiedoncenmêmetempsàquelniveaul’autoritémilitaire lui fait confianceet le niveauet la naturedesinformationsqu’il abesoindeconnaître.Lesdocumentssontnormalementstockésdansuncoffre–fort,doncle droit d’accéderàundocumentcorrespondaudroit dele retirerducoffre fort. La classificationd’un documentestnormalementtamponnéesurle documentmêmeetsurle cahierqui le contient.Pourpouvoirretirerle document,le sujetdoit prouverqu’il possèdel’habilitation nécessairesoit parsonrangmilitaire, soit pard’autresmoyens.Un documentmilitaire nepeutpaschangerdeclassificationmaissesinformationspeuventêtrecopiéesdansunnouveaudocument.Danscecasil fautquela classificationdunouveaudocumentcorrespondeà la classificationdesinformationslesplussensiblescopiéesdanscedocument.Lesinformationspeuventperdreleur importance,parexemplela conceptiondelafortificationdeGrenoble(notammentle Fort St.Eynardet la Bastille)n’a plusd’importancemilitaire. Danscecasunnouveaudocumentd’uneclassificationinférieureestcréeet lesinformationsy sontcopiées– cetteprocédures’appellela déclassification(“sanitizing”) desinformations.Touteslesprocéduresdeprotectionsontmisesenplacepourprotégerlesinformationsclassifiées,doncla déclassificationestunprocessustrèssensiblequi suit desrèglesparticulières.La structuredela sécuritémilitaire aétédéveloppéepourrésoudredeuxproblèmes: d’aborddecontrôlerl’accèsauxinformationssecrètes(confidentialité)etensuited’éviterquelesinformationsd’uneclassificationélevéesoientcopiéesdanslesdocumentsd’uneclassificationinférieure(confinement).Dansle castraditionneldesdocumentsstockésdansuncoffre fort, la sécuritéestassuréeparlescontrôlesphysiquesdel’accèsauxdocuments.Le tampondela classificationsurledocumentrendla recopiedifficile.Dansunsystèmeinformatique,la composition,la correctionet la distributiondesinformationssontbeaucoupplusrapideset la recopiedesdonnéesbeaucoupplusfacile.Deplus,il n’existecourammentpasdemoyensdefaireun tamponsurlesdonnéesqui nepuissepasêtreeffacéfacilement,parexempleenrecopiantle fichierqui contientle document.Alors la miseenœuvredela politiquedeprotectionlogiquedoit pouvoir donnerlesmêmesgarantiesqu’uncoffre fort avecdesgardiensarmés.

3.3 Lesbesoinsde la sécuritédanslessystèmescivils

Commelessystèmesmilitaires,lessystèmescivils traitentdesinformationssensibles(parexemplelesdossiersmédicaux,relevésdecomptes,secretsdefabricationetc.)dontl’assurancedela confidentialitéesttrèsimportante.Maispourunegrandepartiedesapplicationsciviles le besoindepouvoir garantirl’intégrité desdonnéesgéréesparle systèmeestaussiimportant.Parexemple,l’intégrité d’un compteenbanqueestplusimportantequelesecretdusolde.Cettedifférenceentrelessystèmesmilitaireset lessystèmescivils aétéétudiéeparClarketWilson [Clark87].Ils prétendentquel’intégrité estnormalementplusimportantepourlessystèmescivils quela confidentialité.Lestechniquespourla miseenœuvredel’intégrité danslessystèmesdegestionde

3.3. LESBESOINSDE LA SÉCURITÉDANS LESSYSTÈMESCIVILS 45

l’information (avantl’introductiondel’informatique)sontlessuivantes: la transactionbienforméeet la séparationdesfonctionsentrelesemployés.

La transaction bien formée

La notiondetransactionbienforméeestplusgénéralequela définitionnormaled’unetransactioneninformatique.Elle garantitquelesmanipulationsdesdonnéessuiventcertainesrèglespourassurerl’intégrité desinformations.Avantl’ère del’informatique,lescomptablesécrivaienttoujoursà l’encreet lesmodificationsétaientfaitesparuneentréedecorrectionsanseffacerl’entréeexistante; toutetracedemodificationindiquaitunetentativedefraudepotentielle.Aujourd’hui le systèmemaintientun journaldetouteslesmodificationsdesdonnées.Un auditdecejournalpermetderévélerunetentativedefraude.

La séparationdesfonctions

La séparationdesfonctionsapourbut degarantirquelesinformationsstockéesdanslesystèmecorrespondentà la réalité.L’idéegénéraleestd’assurerquele traitementnormaldesdonnéesimpliqueplusieursutilisateurs.Le risquequeplusieursutilisateurssoientmalveillantsestplusfaible.Pourmieuxexpliquercommentcelamarche,nousallonsprendrel’exempled’un magasinqui venddestéléviseurs.Si uneseulepersonneestresponsablepourtouslesachats,lespaiements,le stockageet lesventesdestéléviseurs,il peutmanipulerlesdonnéesqui représententlesprix d’achatet lesprixdeventedansle système(il peutparexempleaugmenterle prix d’achatetbaisserle prix devente)parrapportauxprix réelsetdéroberla différenceaumagasin.Le problèmedanscetexempleestquela mêmepersonnefournit touteslesinformationsausystème; il devienteffectivementla seulesourced’informationpourle système.Cetexemplemontrequelesseulsmécanismesdeprotectiondel’intégrité desdonnéesn’arriventpasàassurerl’intégrité entrelesvaleursreprésentéeset leur représentationdansle système.La séparationdesfonctionsentreplusieursemployés— parexempleunqui commandelestéléviseursetunautrequi paielesfactures— rendla fraudeplusrisquée.Si celuiquicommandelestéléviseursn’entrepasle bonmontantdansle système,celuiqui paielesfacturesva toutdesuitedécouvrirla divergenceetavertir le propriétaire.Il estpossiblepourlesdeuxemployésdecollaborerpourescroquerle magasin,maisla séparationdesfonctionsaugmentele risqued’êtredécouvert.Un autreexempledela séparationdesfonctionslargementrépanduestle droit designerunchèque.Normalementle directeurd’uneentreprisepeutsignertoutseul,maisil fautlasignaturededeuxcommisdebureaupourrendrele chèquevalable.Ceprincipeestexprimédansle modèledecontrôled’accèsbasésurlesrôles(cf. 3.6).Un dernierexempledela séparationdesfonctionsconcernelesemployésdessociétésdeservice.Pendantunemissiondansuneentreprise,le consultantapprendbeaucoupd’informationsconfidentielles.Il fautdoncéviterqu’il travaille toutdesuiteaprèschezunconcurrentparcequececiintroduitunconflit d’intérêt.La sociétédeservicedoit gérerlesconsultantsdemanièreàcequececonflit d’intérêtneseproduisepas.Ceprincipeestexprimédansle modèledela murailledeChine(cf. 3.7).


3.4 ModèledeBell et LaPadula

Le modèlemandatairedeBell etLaPadula[Bell73a,Bell73b, Bell75] estuneformalisationdela structuremilitaire3 adoptéepourl’usagedansunsystèmeinformatique.Le modèledéfinit lessujets,lesobjets,lesclassesdeconfidentialitéet leshabilitationscommeauparavant.Il définitégalementunerelationdedomination— similaireàcelledumodèledel’intégrité deBiba (cf. 2.5)4. Uneclassedeconfidentialité(ouunehabilitation) � domineuneautreclasse�(écrit �� ) si le flot d’informationde � vers � estautorisé.Lesdroitsd’accèsdéfinisparle modèlesontlessuivants:lir e : permetausujetdelire l’objet maispasdele modifier;écrire : permetausujetdelire etécrirel’objet ;rajouter : permetausujetd’écrirel’objet maispasdele modifier;exécuter : permetausujetd’exécuterle contenudel’objet commeunprogramme,

maisil nepeutni lire ni écrirel’objet.Un attribut dechaqueobjetspécifiel’identité dusujetqui contrôlel’objet (le propriétairedel’objet). Le propriétaireestnormalementceluiqui acréél’objet.Lesrèglesdesécuritésontexpriméesparlesdeuxconditionssuivantes.

Condition desécuritésimple : Un sujet � peutlire unobjet � seulementsi le niveaudeconfidentialitéde � dominele niveaudeconfidentialitéde � .La propriété � : Un sujet � peututiliser le contenud’un objet �� pourmodifierunobjet�! seulementsi le niveaudeconfidentialitéde �" dominele niveaudeconfidentialitéde�#� .

Pourlire unobjetle sujetdoit doncavoir unehabilitationqui égaleousurpassele niveaudeconfidentialitédel’objet.Cesdeuxconditionsdesécuritésontnormalementrésuméescommesuit : unsujet“peut lireversle basetécrireversle haut”.La propriété� (appelée“la propriétéétoile”) estmoinsintuitive.Elle dit quele sujetnepeutpasécrireunobjetd’un niveaudeconfidentialitéinférieurauniveaudel’information le plusélevéauquelil peutactuellementaccéder. Ceciempêchelesujet(ouuncheval deTroie)de“déclasser”l’information contenuedanslesobjetsauxquelsilaaccès.Pourpermettreàunmaréchald’écrireunepetiteannoncelisible partout le monde,le modèleintroduit la notiond’habilitationcourantequi correspondauniveaudeconfidentialitéle plusélevédel’information accédéeparle sujet.Si le maréchaln’a pasencorelu del’informationtrèssecrète,il peutdonccréer/écrireunobjetd’un niveaudesécuritéinférieuràceniveau.Ilfautdoncquele systèmemémorisele niveaud’informationle plushautaccédéparle sujet—depuisle login d’un utilisateuroudepuisle démarrageduprocessus— pourpouvoir garantirquel’objet créén’a pasunniveaudeconfidentialitéinférieuràcelui–ci5. Si le sujetsouhaiteaugmentersonniveaudeconfidentialitépourpouvoir accéderauxinformationsplusconfidentielles,il fautdoncqu’il perdele droit d’écriturepourlesobjetsdéjàactifs(unobjetactif estunobjetencoursd’utilisation).

3Le modèleaétédéveloppéencollaborationentrel’arméedel’air américaineet le MITRE Corporation— uneentreprised’armementaméricaine.

4Enréalitéc’estle modèledeBell & LaPadulaqui a inspiréBiba.5Le systèmeADEPT–50[Weissman69] réalisaitun tel modèledecontrôled’accès(il s’appellele modèledela

lignedeshauteseaux)avantla conceptiondumodèledeBell & LaPadula.

3.4. MODÈLE DE BELL ET LAPADULA 47

La miseenœuvredumodèledeBell & LaPaduladoit respecterlestroisprincipessuivants:

1. Principe de tranquillité. Le niveaudeconfidentialitéd’un objetactif nepeutpasêtrechangé.

2. Non-accessibilitédesobjets inactifs. Un sujetnepeutpaslire le contenud’un objetinactif.

3. Initialisation desobjets.L’état initial d’un objet(aprèscréation)nedépendd’aucuneressourceantérieurementallouéeàunautreobjet.

Le principedetranquillitén’a pasdejustificationdansle modèled’accèsauxinformationsmilitaires,maisil permetderéaliserunmécanismeplusefficacesi la politiquedecontrôled’accèspeutêtrevérifiéeunefois aupremieraccèsà l’objet etnonàchaqueaccès.Un sujetnedoit pasavoir accèsauxobjetsnon–actifs,parexemplela mémoireou lesblocsdudisquedurnon–alloués.L’initialisation desobjetsàpourbut d’assurerqu’il n’existepasdefuite d’informationà traversdela mémoirenon–initialisée.Ceprincipeestmisenœuvreparle plupartdessystèmescourants.Engénérale,l’allocationd’unepagedemémoireoud’un blocdedisquedurmetlapageou le blocà zéroavantle retournerausujet.Lesprincipesdela non–accessibilitédesobjetsinactifset l’initialisation desobjetsà la créationgarantissentquela mémoire(primaireousecondaire)non–allouéenepeutpasconstitueruncanalcaché.

3.4.1 Variations du modèle

Denombreusesvariationsdecemodèleont étéproposéesdansla littérature,notammentlemodèledeflot d’information.La conceptiondecemodèleestnormalementattribuéàDenning[Denning76]. Le modèleestunegénéralisationdumodèlemandatairequi décritlesflotsd’informationsûrsdansunsystème.Denningmontrequele modèlepeutêtreexprimédansla théoriedestreillis. Cerésultatestimportantparcequedenombreuxautresmodèlespeuventêtreexprimésdanscettethéorie[Sandhu93].Le modèled’intégritéproposéparBibaestuneautrevariationdumodèledeBell & LaPadulaqui protègel’intégrité desinformationsaulieu dela confidentialité.

3.4.2 Discussion

Le modèledeBell & LaPadulaaétéréalisédansuncertainnombredesystèmes[Ames78, McCauley79, Neumann77, Feiertag79],cecia permisd’obtenirdesexpériencesd’utilisationdecemodèle.La limite principaledumodèleestla restrictionsévèreimposéeparla propriétéétoile.Avecleprincipedela lignedeshauteseaux,ceciapourconséquencequele niveaudeconfidentialitédesdonnéesremontelentementversle niveaule plushaut.Pourremettrelesfichiersà leurniveaupropre,lesprocéduresdedéclassificationdoiventêtreappliquéesfréquemment.Quandla déclassificationdevientunévénementquotidien,le risquedefautecauséeparunmanquedeconcentrationaugmenteénormément.Le gaindecetterestrictionentermedesûretén’estpasévidentparcequele modèlen’empêchepaslescanauxcachés(notammentlescanauxtemporels).


3.5 Modèlediscrétionnaired’Unix

Le modèledeprotectiond’Unix estunexempleclassiquedemodèlediscrétionnaire.DansunsystèmeUnix traditionnel,lescontrôlesd’accèssontprincipalementassociésausystèmedefichiers(fichiers,répertoireset “namedpipes”); il existequelquesexceptionsàcetterègle,notammentl’accèsàunportderéseaudenuméroinférieurà1024et l’accèsàunsegmentdemémoirepartagéedansSystemV.Lesmeta–donnéesassociéesàchaquefichierdésignentle propriétaireetungrouped’utilisateursauxquelsle fichierappartientet lespermissionsd’accèspourle fichier.La notiondugroupeesttrèsimportanteparcequ’ellepermetàunensemblefixed’utilisateursdepartagerdesfichiersentreeux.

3.5.1 Permissions

Lespermissionssontspécifiéesparun tableaudebitsqui indiquentl’existenceou l’absencedesdroitsdelire, écrireet/ouexécuterle contenudufichierpourle propriétaire,songroupeoutouslesutilisateursdusystème.Enplusdecesbitsdeprotection,le systèmemaintienttroisméta–bitsdeprotection: le bitSet–UID,le bit Set–GIDet le bit appelé“sticky”.Lesbitsdepermissionont unesémantiquedifférentepourlesfichiersnormauxet lesrépertoires,cessémantiquessontdécritesparla suite.

Sémantiquepour lesfichiers

lire permetdelire (et copier)le contenudufichier;

écrire permetdemodifierle contenudufichier;

exécuter permetd’exécuterle contenudufichier;

SUID surunfichierexécutable,permetd’affecterl’usager(UID) associéauprocessusàceluidufichierpendantl’exécutionduprogramme;

SGID surunfichierexécutable,permetd’affecterle groupe(GID) associéauprocessusà celuidufichierpendantl’exécutionduprogramme;

“sticky” permetd’indiquerausystèmequ’unbinaire(unprogrammeouunebibliothèquepartagée)doit resterdansl’espacedepagination(swap)aprèslaterminaisonduprogramme.Cecipermetderéduirele tempsdechargementdecesbinaires.

Sémantiquepour lesrépertoires

lire permetdelister lesfichierset sous–répertoiresdansle répertoire;

écrire permetdemodifierle contenudu répertoire,c’est–à–direcréer, renommeretsupprimerlesfichiersdecerépertoire;

exécuter permetd’accéderauxfichierset sous–répertoiresdansle répertoire.Sansdroit delire le répertoire,le sujetdoit connaîtrele nomdufichierà l’avancepouryaccéder. Cecipermetàungrouped’utilisateursdepartagerlesfichierssansavoir lesupportd’un groupeencommun.La sécuritédépenddusecretdesnomsdesfichiers,si

3.5. MODÈLE DISCRÉTIONNAIRE D’UNIX 49

le fraudeurarriveàdeviner le nomd’un fichierdansle répertoireil peuty accéderaveclesmêmesdroitsquelesautres; cecis’appelleaussila “sécuritéparobscurité”;

SUID etSGID n’ont pasdesignificationparticulière;

“sticky” avecécrirepermetdecréerdesrépertoiresoù tout le mondepeutcréerdesfichiers,maispersonne(saufroot ) nepeuteffacerourenommerlesfichiersdesautres.

3.5.2 Politique deprotectionpar défaut

La politiquedeprotectionpardéfautintervientaumomentdela créationd’un fichier. À cemomentle systèmeattribueaufichier le nomdel’utilisateurqui le créeet le groupedurépertoiredanslequelil estcréé.Lesdroitsdeviennentceuxdu répertoire,modifiésavecl’ umask(2) del’utilisateurdela façonsuivante.L’umask estunbitmapqui indiquelesbitsà supprimerdanslesdroitsdufichier, c’est–à–direlesbitsqui sont1 dansl’ umask deviennent0 danslesdroits.Ainsi l’ umask classiquede022 indiquequele droit d’écrituredoit êtreretirépourle groupeet lesautres.

3.5.3 Mécanismesdeprotectiondiscrétionnaire

Unix réalisetroismécanismesqui permettentaupropriétaire(ou l’utilisateur root ) demodifierlesmeta–donnéesdela protection:

chown(1) qui permetdechangerle propriétairedufichier (dansSystemV lepropriétairepeutdonnersesfichiersauxautres,dansBSDuniquementroot a le droitdele faire);

chgrp(1) qui permetdechangerle groupeassociéaufichier;

chmod(1) qui permetdechangerlesdroitsassociésaufichier.

Lesopérationschown(1) etchgrp(1) nechangentpaslesdroitssauflesbitsspéciauxquisontmisà zéro.L’annulationdesbitsspéciauxestnécessairepouréviterqu’unutilisateurcréeunprogrammeSUID et le donneàquelqu’und’autre,parexempleroot .

3.5.4 Discussion

Dansunmodèledecontrôled’accèsdiscrétionnaire,la confiancedanslesutilisateursesttotale.Cecinécessitedesutilisateursresponsablesetcompétents— parcequ’il fautquechacund’euxconnaissela politiquedesécuritéglobaleet la respecte.Le contrôlelogiquedusystèmenepermetpasdegarantircertainespropriétésdumodèle.L’impossibilitéd’assurerle confinementenestunbonexemple:

1. si �$� estunsujets’exécutantpourle comptedel’utilisateur %&� propriétairedufichier '�� ,il peutdonnerausujet �( (s’exécutantpour %) ) le droit delecturesur '�� .

2. �( peutcréerunfichier '! surlequelil peutdonnerle droit delectureà �(* (s’exécutantpour %+* ).

3. �( peutrecopier'�� dans'" pourdivulguerlesinformationsde '�� à �,* à l’insu dupropriétaire�$� .


3.6 Modèledecontrôle d’accèsbasésur lesrôles

La notiondepropriétairedel’information danslesmodèlesdiscrétionnairesestartificielleparcequelesdonnéesn’appartiennentnormalementpasà unepersonne,maisàuneentrepriseouuneorganisationgouvernementale.Le droit d’accèsauxdonnéesestnormalementconfiéaupersonnelenraisondeleur travail.Le modèledecontrôled’accèsbasésurlesrôlesreflètecefait parla séparationentrel’identitéd’un utilisateuret le rôlequ’il jouedansl’organisation.Lesdroitsd’accèsauxdonnéessontattribuésauxrôles,alorsquele seulprivilègeassociéàunutilisateurestceluidepouvoir jouerunouplusieursrôlesdansl’organisation.UnemotivationpourcetypedemodèledanslessystèmescoopératifsaétédécriteparCoulourisetDollimore [Coulouris94a, Coulouris94b]. Ils montrentcommentl’identificationdesrôlesfacilite l’attributiondesdroitsd’accèspourdeuxcasprécis: la préparationd’unexamenuniversitaireet la préparationdesinformationsd’un coursdonnéà l’Uni versitédeLondres.Le modèlequenousallonsdécrireici aétédéveloppéauseindu “National InstituteofStandardsandTechnology”(NIST) auxÉtatsUnis [Ferraiolo92,Ferraiolo99].Le modèlen’imposepasdemécanismedeprotectionparticulier, maisil sebasesurlesnotionsd’un rôleactif, unelistederôlesautorisés,lestransactions6 autoriséesparrôleetunprédicatexec-.��/ sujet0213/ transaction4 qui estvrai uniquementsi le sujet � possèdele droit d’exécuterla transaction1 .Le rôle actif

Le rôleactif estle rôlecourammentutiliséparle sujet

AR-.�5/ sujet476 le rôle actif dusujet �Lesrôlesautorisés

Lesrôlesautoriséssontstockéssousformed’unelistederôlesdifférentsquele sujetpeutassumer

RA-.�5/ sujet47698 lesrôlesquele sujet � peutassumer:Les transactionsautoriséespar rôle

Chaquerôleestautoriséàexécuteruneouplusieurstransactionsbienformées(cf. 3.3).Remarquonsquel’autorisationn’estplusassociéeausujetmaisaurôleactif dusujet.

TA -�8!;</ rôle :$4=6>8 lestransactionsautoriséespour touslesrôlesdans 8!;?/ rôle :�:Le modèledéfinit lestrois règlessuivantes:

Attrib ution desrôles

Un sujetestautoriséàexécuterunetransactionuniquements’il achoisioua reçuunrôle :@ �A/ sujet0 @ 1B/ transaction C exec-.�#021D4=E AR-.�!4GF6AH6La notiondetransactionutiliséeici inclut l’identité desdonnéeset la transformationsurcesdonnées.

3.6. MODÈLE DE CONTRÔLE D’ACCÈSBASÉSURLESRÔLES 51

La procédured’identificationn’estpasconsidéréecommeunetransaction.Touteslesautresactivitésd’un utilisateurdoiventêtredestransactionsbienformées.Un utilisateurnepeutdoncpasêtreactif sansassumerun rôle.Le problèmed’attributiondesrôles(quelsrôlesunsujetestautoriséàassumer)estunproblèmeimportantdanscemodèle,doncdifférentesextensionsaumodèleont étéproposéespourrésoudreceproblème,parexemplele modèlesdecontrôled’accèsbasésurlestâches[Thomas94]. Cesmodèlesontétéproposéscommedesmodèlesindépendantsmaisilssemblentreposersurunmodèledecontrôled’accèsbasésurlesrôlesdebaseetserventprincipalementcommeaideà l’identificationdesrôleset l’attributiondesdroitsd’accèsauxrôles.

Autorisation pour un rôleLe rôleactif d’un sujetdoit êtreautorisépourle sujet:

@ ��/ sujet C AR-.�!4JI RA-��"4Avecla règled’attributiondesrôles,cetterèglegarantitqu’unutilisateurn’arrivepasàassumerunrôlepourlequelil n’a pasdedroit.

Autorisation pour une transactionUn sujetpeutuniquementexécuterunetransactionssi sonrôleactif estautorisépourl’exécuter: @ �A/ sujet0 @ 1B/ transaction C exec-��#021D47EK1ML TA - RA-.�!424Aveclesdeuxautresrègles,cetterèglegarantitqu’unsujetpeutuniquementexécuterunetransactionpourlaquelleil aétéautorisé.L’“uniquementsi” dansla définitionci–dessuspermetd’imposerdesrestrictionsadditionnelles,parexemplecertainestransactionspeuventuniquementêtreautoriséespendantla journée(pouréviterquela femmedeménageexploiteun terminalqui aétélaisséconnecté).

3.6.1 Discussion

Le contrôled’accèsbasésurlesrôlessupposequetouteslesmanipulationssurlesdonnéesontla formed’unetransactionbienformée.Lespolitiquesdecontrôled’accèsneconsidèrentpasl’identité dusujetmaisuniquementsonrôleactif.La séparationentrel’identité dusujetet sesdroitsd’accèsdansle systèmeoffre plusieursavantages.Parexemplel’expériencedeCoulourisetDollimoremontrequel’abstractiondurôle facilite l’analysedusystèmeet l’attributiondesdroitsd’accès.Le rôleconstitueunniveaud’indirectionsupplémentaireentrelesutilisateurset lesdonnées.Cetteindirectionfacilite la gestiondupersonneld’uneentreprise.Regardonsbrièvementl’exempled’un conseillerdebanque.Chaqueconseillerauncertainnombredeclientset il a ledroit d’inspecterleurscomptes,accorderlesdécouverts,etc.Quandunconseillerdebanqueestpromu,il n’estplusresponsabledela totalitédesesclients(il peutquelquefoisgarderquelquesclientsimportants)doncil nedoit pluss’occuperd’euxetparconséquentperdrel’autorisationdemanipulerlesdonnéeslesconcernant.Danslesmodèlesqui attribuentlesdroitsd’accèsauxutilisateurs,celaimpliquele parcoursdetouslesclientset tousleurscomptespourretirerle droit demanipulercescomptespourle conseiller. Dansle modèlede


contrôlebasésurlesrôles,il suffit deretirerle droit d’assumerle rôledeconseillerpourcesclients.Le rôleprésentedoncunevuelogiquesurlesdonnéeset lesdroitsd’accès.

3.7 Modèlede la muraille deChine

Le modèledela murailledeChine[Brewer89] aétédéveloppépourrésoudrelesproblèmesdeconflit d’intérêtdanslessociétésdeservice.Il estnormalpourunconsultantd’avoir accèsàdesinformationsconfidentielles.Pouréviterqu’unconsultantpuisseenmêmetempsaccéderàdesinformationsdedeuxentreprisesconcurrentesil fautuneétanchéitécomplèteentrelesconsultantsqui travaillentpourl’une et lesconsultantsqui travaillentpourl’autre (cettepropriétéadonnésonnomaumodèle).Danscemodèlela politiquedecontrôled’accèsnedépendpasdel’identité duconsultant— lasociétédeservicedoit avoir confianceentoussesconsultants— maisuniquementdel’histoiredesaccèsauxinformationsconfidentiellesparle consultant.Lesinformationssontdiviséesenclassesdeconflitd’intérêt. Lesinformationsdansla mêmeclassedeconflit d’intérêtconcernentlesentreprisesdansle mêmedomaine.Un consultantpeutdoncaccéderàdel’information concernantdesentreprisesdedeuxclassesdeconflit d’intérêtdifférentes,maisjamaisdedeuxentreprisesdansla mêmeclassedeconflit d’intérêt.Le modèleestainsitrèsdynamique.Un nouveauconsultantcommencesacarrièresansrestrictionssurlesinformationsauxquellesil peutaccéder. Au momentoù le consultantaccèdeàdel’information concernantuneentreprise,touteslesinformationsconcernantd’autresentreprisesdansla mêmeclassedeconflit d’intérêtsontinterditesauconsultant.L’interdictiondoit persisterjusqu’aumomentoù il n’y aplusderisquedeconflit d’intérêt— la duréedel’interdiction dépenddoncdudomained’affaireet la duréedevie d’un secretcommercial.La structuredumodèleestillustrésurla figure3.3.

Société 1,P

Information sur les sociétés

Classe de conflit d’intérêt 1

Société 1,1 Société N,1 Société N,Q

Classe de conflit d’intérêt N

FIG. 3.3:Le modèledela murailledeChine

La figuremontrela basededonnéesd’unesociétédeservicequi gèredesinformationssurlesdifférentsclients.LesclientssontdivisésenN classesdeconflit d’intérêtdifférentes.Avecl’introductiond’uneclassedeconflit d’intérêtsupérieure(qui rassembletouteslesfeuillesdel’arbre), le modèlepeutêtredécritparun treillis [Sandhu93].Cetteclassedeconflitd’intérêtcombinetouslesconflitspossibleset imaginablesdusystème,doncaucunutilisateurnormalnedoit êtreassociéà cetteclasse.La classedeconflit d’intérêtmaximalepeutservirpourl’administrationdusystème(commele rôlederoot d’Unix). Elle permetparexempleaumêmesujetdefaireunesauvegardedetouslesfichierssurdisque.

3.8. MÉCANISMESDE CONTRÔLE D’ACCÈS 53

3.8 Mécanismesdecontrôle d’accès

Touslesmodèlesdécritsdanscechapitresebasentsurla matricedecontrôled’accès.Lesystèmedoit doncreprésentercettematriced’unefaçonqui peutêtreutiliséeparle moniteurderéférence.Nousallonsétudierdifférentesfaçonsdele faireparla suite.

3.8.1 Matrice decontrôle d’accès

La matricedecontrôled’accèsdécriteauparavantpeutêtrestockéedanssatotalitéparlemoniteurderéférence,maiscecin’estpastrèsefficace.La plupartdessujetsontuniquementdesdroitsd’accèssuruneminoritédesobjetsgérésparle système.La matriceestdoncnormalementcreuse.Onpeutalorsla représentersoit parcolonnes(listesdecontrôled’accès)soitparlignes(listesdecapacités).

3.8.2 Liste decontrôle d’accès

Unelistedecontrôled’accès(“AccessControlList” ou “ACL”) estassociéeàchaqueressource.Elle liste touslessujets(l’identité del’utilisateuroudurôle)qui sontautorisésàaccéderà la ressourceet leursdroitsd’accès.Touteslescellulesvidessontsupprimées.Le moniteurderéférenceautorisel’accèsà la ressourcesi le sujetestlistédansl’A CL decelle–ci.CeciimpliquequelesACLs fonctionnentuniquementsi l’identité dusujetestconnuesurle sitequi gèrela ressource.Ellesnepermettentdoncpasla collaborationentrelesutilisateursqui neseconnaissentpasà l’avancecommeparexemplelesgensqui serencontresurl’Internet,ou lesagents(utilisateursouprogrammes)mobiles.L’avantageprincipald’uneACL estqu’ellepermetfacilementderépondreà la question: “quipeutaccéderàcetteressource?” Celarendl’audit dela sécuritédesressourcesplusfacileetplussûr. C’estpourquoilescritèresd’évaluationdela sécuritéprévoientnormalementl’utilisation desACLs.La gestionet la délégationdesdroitsd’accèsposentunproblèmepourlessystèmesdeprotectionbaséssurlesACLs. Il fautqu’unsujetait le droit demodifierl’A CL pourpouvoirdéléguerundroit d’accès.Le droit demodifierl’A CL esttrèspuissant,il fautdonclimiterl’ensembledessujetsqui le possèdent.Cecia pourconséquenceunepolitiquedeprotectiontrèsstatiqueoù lesdroitsd’accèschangentpeu.L’efficacitédela vérificationdudroit d’accèsestunproblèmepourl’utilisation deslistesdecontrôled’accès.Dansunsystèmeà grandeéchellelesACLspeuventdevenir trèsgrandes,cequi impliqueuneforteconsommationdela mémoirepourle stockageetdel’unité centralepourla recherchedesentrées.

3.8.3 Liste decapacités

Unelistedecapacitésestassociéeàchaquesujet.Elle contientuneentrée(la capacité)pourchaqueressourceà laquellele sujetpeutaccéder. La capacitéidentifiela ressourceetdécritlesdroitsd’accès.Il n’existepasd’entréeassociéeà la ressourcedansla listedecapacitéssi lesujetn’a pasle droit del’utiliser. La possessiondela capacitéestnormalementuncritèrenécessaireet suffisantpouraccéderà la ressource.Il fautdoncs’assurerqu’unutilisateurnepeutpasfabriquerdescapacitéspourlesressourcespourlesquellesil n’a pasdéjàle droit.


Le moniteurderéférenceautorisel’accèssi la capacitéestvalable,c’est–à–direqu’ellen’a pasétéfabriquée.La capacitéeststockéechezle clientetellen’imposepasdebesoindestockagechezle serveur. Cestockagechezle clientposeunautreproblème; il n’estpasfacilederetirerunecapacitéparticulière.Unesolutionpossibleestdelimiter la duréedevie dela capacité,lesujetdoit doncredemanderunecapacitédetempsentempspourpouvoir continueràaccéderàla ressource.Par exemple,cettesolutionaétéréaliséeparKerberos(cf. 2.8.1)qui exigeunrenouvellementpériodiquedestickets.L’avantageprincipaldescapacitésestqu’ellesoffrentunegestiondesdroitsd’accèstrèssoupleetdynamique.Le droit dedéléguerunecapacitépeutêtreinclusdansla capacitéelle–mêmeaveclesrestrictionsnécessairespouréviterunediffusiongénérale.La listedecapacitéspermetfacilementderépondreà la question: “quellessontlesressourcesauxquellesunsujetpeutaccéder?” Parcontreil estnormalementdifficile derépondreà laquestiondequi peutaccéderàuneressourcedonnée.Il n’estdoncpasaussisimpledevérifierla sûretéd’uneressourcequ’aveclesACLs.

3.8.4 Discussion

Lescapacitésoffrentunesouplesseetundynamismedela gestiondesdroitsd’accèssupérieuràceuxdesACLs.Un exempledécritdansla documentationdeSPKImontrebienl’avantagedescapacités(ladéfinitiond’un certificatd’autorisationdeSPKIestindifférenciabledela définitiond’unecapacité).

“Considéronsle casd’un proxysur unemachinepare–feuqui permetl’accèsdetelnet et ftp entre l’Internet etun réseaudesmachinesduMinistèredela Défense.La sensibilitéduréseaumilitairenécessiteuncontrôled’accèsstrict. . . . (la discussiondel’authentificationa étéomise). . . Il fautdoncquele pare–feumaintienneuneACL quiliste touslesutilisateursqui sontautorisésà traverserle pare–feuet le moded’accèsautorisé.L’ACL elle–mêmepeutdevenir trèsgrandeetconsommerbeaucoupderessourcespoursonstockage. Deplus,il fautcontrôlerle droit demodifierl’ACL, par exempleà l’aided’uneautreACL. Il n’estpaspossiblepourquelqu’undansl’arméedeterrededécidersi quelqu’undansla marinedoit avoir unaccès.Il fautdoncuneACL à deuxniveauxpourcontrôlerl’accèsà l’ACL dupare–feu.En réalité il fautprobablementunehiérarchiedesACLs,afinderefléterla structuredesforcesarmées.Sansbesoindestocker desACLs,le pare–feupeutêtre réalisépar unemachinesansdisquedur, par exempleenfermédansunepetiteboîte. Par contre, unsystèmequisupportedesACLsa besoind’un disquedur disponiblependantla vérificationdesdroitsd’accèsaupare–feuetpendantla modificationdesACLs.(Descriptiondela délégationdescertificatsd’autorisationomise)La structuredela délégationdescertificatsreflètel’organisationduMinistèredelaDéfensecommeunehiérarchiestockéesur le disquedur dupare–feu,maisla gestiondecescertificatsestrépartieetnenécessiteaucunereprésentationdecettestructurerépliquéesur le pare–feu.La délégationdechaquecertificatestsimpleetbiencomprise,doncle logiciel qui la réalisepeutégalementêtresimple.” [Ellison99]

La protectionparcapacitéspermetderefléterla structuredel’organisationet le modèlede

3.9. PARTICULARITÉS DESAPPLICATIONS RÉPARTIES 55

protectionenvigueurendehorsdumécanismedeprotection.Cemécanismepeutdoncêtrebeaucoupplussimple,cequi réduitle risqued’unefautedeconceptionouderéalisation.

3.9 Particularités desapplicationsréparties

Outrelesparticularitésidentifiéesdansle chapitre2, lessystèmesrépartisfacilitentlacollaborationentresujetsqui neseconnaissentpasà l’avance,parexemplelesutilisateursmobilesqui visitentunelocalitépendantun tempstrèscourtou lesgroupesdetravail adhoccomposésdegensqui serencontrentsurl’Internet.Il n’estpastoujourspratiquedecréeruncomptepourquelqu’unqui visiteunsitepouruntempstrèscourt,parexemplepourfaireuneprésentationoudémontrerunproduit.Cetyped’utilisateursadesbesoinsderessourceslégitimes; il fautdonctrouverunmoyendeluipermettred’accéderauxresourcesd’un sitesansuneadministrationtrop lourde.L’Internetaprovoquéla créationdebeaucoupdegroupesdetravail composésdegensqui neseconnaissentpasà l’avance,parexemplele groupequi acrééLinux. La confianceestunepropriétéqui seformelentement; il fautdoncunmoyendetravailler ensemblesansavoir uneconfianceabsoluedanssescollaborateurs.Cesdeuxconditionssontparticulièresauxsystèmesqui dépassentle domained’administrationd’un seulesite.Ellesserésumentparlesdeuxdéfinitionssuivantes:

3.9.1 Suspicionmutuelle

Un systèmecentralisépermetd’authentifiertouslesusagersetdecontrôlerleuraccèsauxressources.Il estdoncpossiblededéfinirunepolitiquedesécuritéglobale.Lessystèmesrépartissecomposentd’un groupementdemachinesgéréesdansdesdomainesadministratifdifférents,parexempledesmachinesgéréespardifférentesfilièresd’unemêmeentreprise.La taille et la complexité d’un tel systèmesontbeaucoupplusgrandesquedansunsystèmecentraliséet la définitiond’unepolitiquedesécuritéglobalen’estpastoujourspossible.Pourrépondreàceproblème,lesdifférentssitespeuventêtreclassifiésselonle moded’interactionavecle site.Nousavonsidentifiéstroisclassesd’interactionentredeuxsites(cf. figure3.4) : la confianceabsolue,la suspicionmutuelleet l’hostilité ouverte.

Confianceabsolue

Suspicion mutuelle

Espérance d’hostilité

FIG. 3.4:Lesdifférentesclassesd’environnements


La confianceabsolueexisteengénéralentredifférentssitesdansle mêmedomaineadministratifet l’hostilité ouverteestl’espéranced’interactionsprudentesentremachinesconnectéesà l’Internet.La suspicionmutuellecouvrele spectreentrela confianceabsolueetl’hostilité ouverte.Elle permetd’ouvrir le modèledeconfianced’un siteetdecollaboreravecquelqu’unsanslui fairetotalementconfiance.Ainsi, la suspicionmutuellepermetdelimiterlesdégâtsaucasd’un abusdeconfiance.

3.9.2 Contrôle d’accèsdessujetsnon–identifiés

Le webet le commerceélectroniquenécessitentunsystèmeouvert,qui permetunaccèsrestreintauxutilisateursnon–identifiésousemi–anonymes,parexemplepourconsulterunecatalogueenligneoucommanderunproduitsurle sitewebd’uneentreprise.Deplus,uneentreprisepeutpermettreà sesmeilleursclientsdeconsulterlesnouveautésou le nombredeproduitsenstock.Cetteouvertureinformatiquedevientdeplusenplusunparamètredecompétitivité important.Il fautdoncunmoyend’ouvrir le systèmeauxclientssansleur faireuneconfianceabsolue,c’est–à–direla suspicionmutuelle.Pourpouvoir réaliserunepolitiquedesuspicionmutuelle,il fautunmécanismedecontrôled’accèstrèsflexible, qui permetauxutilisateursnon–identifiésdeprésenterunpreuvenécessaireet suffisantedeleurdroitsd’accèsàuneressource.Cettepreuvedoit êtreindépendantedel’authentificationdel’identité desusagerspourfaciliter l’interactionentresitesqui n’utilisentpaslesmêmesagencesd’authentification(“CertificationAuthority”).

3.9.3 Discussion

Danslessystèmesd’exploitationrépartis,lesmachinespeuventcoopéreravecuneconfianceabsolue.Il estdoncla responsabilitédusystèmesous–jacentausystèmedeprotectiond’assurerl’identité et l’authenticitédessujetsetdesobjets.Il n’y aalorspasdedifférencevisibleparrapportauxsystèmescentralisés.Danslessystèmescoopérants,la différenceentresitesestexplicite. Lesproblèmesdel’identification,del’authentificationetdel’autorisationdessujetsetobjetsdoiventêtreprisencompteparle modèledeprotectionet la réalisationdusystème.


Depuisle début desannées1980,la doctrinedespolitiquesmandatairesetdiscrétionnaires—établiedansle contextedessystèmesmilitaires— a lentementétémiseencausecommebaseappropriéepourle contrôled’accèsdanslessystèmescivils. L’introductiondesmodèlesdecontrôled’accèsmandataires— commelesmodèlesbaséssurlesrôlesou le modèledelamurailledeChine— dansle mondedessystèmescivils, laissesupposerqu’unmécanismedecontrôled’accèscapablederéaliserunetellepolitiqueestnécessaireaujourd’hui.Nousavonsdanscechapitreétudiéunnombredemodèlesdeprotectiondifférentset lesmécanismesqui permettentdecontrôlerl’accèsauxressources.Lesmécanismesdecontrôled’accèssebasentgénéralementsurla matricedecontrôled’accès,soit sousformedeslistesdecontrôled’accès,soit sousformedecapacités.Un systèmedeprotectionàbasedescapacitéssemblemieuxrépondreauxbesoinsdesapplicationsréparties.Lescapacitésoffrent lesavantagessuivants:


– Flexibilité del’évolutiondesdroitsd’accèsd’uneapplicationpardélégationdescapacités.

– Délégationplussimpleetplussûreparcequele droit dedéléguerundroit d’accèsn’impliquepasle droit dedéléguertouslesdroitsd’accès(commele droit demodifieruneACL).

– Supportpourla suspicionmutuelleparle changementdedomainequi permetd’exporterle droit d’opérersurlesdonnéessansexporterle droit demanipulerlesdonnées.

– Contrôled’accèsdesusagersnon–identifiésousemi–anonymes.

– Éliminationd’unereprésentationcomplètedel’organisationdansle moniteurderéférenceparla gestionrépartiedesdroitsd’accès.

Le chapitresuivantprésentelessystèmesàcapacités.

Chapitre4

Protectionpar capacités

Au coursdeschapitresprécédentsnousavonsétudiéla sécuritédanslessystèmesrépartisetplusparticulièrementle contrôled’accès.Danscechapitrenousallonsétudierle contrôled’accèsparcapacités.Cechapitreprésented’aborden4.1unebrève introductionauxsystèmesàcapacitéspuisrappellelesdéfinitionsdesdifférentstypesdesystèmesàcapacités,y comprisla définitionoriginaleselonDennisetVanHorn.Ensuite,dansla section4.3,nousprésentonsquelquesrésultatsthéoriquesetproposonsunetaxinomiedessystèmesàcapacités.La section4.4présentedeuxsystèmesàcapacitéscentralisés,le CambridgeCAPetHydra,qui ontbeaucoupinfluencélesidéessurlessystèmesàcapacités.EnsuitenousprésentonsdeuxsystèmesàcapacitésplusrécentsAmoebaetMach,dansla section4.5.La conceptiondecessystèmesmontrelesdifférentschoixdeconceptionpourunsystèmeàcapacités.La section4.6présentela conceptiondesystèmesàmémoirevirtuelle répartieunique(qui nousintéressentdanslecadredecettethèse)— qui tousbasentleurmécanismedeprotectionsurlescapacités.Enfinnousprésentonsunerécapitulationetunediscussiondansla section4.7.

4.1 Intr oduction historique aux systèmesà capacités

Lescapacitésoudescripteursontétéutiliséesdanslesordinateursbienavantla premièreformulationdela notiondecapacité.La premièredéfinitionduconceptdecapacitéaétéproposéeparDennisetVanHornen1966[Dennis66]. Cettedéfinitiondétailléeplusloin estpurementabstraite: ellenereposesuraucunmodèled’exécutionparticulier, etneprésumeenriendesréalisationspossibles.Cettedéfinitionaensuiteétérepriseetutiliséedansdifférentscontextesmatérielset logiciels,eta donnélieu a denombreusesréalisations,notammentla“ChicagoMagicNumberMachine”[Fabry74]qui étaitparmilespremiers(sinonle premier)àproposerd’utiliser lescapacitéscommemécanismededésignationgénérale.Le livre“Capability–BasedComputerSystems”parHankLevy [Levy84] présenteunpanoramahistoriquecompletdespremierssystèmesàcapacitésquenousrecommandonsvivement.Lescapacitésont étéutiliséesdansle contextedessystèmescentraliséspendantlesannées1970etdessystèmesrépartisdepuisle milieu desannées1980.Mêmesi lescritèresd’évaluationont forcélessystèmescommerciauxàadopterlesACLs,lescapacitéssontencoreutiliséesdanscertainsprototypesderecherche.Parmi lesexempleslesplusrécentsfigurentGrasshopperdéveloppéà l’Uni versitédeSydney [Dearle94a, Dearle94b],le J–Kerneldéveloppéà l’Uni versitéCornell[Chang98,vonEicken99] etEROSdéveloppéà l’Uni versité

59

60 CHAPITRE4. PROTECTIONPAR CAPACITÉS

dePennsylvanie[Shapiro99].

4.2 Définitions dessystèmesà capacités

La définitionla plusgénéraled’unecapacitéestla suivante: c’estunestructurededonnéesqui

1. désigneunobjetunique.

2. inclut del’information supplémentairepertinenteà la sécurité.

La capacitésertdoncenmêmetempsà désignerunobjetetàcontrôlerl’accèsà l’objet. Lessystèmesàcapacitésont normalementlespropriétéssuivantes:

1. La possessiond’unecapacitépermetausujetd’accéderà l’objet (aveclesdroitsd’accèsinclusdansla capacité).

2. La capacitépermetle partaged’un objet— touslessujetsqui possèdentunecapacitéquidésigneunobjetpartagentcetobjet.Différentescapacitéspeuventincluredifférentsdroitsd’accès,donclesdifférentssujetsn’ont pasforcémentlesmêmesdroitspourmanipulerl’objet.

3. Unecapacitédoit êtreimpossibleà falsifier, pouréviterla constructiond’unecapacitéqui inclut lesdroitsd’accèssouhaitésparle sujetmaisnonautorisésparle système.

Il existetroisclassesdecapacités: lescapacitésmarquées, lescapacitésconfinéeset lescapacitéschiffrées. Nousdonnonsunedescriptiontrèscourtedecesclassesavantdereveniràla définitionoriginaled’un systèmeàcapacitésproposéeparDennisetVanHorn.

4.2.1 Capacitésmarquées

Lescapacitésmarquées(“taggedcapabilities”)oudescripteurssontdesvariablesspécialesmarquéesparle système.Cettemarqueestnormalementunbit qui indiquesi le motenmémoirecontientunecapacitéounon.Le marquagenécessitedoncunsupportdumatérielpourdistinguerentrelesvariablesnormaleset lescapacités.Deplus,il fautquele systèmegarantissel’intégrité descapacités,c’est–à–direempêcherlessujetsdemodifieruneadresseenmémoirequi contientunecapacité.

Structure protégée d’une capacité

Donnée ordinaire

Base + Taille du segment, Droits d’accès

Marqueur = 0

Marqueur = x

Structure des capacités à marqueur

FIG. 4.1:Le formatd’unecapacitémarquée

Denombreuxsystèmesàcapacitésmarquéesontétéréaliséspendantlesannées1960et1970;quelquesexemplesdécritsparLevy sont: le BurroughsB5000,le ChicagoMagicNumberMachine,le CAL–TSSet le Plessey System250.

4.2. DÉFINITIONSDESSYSTÈMESÀ CAPACITÉS 61

4.2.2 Capacitésconfinées

Lescapacitésconfinées(“segregatedcapabilities”ou “partitionedcapabilities”)sontgéréesparle systèmedansuneregiondela mémoireséparée,horsdeportéedesapplications.Le systèmeempêcheainsilessujetsdemodifierunecapacité.Le formatd’unecapacitéconfinéeestillustrésurla figure4.2.

Structure libre d’une capacité

Nom de la capacité

Nom de la capacité

Informations de protection en clair

Espace utilisateur

Espace système

Structure protégée d’une capacité

FIG. 4.2:Formatd’unecapacitéconfinée

La capacitésecomposed’unepartiequi sesituedansl’espacedel’utilisateuretqui lui permetdedésignerl’objet etuneautrepartieconfinéeparle système(dansle noyauoudansunserveurséparé)qui permetdelocaliserl’objet et vérifier lesdroitsd’accèsinclusdansla capacité.

4.2.3 Capacitéschiffrées

Lescapacitéschiffrées(“encryptedsignaturecapabilities”,“sparsecapabilities”ou “passwordcapabilities”1) utilisentle chiffrementpourprotégerlesdroitsd’accèsinclusdansla capacitéouprouver l’identité deceluiqui l’envoie.

algorithme de chiffrement

Signature

Droits d’accès

Droits d’accès

Clé secrèteIdentité de l’objet

Identité de l’objet

capacité en clair

Chiffrement

capacité chiffrée

FIG. 4.3:Le formatd’unecapacitéchiffrée

Le systèmestockenormalementuneclésecrèteavecl’objet pourpouvoir vérifier lescapacitésplustard.Il fautdoncconnaîtrecetteclésecrètepourfaireunesignaturevalidedela capacité.

1Le nom “password capability” a été utilisé pour décrire une capacitéqui contient un mot de passeenclair [Anderson86]. Cetteméthoden’est passûredansun systèmerépartimaisfonctionnebiendansle contexted’un multi–processeur.


Si lescapacitéssontgéréesparle système,celui–cipeututiliser le chiffrementsymétriqueouunefonctiondehachageàsensuniquepoursignerla capacité.Si lescapacitéssontgéréesparlesutilisateurs,le systèmedoit stockerunecopiedela clépubliqueavecl’objet pourpouvoirvérifier la signaturefaiteavecla clésecrètedel’utilisateur. Le systèmepeutstockerplusieursclésdifférentesavecl’objet pourpouvoir distinguerlesdroitsaccordésà desutilisateursdifférents.

4.2.4 Définition originale selonDenniset Van Horn

La définitiond’un systèmeàcapacitésproposéeparDennisetVanHornsebasesurlestroisnotionssuivantes:

le segment, qui sedéfinitcommeunezonedemémoirecontiguë

l’ activité, qui définitunflot d’exécutionquelconque

le processus, qui représenteuncontexted’exécution,unesphèredeprotectiondanslaquelles’exécutentuneouplusieursactivités

La sphèredeprotectiondéfinit le contextedeprotectiondetouteslesactivitésqui s’exécutentdansla sphère.Elle définit l’ensembledessegmentsaccessiblesparlesactivitésduprocessus,l’ensembledesentrées/sortiespossibles,etdefaçongénérale,l’ensembledesobjetsaccessiblesdanscecontexte.La capacitésecomposed’un nom(unechaînedebits)uniquequi identifiel’objet. Le nompermetdedésignerl’objet maispasdele localiser(le nomestindépendantdel’adresseeffectivedel’objet).Lesdroitsd’accèsinclusdansla capacitédépendentdu typedel’objet. Deplus,la capacitéindiqueaussisi sondétenteurestpropriétairedel’objet. Le propriétairepossèdelesdroitsspéciauxcommeparexemplele droit dedétruirel’objet.UneseuleC–liste(listedecapacités)estdéfiniepourchaqueprocessus.Cettelistepeutêtrepartagéeentreplusieursprocessus.Le modèlepermetdedéfinirunehiérarchiedeC–listes(etdesphèresdeprotectioncorrespondantes)avecdescapacitésdifférentes.LesdroitsnormauxdemanipulationdesC–listessontlessuivants:

– uneactivité peutajouterdescapacitésdanssaC–listeoudansla C–listed’unesphèredeprotectiondeniveauinférieure

– uneactivité peutactiverouarrêterunprocessusdeniveauinférieur

– uneactivité peutsupprimerunecapacitédansuneC–listed’unesphèredeprotectiondeniveauinférieur

Unecapacitéd’entréepermetausujetd’appeleruneprocédure(appeléeuneprocédureprotégée)dansuneautresphèredeprotection.Ainsi, la procédureprotégéepermetdechangerle contextedeprotection.Le processusappelantestsuspendupendantla duréedel’appel.L’appeldeprocédureprotégéepermetégalementdepasserunecapacitéenparamètreentrel’appelantet l’appelé(la capacitépeutêtreunecapacitésuruneC–liste).Onretrouve lesnotionsdecapacitéd’accès,capacitésd’entréeet sphèredeprotection(souventappeléeundomainedeprotection)dela définitionoriginaled’un systèmeà capacitésselonDennisetVanHornedansla plupartdessystèmesàcapacités.

4.3. QUELQUESRÉSULTATSTHÉORIQUES 63

4.2.5 Discussion

Danstouslestypesdecapacitésdécritsci–dessus,le formatd’unecapacitéinclut trois typesd’information: la désignationd’un objet,lesdroitsd’accèsàcetobjetet lesdroitsdemanipulerla capacitéellemême— parexempledela copieroudela délégueràquelqu’und’autre.

4.3 Quelquesrésultats théoriques

Lesétudesthéoriquesdessystèmesàcapacitéspermettentd’analyserleurspropriétésetdeclassifiercessystèmes.Certainesdecesétudessontprésentéesdansla suite.

4.3.1 Un modèleformel dessystèmesà capacités

Lesdescriptionsdessystèmesàcapacitéssontsouventinformellesetellessontdominéesparlesdétailsdela réalisation.Lesquestionssuivantesnesontnormalementpasconsidéréesdansla descriptiond’un système,mêmesi ellessontsouventposéesparlesutilisateurs.

1. Est–cequele systèmelimite réellementl’accèsauxressourcesà ceuxqui sontautorisésà y accéder?

2. Estcequele systèmesupportelesmodesnormauxdepartagedel’information?

3. Sousquellesconditionsl’information peut–elleêtredisséminéeà l’intérieur dusystème?

4. Quellepolitiquedecontrôled’accèsestréaliséeparle système?

CetteobservationapousséLawrenceSnyderàproposerunmodèleformeldessystèmesàcapacités[Snyder81].Le modèlesebasesurungrapheorientéoù lesnœudsreprésententlesentitésdusystème(sujetsetobjets)et lesarcsreprésententlescapacités.Pourdistinguerentresujetsetobjets,Snyderproposedecolorerlesnœudsdessujetsennoir et ceuxdesobjetsenblanc.Lesarcssontannotésaveclesdroitsinclusdansla capacité.Un exemplesimpleestillustrésurlafigure4.4.

lire lirelire-écrire

S2

O1 O2

S1 entrer

FIG. 4.4:Un systèmesimpleàcapacités

La figuremontredeuxsujetsS1 etS2 etdeuxobjetsO1 etO2. S1 possèdeunecapacitédelecturepourO1 etuneautredelecture–écriturepourO2. S2 possèdeunecapacitédelecturepourO2 etunecapacitédechangementdedomaineversS1.Snyderdéfinitégalementunensembledestransformationslégalesdugraphequi correspondentà l’utilisation età la délégationdescapacités.Lestransformationslégalesdépendentdumodèleàcapacitésparticulier.Pourmontrerla sûretéd’un système,il fautdoncmontrerqu’il n’existepasuneséquencedetransformationslégalesqui transformele graphed’un étatsûràunétatnon–sûr.


4.3.2 Une taxinomie dessystèmesà capacités

Unetaxinomiedessystèmesàcapacitésa étédéveloppéeparKain etLandwehr[Kain86].Cettetaxinomiepermetdedécriredesdifférentsmodèles(ouréalisations)decapacitésdanslessystèmescentralisés.

Modèledecapacités

Unecapacitéestuneréférencesystèmequi désigneunobjetetspécifielesdroitsd’accèsaccordésàceluiqui présentela capacité; unsujetsansdroitssurunobjetpeutposséderunecapacitévide.

Description de la taxinomie

La taxinomieestbaséesuruneanalysedesdifférentsévénementsclésdansla gestiondesobjetsetdescapacités.Kain etLandwehront identifiécinqquestions,auxquelleslesréponsesserventdebaseà la taxinomie.Lesquestionssontlessuivantes:

1. quesepasse-t-illorsdela créationd’un objet?

2. quesepasse-t-ilquandlesattributsdesécuritéd’un objetchangent?

3. quesepasse-t-ilquandunecapacitéestcopiée?

4. quesepasse-t-ilquandunecapacitéestprésentéeausystème?

5. quesepasse-t-ilquandunsujetessaied’accéderàuneressourceprotégée?

Kain etLandwehrprétendentavoir trouvéunensembledesréponsesassezgénériquespourpouvoir classifiertouslessystèmesàcapacités.Cetteclassificationestprésentéeparla suite.

Classificationdessystèmes

La classificationsebasesurlesréponsesdonnéesauxquestionsci–dessus.

Question1 : À la créationd’un objetuneréférence(capacité)estnormalementretournéeaucréateur. Lesdroitsd’accèsducréateurpeuventêtreinclusdanscettecapacité,sinonil fautunmécanismepourlesy inclure.Kain etLandwehridentifientlesoptionssuivantes:

a) aucundroit d’accèsn’estinclusdansla capacité

b) lesdroitsd’accèssontinclusdansla capacité

Dansle cas(b), lesdroitsd’accèssontnormalementtouslesdroitspossibles.Le créateurd’unobjetestnormalementconsidérécommele propriétairedel’information etdoit êtreautoriséàtout faire.

Question2 : Kain etLandwehridentifientdeuxcasparticuliersqui méritentuneréponseséparée.Si la capacitéestcourammentutiliséepouraccéderàunobjet,ellenepeutpasêtremodifiéeparcequecelapeutinvalideruneréférenceetprovoqueruneerreurà l’exécution.Sila capacitén’estpasutilisée,ellepeutêtremodifiéeparle systèmepourrefléterle changementdela classificationdel’objet. Quandlesattributsdesécuritéd’un objetchangent,troiscassontpossibles:


a) lesdroitsd’accèsnesontpasmodifiés

b) la capacitéestmarquéepourmodificationultérieurement

c) la capacitéestmodifiéetoutdesuite.

Le problèmedechangementdela classificationdela confidentialitéestparticulieraumodèledecontrôled’accèsmilitaire. Enréalitéil n’estpasl’objet debeaucoupd’attentiondanslessystèmesàcapacitésetneméritedoncpasd’êtrereprésentédirectementdansunetaxinomie.Kain etLandwehrsupposentquelescapacitésdoiventêtremodifiéespourrefléterla nouvelleclassificationdel’objet. Enréalitéla plupartdesréalisationsdessystèmesàcapacitésrépartisreposentsurunerévocationtotaledescapacitésetunenouvelledélégationdecapacitéspourl’objet. Cettenouvelledélégationpeutprendreencomptela nouvelleclassificationdel’objet.

Question3 : Le modèledecapacitéspermetàunsujetqui possèdelesdroitsd’accèsnécessairesdecopierunecapacitéd’un objetversunautre.Lesdroitsnécessairessont: ledroit delire l’objet qui contientla capacitéet le droit d’écrirel’autreobjet.Si l’autreobjetestpartagé,ceciconstitueeffectivementunedélégationdesdroitsd’accès.Quatrecassontpossibles:

a) lesdroitsd’accèsdela copienesontpasmodifiés

b) lesdroitsd’accèsdela copiesontlimitésparunepolitiquepardéfautdusystème

c) lesdroitsd’accèsdela copiesontle maximumpermispourle sujetqui reçoitla capacitéselonla politiquedesécurité

d) lesdroitsd’accèsdela copiesontmodifiésparlesprocéduresdeconfiance(“trustedsoftware”)

Unepolitiquepardéfautdusystèmepeutêtredepermettreuniquementlescopiesavecdesdroitsd’accèsinférieursàceuxdel’original. Celaimpliqueunelimite surlesdélégationspossiblesd’unecapacité.

Question4 : L’utilisation d’unecapacitéestdiviséeendeuxphases,la préparationetl’utilisation. Dansla phasedepréparationle sujetdéclaresonintentiond’utiliser la capacité;parexempleil peutla chargerdansun registredel’unité centraledédiéauxcapacités.Cettephasedepréparationpermetausystèmedevérifier la validitédela capacitéavantl’utilisation.Troiscassontpossibles:

a) le systèmeaccordetouslesdroitsinclusdansla capacité

b) le systèmelimite lesdroitsd’accèsaccordésselonunepolitiquepardéfautdusystème

c) Le systèmelimite lesdroitsd’accèsaccordésselonla politiquedesécuritéenvigueur.

Question5 : Quandunsujetessaied’accéderàuneressourceprotégée,troiscassontpossibles:

a) aucunevérificationn’estfaite

b) l’opérationestcomparéeaveclesopérationspermisesparla capacité

c) lesdroitsd’accèsmaximauxsontcalculéscommefonctiondela capacitéet lesattributsdesécuritédusujetetdel’objet ; si l’opérationestinclusedanscesdroitsmaximaux,ellepeutsedéroulernormalement


Discussion

La taxinomiedeKain etLandwehrestconçuepourclassifierlessystèmesdecapacitéscentralisés.Cetteclassificationn’estpasapplicabledansle contextedessystèmesrépartis.La question2 supposequele systèmepeutidentifieretmodifiertouteslescapacitésquiréférencentunobjetquandlesattributsdesécuritédel’objet changent.Dansbeaucoupd’architecturesà capacitésréparties,lescapacitéssontréaliséespardesstructuresdedonnéesnormales,indistinguablesd’autresdonnées.Ceciestparexemplele casdansla plupartdessystèmesàcapacitéschiffrées.La séparationdel’utilisation dela capacitéenpréparationetaccèspermetuncontrôled’accèsplusefficacedanslessystèmescentraliséset lessystèmesd’exploitationrépartis.Lapréparationpermetausystèmedevérifier la capacitéetdemettreenplacedesstructuresquidécriventlesdroitsd’accèsdusujetpourl’objet. Il suffit doncpourlescontrôlesd’accèssuivantsdevérifiersi le moded’accèscorrespondavecdesstructuresmisesenplacepourlesujetet l’objet. L’opérationsurunfichieropen(2) d’Unix enestunbonexemple.L’appeld’open(2) vérifie lesdroitsdusujetsurle fichieretmetenplaceuneentréepourle fichierdansle tableaudesfichiersduprocessus.Touteslesopérationssuivantessefont autraversdecetteentréedansle tableaudesfichiers.Un autreproblèmedecettetaxinomieestqu’ellesupposedesACL auniveaudesobjets,quipeuventêtreutiliséesparlespolitiquesdesécurité.Le rôledecesACL n’estpasbiendéfini,etleurutilisationpeutcacherdesaspectsimportantsdusystème.Parexemplel’utilisation desACLssembleêtrele seulmoyenderévoquerlescapacités.L’impossibilitédeclassifierlarévocationdescapacitésestdoncunautreproblèmedecettetaxinomie.

4.3.3 Unenouvelle taxinomie dessystèmesà capacitésrépartis

Lesproblèmesdela taxinomieidentifiésci–dessusnousontconduitàproposerunenouvelletaxinomiepourlessystèmesàcapacitésrépartis.Cettetaxinomieestdécritedansla suivante.

Modèledecapacités

Nousproposonsd’utiliser le mêmemodèleàcapacitésqueKain etLandwehr, c’est–à–direqu’unecapacitéestuneréférencesystèmequi désigneunobjetet spécifielesdroitsd’accèsaccordésàceluiqui présentela capacité,undomainedeprotectiondéfinit l’ensembledecapacitésà la dispositiond’un sujetetunecapacitédechangementdedomainepermetdepasserd’un domaineàunautredemanièrecontrôlée.

Description de la taxinomie

Noussuivonsla mêmedémarchequeKain etLandwehr, c’est–à–direquenousallonsidentifierlesévénementslesplusimportantspourla gestiondescapacités.Dansnotretaxinomie,chaqueclassificationdoit êtremotivéeparunedescriptioncourtedumodèledeprotectionmisenœuvreparle système.Lesévénementsidentifiéssontlessuivants:

1. quesepasse-t-ilà la créationd’un objet?

2. commentpeut-onmanipulerlescapacités?


3. commentpeut-onréaliserunchangementtemporairedesdroitsd’accèsd’un sujet?

4. commentpeut-ondéléguerunecapacité?

5. commentpeut-onrévoquerunecapacité?

6. commentsontvérifiéeslescapacités?

7. quesepasse-t-ilquandunsujetessaied’accéderàuneressourceprotégée?

Classificationdessystèmes

Création d’un objet : NousproposonsdegarderlesdeuxclassesdéfiniesparKain etLandwehr:

a) aucundroit d’accèsestinclusdansla capacité

b) lesdroitsd’accèssontinclusdansla capacité

Manipulation descapacités: Lessystèmesautorisentnormalementlessujetsà manipulerlescapacités,parexempleà lescopieretà lestransférerentreeux.Dansle casdescapacitésconfinées,toutemanipulationnécessitel’interventiondusystème.L’interventiondusystèmen’estpastoujoursnécessairedansle casdescapacitéspubliques,parexemplelesclientsetserveurspeuventsigneret vérifier lescapacitéseux–mêmes.L’utilisation descapacitéspubliquesn’exclut pasl’interventiondusystème(parexemplele stockageetvérificationdescapacitéspeuventêtrefaitsauniveaudel’utilisateur)maisla créationet la modificationdescapacitéspeuventnécessiterl’interventiondusystème.Un point trèsimportantdanscecontexteestle transfertdescapacités.Si le transfertsefait sansinterventiondusystème,il vaêtredifficile deréaliserunepolitiquedeprotectionmandataire2.Nousavonsidentifiédeuxclassesdecomportementdifférentespourla manipulationdescapacités:

a) lescapacitéspeuventêtremanipuléessansinterventiondusystème

b) l’interventiondusystèmeestnécessairepourla manipulationdescapacités

Changementdesdroits d’accès: Le changementtemporairedesdroitsd’accèscorrespondeffectivementàunchangementdudomainedeprotectiondusujet(ousimplementunchangementdedomaine).Le changementdedomaineapourbut depermettreuneamplificationouunerestrictiontemporairedesdroitsd’accèsdusujetpendantl’exécutiondesopérationssensibles.Le changementdedomaineestnormalementassociéàcertainesopérationssurunobjet; cesopérationssontnormalementappeléesdesprocéduresprotégées.Le systèmepermetausujetdechangersesdroitsd’accèspendantla duréedel’appeld’uneprocédureprotégée.Le changementdudomainepeutêtreréalisédetrois façonsdifférentes:

a) l’ extensiontemporairedesdroitsd’accèsdusujet

b) la restrictiontemporairedesdroitsd’accèsdusujet

2La réalisationd’unepolitiquemandatairen’estpasimpossibleà réalisermêmesi le systèmen’imposepasdelimites auniveaudetransfertdescapacités.Il fautdanscecasquele systèmelimite lescopiesdescapacités,parexempleparle chiffrementqui rendla capacitéinutilisablepourquelqu’unqui nedoit pasavoir le droit d’accéderauxdonnées.


c) l’ isolationdel’opérationdansundomainedeprotectionséparépendantl’exécutiondel’opération

Appelonsla C–listecourantedusujet N actuel, la C–listenormaledusujet N normaletsupposonsquelesdroitstemporairespuissentêtredécritsparuneC–liste N temporaire.Le changementdedomainepeutdoncêtredécritparlesformulessuivantes:

a) N actuel O N normal P N temporaire

b) N actuel O N normal Q N temporaire

c) N actuel O N temporaire3

La plupartdessystèmespermettentdepasserquelquesdroitsd’accèssupplémentairesaudomaineisolédansl’appeldela procédureprotégée.

Délégation: La délégationestunegénéralisationdela copied’unecapacitéutiliséedanslataxinomiedeKain etLandwehr.

a) Le transfertdela capacité.Ceciimpliquequela capacitésoit suppriméedansle domainedeprotectiond’origineet inséréedansle domainedeprotectionqui la reçoit.

b) La copiedela capacité.Ceciimpliquequela capacitésoit copiéedudomainedeprotectiond’origineet inséréedansle domainedeprotectionqui la reçoit.

Danslesdeuxcasle systèmepeutimposerlesrestrictionsproposéesparKain etLandwehrsurle droit d’accèsinclusdansla capacitéetsurle droit demanipulerla capacitéelle–même.

Révocation: La révocationestunpointdifficile detouslessystèmesàcapacitésetenparticulierdessystèmesàcapacitéschiffrées.Le systèmen’a querarementlesmoyensnécessairespouridentifieret supprimerunecapacitédansla mémoired’un processus.Larévocationestdoncnormalementfaiteaumomentdela vérificationdela capacité.Nousavonsidentifiétroisclassesderévocationdifférentes:

a) révocationenblocdetouteslescapacitéspourunobjet

b) révocationsélectivechezle sujet

c) révocationsélectivechezl’objet

La révocationenblocestla plusfacileà réaliser. Lorsdela création,unmotdepasse(unechaînedecaractèresouunnumérodeversiondel’objet) associéà l’objet estinclusdanslacapacité.La vérificationdela capacitédoit donccomparerle motdepasseinclusdanslacapacitéavecceluistockéavecl’objet ; s’il y aunedifférencela capacitén’estplusvalable.Ilsuffit doncdechangercemotdepassestocké(augmenterla versiondel’objet) pourrévoquertouteslescapacitésqui référencentl’objet. Il fautdoncquelessujetsqui doiventgarderleursdroitsd’accèsà l’objet obtiennentunenouvellecapacitépourpouvoir accéderà l’objet.La révocationdela capacitéchezle sujetn’estpastoujourspossible.Elle nécessitequele sitequi gèrel’objet arriveà inspecteret supprimerd’unefaçonfiabletouteslescapacitésstockéessurle système.Lessystèmesd’exploitationrépartisqui utilisentlescapacitésconfinéessontuncasspécialqui permetcetteopération.

3La définitiondel’isolation donnéeici necorrespondpasforcementauconfinement(cf. 2.3),parexempleonn’imposepasque R actuelS R temporaireT�U .


La dernièrepossibilitéestdestockeravecl’objet unelistederévocationdescapacités(cettelisteestappeléeune“capability revocationlist” ou “CRL” dansle contextedeSPKI [Ellison99]). Il suffit d’inclure la capacitédanscettelistepourla révoquer. La CRLmarchedonccommeuneACL négative.Cettesolutionn’estnormalementpastrèssatisfaisanteparcequ’ellesouffre desmêmesinconvénientsquelesACLs.La taille dela CRL augmenteavecchaquecapacitérévoquée; uneentréenepeutjamaisêtresupprimée,parcequecelarendànouveaula capacitévalable.

Vérification : Quandunsujetprésenteunecapacitéausystème,cederniervad’abordvérifier la validitédela capacitépuislesdroitsd’accèsspécifiésparla capacitévontêtreaccordésausujet.LesactionspossiblessontessentiellementcellesidentifiéesparKain etLandwehrpourla préparationd’unecapacité,c’est–à–dire:

a) le systèmeaccordetouslesdroitsinclusdansla capacité

b) le systèmelimite lesdroitsd’accèsaccordésselonunepolitiquepardéfautdusystème

c) Le systèmelimite lesdroitsd’accèsaccordésselonla politiquedesécuritéenvigueur.

Accèsaux objets : NousproposonsdegarderlestroisclassesdéfiniesparKain etLandwehr:

a) aucunevérificationestfaite

b) l’opérationestcomparéeaveclesopérationspermisesparla capacité

c) lesdroitsd’accèsmaximauxsontcalculéscommefonctiondela capacitéetdesattributsdesécuritédusujetetdel’objet ; si l’opérationestinclusdanscesdroitsmaximauxellepeutsedéroulernormalement

La séparationentrevérificationet contrôled’accèsa étéintroduiteparKain etLandwehrpourdécrireuncertainnombred’architecturesdecapacitéscentralisées,où il fautchargerlacapacitédansun registrespécialavantdel’utiliser. Cettedistinctionn’existenormalementpasdansunsystèmeréparti,parcequ’il n’existepasdesupportmatérielpourlescapacités(lescapacitéssontnormalementréaliséesparlogiciel). La séparationrestetoujoursintéressanteparcequ’ellepermetdedistinguerentrela vérificationinitiale dela capacitéet lesutilisationssuivantes.Le résultatdela vérificationpeutêtrela constructiond’un canaldecommunicationsûr(pourtransférerl’information) entrele sitedusujetet le sitedel’objet. Touslesmessagesqui arriventparcecanalcorrespondentà la capacitédéjàvérifiéeetpeuventêtresoumisà uncontrôled’accèsrudimentaire(le contrôled’accèsauxobjetsproposéici).

Discussion

L’utilité denotretaxinomieestd’aborddefocalisernotreattentionsurlesévénementslesplusimportantsd’un systèmeàcapacités.Nousneprétendonspasavoir prouvéquela taxinomieestcomplèteni pouvoir utilisercettetaxinomiepourfairedespreuvesformellesdescaractéristiquesd’un systèmeàcapacités.Cespreuvessortentducontextedecettethèse.Un résultatfacileàvérifierestquelessystèmesclassés“ ?a?????” (touteclassepeutêtresubstituéeàun ’ ?’) sontincapablesderéaliserunepolitiquedeprotectionmandataire(outrelapolitiquetrivialequi interdit la communicationentresujets).Si l’interventiondusystèmen’estpasnécessairepourlesmanipulationsdescapacités,le systèmenepeutpasimposerde


restrictionssurla délégationdescapacités.Le systèmeestdoncincapabled’éviteruneviolationdela politiquedeprotectionparunsujetqui donneunecapacitéàquelqu’unqui nedoit pasavoir l’accèscorrespondants.

4.3.4 Capacitésaugmentées

LescapacitésaugmentéesontétéproposéesparKargeretHerbert[Karger84] pourpouvoirréaliserunepolitiquedecontrôled’accèsmandataire,parexemplecelledeBell etLaPadula4.Le systèmesebasesurle modèleàcapacitésclassiqueaveclesdomainesdeprotection,lescapacitésd’accèset lescapacitésdechangementdedomaine.Lescapacitessontvérifiéavantl’utilisation et lescapacitésverifiéessontmisesdansuncachedecapacités.Le systèmedéfinitundomainedeprotectionparticulier(unmoniteurderéférence— “SecurityKernelDomain”)qui intervientaumomentdela vérificationd’unecapacité,parexempleprovoquéparuneinterruptionlogiciellequandle systèmechargeunecapacitédansle cache.Cedomainedeprotectionspécialdoit s’exécutersansrestrictionspourpouvoir vérifierquetouteslesutilisationssontconformesaumodèledecontrôled’accès.Remarquonsquelesrestrictionsimposéessurl’utilisation descapacitésdoiventêtrefaitesdynamiquement; undomainedeprotectionpeutdoncposséderdescapacitésqu’il n’a pasle droit d’utiliser danssoncontextecourant.Pourpouvoir réaliserunepolitiquedecontrôled’accèsmandataire,le systèmeclassifietouslessujetset lesobjets,parexempleselonla classificationmilitaire (cf. tableau3.1).Au momentduchargementdela capacitédansle cachedescapacités,le systèmevérifiequelesdroitsd’accèsinclusdansla capacitésontconformesaumodèle.Si lesdroitssonttrop faiblesparrapportauxdroitsrequis,le systèmeretourneunmessaged’erreuret si lesdroitssonttropélevés,le systèmelimite lesdroitsà ceuxpermisparle modèle(cf. figure4.5).

classification "bas"

Classe bas Classe bas

Procédure protégée,

rw-rw-

Classe A

r-- rw-

en paramètre

droits d’accès pourdeux fichiers d’une

Fichiers

Droits effectifs (r)Droits effectifs (r)Droits effectifs (rw)

Droits effectifs (rw)

Capacités locales

confidentialité A, droits

capacité pour le fichier

Domaine A, classe de

d’accès sur le fichier (lire et écrire)

Appelle une procédureprotégée, et passe la

FIG. 4.5:Contrôled’accèsmandataire

La figuremontreundomainedeprotectionqui s’exécuteavecuneclassificationde

4Le systèmeproposéinclut égalementunecominaisondescapacitéset les ACL pour permettreun contrôled’accèsdiscrétionnaire.Nousnedétaillonspascetteextensionparcequ’elle estmoinsgénéralequele modèledecapacitésd’Angel (cf. 4.6.3)décritplusloin.


confidentialitéA ; classebas V classeA V classehaut. Cedomaineappelleuneprocédureprotégéequi possèdedesdroitslocauxsurdeuxfichiersdansla classebas, y comprisle droitd’écrireundecesfichiers.L’écritureversle basn’estpaspermiseselonle modèledeBell etLaPadula,le domainedemoniteurderéférencevadonclimiter lesdroitseffectifsà la lectureseule.La possessiond’unecapacitén’estdoncplusuneconditionnécessaireet suffisantepouraccéderà la ressource(ellen’estplussuffisante),il fautquel’utilisation dela capacitésoitautoriséeparla politiquedesécurité.

4.3.5 ICAP — l’identité inclusedansla capacité

Le systèmeICAP estunsystèmeàcapacitéproposéparLi Gong[Gong89a, Gong89b] quipermetdesurveiller, coordonneretenregistrerla propagationdescapacitéset réaliserunepolitiquedecontrôled’accèsmandataire.ICAP utiliseun formatdecapacitéchiffréeoù l’identité deceluiqui estautoriséàutiliser lacapacitéestchiffréeaveclesdroitsd’accèsdansla signature.Deplusil fautquela signaturesoit faiteparunserveurd’autorisation(“accesscontrolserver” ou “ACS”), l’A CSn’estpasforcementidentiqueauserveurdel’objet (celuiqui gèrel’objet).Quandunobjetestcrééparunserveurd’objets,ceserveurvaenvoyer le motdepassedel’objet à l’A CSqui l’enregistre.Cemotdepassepeutensuiteêtreutiliséparl’A CSpourcréerdesnouvellescapacités.Pourdéléguerunecapacitéd’un sujet WYX àunsujet W(Z , il fautque WYX envoieunerequêteauserveurpourlui demanderdeconstruireunecapacitépour W(Z . La requêtecontientla capacitéetl’identité de W(Z . L’ACSvérifiequela délégationestpermiseselonla politiquedesécurité,puisil construitunenouvellecapacitéuniquementutilisablepar W(Z .La vérificationdela délégationdescapacitésparl’A CSpermetparexempled’assurerunepolitiquedecontrôled’accèsmandataire.La politiquedesécuritéestdoncvérifiéequandunecapacitéestdéléguéeaulieu d’êtrevérifiéeaumomentdel’utilisation commedanslescapacitésaugmentées.Cechoixestfait parceque:

“Notre intuition nousdit quele nombrededélégationsestnormalementbeaucoupmoinsgrandquele nombred’utilisations.Il sembledoncplusefficacedevérifier la capacitéaumomentdela délégationau lieu dela vérifieraumomentdel’utilisation” [Gong89a].

DansICAP la capacitéestuneconditionnécessaireet suffisantepouraccéderà la ressourcesile sujetpeutprouverqu’il estbiencelui inclut dansla capacité.Cettevérificationestbeaucoupplussimpleà réaliserdansunsystèmerépartiquela vérificationdela classificationdessujetsetdesobjetsnécessairedansle contextedescapacitésaugmentées.

4.3.6 Capacitésactives

Lescapacitésactivesontétéproposéesparle “SystemSoftwareResearchGroup”àl’universitéd’Illinois à Urbana–Champaign[Tock94, Campbell96] pourrépondreauproblèmedecontrôled’accèsdansun réseauouvertàgrandeéchelle,parexemplel’Internet.Cetypederéseausecaractérise,entreautre,paruneaugmentationcontinuelledunombredeprotocolesetdestypesdeservices.Il fautdoncquela sémantiquedesdroitsd’accèsinclusdansla capacitépuisseévoluerpourpermettredesnouveauxmodesd’accès.


L’idéegénéraled’unecapacitéactiveestderemplacerlesdroitsd’accèstraditionnelsparunscriptdevérificationdesdroitsd’accès.Le sujetqui souhaiteaccéderàuneressourceprotégéeprésenteunecapacitéactiveausystème.Le systèmepassela capacitéaugestionnairedesécurité(“SecurityManager”)qui vérified’abordl’intégrité dela capacitéactiveparsasignaturedigitaleavantd’interpréterle scriptpourretirerlesdroitsd’accèsinclusdanslacapacité.Aprèscettevérificationle systèmepassel’identificateurdel’objet et l’opérationauserveurqui gèrel’objet (“ObjectManager”).La structuredusystèmeestprésentéesurlafigure4.6.

caca ca

Ser

veur

de

l’Obj

et

Gestionnaire de sécurité

Sujet

OID+OP

OID+OP OID+OP

OP OPOP

CA : capacité active OID : Identificateur objet OP : Operation

Ser

veur

de

l’Obj

et

FIG. 4.6:Le modèledescapacitésactives

La figuremontreunsujetqui possèdedescapacitésactivespourtroisobjetsgéréspardeuxserveursdifférents.Le gestionnairedesécuritévérifiecescapacitésavantdepasserl’OID etl’opérationauserveurqui gèrel’objet.Un avantagedecetteapprocheestqu’ellepermetd’exprimerunepolitiquedecontrôled’accèspluscomplexe,parexempleinterdirel’accèsauserveursi la chargeesttropélevée,restreindrel’accèsauxheuresdetravail, etc.Cespolitiquessonttoutesdifficilesàexprimeraveclescapacitéstraditionnelles.

4.4 Systèmescentralisés

Lessystèmesàcapacitéscentralisésoffrentuneplate–formecommuneauxtouteslesapplications.Lescapacitésreposentsouventsurunsupportmatériel(capacitésmarquées)ouunsupportdunoyau(capacitésconfinées).

Remarque! Un systèmecentralisépermetdevérifierunecapacitéavantla premièreutilisation,puisassocierlesdroitsd’accèsinclusdansla capacitéauprocessusqui aprésentélacapacité.Cecipermetd’amortir le coûtdela vérificationsurtoutesutilisationsdela capacité.

Nousprésentonsunsystèmequi profited’un supportmatérielpourla gestiondescapacitésetunsystèmedecapacitésconfinéesdansla suite.

4.4. SYSTÈMESCENTRALISÉS 73

4.4.1 Cambridge CAP

L’ordinateurCambridgeCAPaétéconstruità l’Uni versitédeCambridgeenAngleterreaudébut desannées1970[Needham77]. Un objectifdela conceptiondecesystèmeétaitderendrela manipulationdescapacitéstransparenteauxprogrammeurs,c’est–à–direquelacapacitésertdedésignationetquele chargementet la vérificationdessegmentsdecapacitéssefont demanièretransparente.

Description du systèmedeprotectiondeCambridge CAP

La conceptiondusystèmesuit le modèleàcapacitésproposéparDennisetVanHorn.Leprocessusconstituele contexted’exécutionetdeprotection(la sphèredeprotection).Lescapacitéscontrôlentl’accèsauxsegments.Lescapacitéssontconfinéesdansdessegmentsdemémoired’un typeparticulier. La notiondesegmentdecapacitéscorrespondà la C–listedansle modèledeDennisetVanHorn.Le systèmeCAPfournit 16 registresdesegmentqui permetàunprocessusd’utiliser lescapacitésstockéesdans16segmentsà la fois.Lesprocessussontorganisésselonunearborescenceoùchaqueprocessuscontrôletoussessous–processus.La racinedecettearborescenceestuneentitésystèmequi s’appellelecoordinateurmaître(“mastercoordinator”ou “MC”).Le contextedechaqueprocessuscontientunelistedetouteslesressourcesdisponiblesauprocessus(“processresourcelist” ou “PRL”) ; cettelisten’estpasmodifiableparle processus.Lesentréesdela PRLd’un processuspointentversdescapacitésdansle processusqui l’acréé; unprocessusnepeutdoncjamaisposséderunecapacitéqui n’estpasdisponibleàsonparent.Unecapacitépointeversuneentréedansla PRL,qui pointeàsontourversunecapacitédansle processuspèreetainsitransitivementjusqu’auMC. La listedesressourcesdumaître(“masterresourcelist” ou “MRL”) donneaccèsauxressourcesphysiques.Ainsi lescapacitésn’ont qu’unesignificationlocaleetnepeuventpasêtretransféréesentreprocessus.L’appeldesprocéduresprotégéespermetd’amplifieroudedégraderlesdroitsd’accèspendantl’exécutiondela procédure.Lesdroitsd’accèsd’uneprocédureprotégéedépendentdelaprocédureet l’identité del’appelantetdel’appelé.Lesprocéduresprotégéessontainsiutiliséespourcontrôlerl’accèsauxressourcessystèmescommeparexemplelesentrées/sorties.

Format descapacités

Index de la capacité dans la PRL Adresse de base du segment

Taille du segmentDroits d’accèsWUType

FIG. 4.7:Le formatdescapacitésdeCAP

La capacitémontréesurla figure4.7spécifiel’index dela capacitédansla PRLduprocessus,l’adressedebasedusegment,le typedela capacité(capacitéd’accèspourunsegment,capacitéd’entréepouruneprocédureprotégée,etc.)le bit–mapWU qui indiquequelesegmentaétémodifié(W) ouutilisé (U), et la taille dusegmentautoriséausujet.L’adressede


baseet la taille peuventêtreutiliséspourraffiner l’accès,c’est–à–direréduirela taille delafenêtresurle segmentauquelle sujetpeutaccéder.

Création d’un objet : Lorsdela créationd’un segmentdemémoirele systèmeretourneunecapacitéqui inclut touslesdroitssurle segment.

Manipulation descapacités: Il existedeuxinstructionsdansCAPqui autorisentauxsujetsàmanipulerlescapacités: movecap et refine .

– L’opérationmovecap permetdecopierunecapacitéd’un segmentàunautre,si le sujetpossèdelesdroitsd’accèsadéquatssurlessegments.

– L’opérationrefine permetdefaireunecopiedela capacité(commemovecap ), maislesdroitsd’accèsdela copiesontinférieursàceuxdela capacité.Parexemplele sujetpeutcréerunecapacitédelectureàpartir d’unecapacitédelecture–écritureouunecapacitéqui donneaccèsàunepartiedusegmentdela capacitéoriginale.

Danstouslescasil fautl’interventiondusystèmepourcopierla capacité.

Changementdedomaine: Le changementdedomaineà traversdesprocéduresprotégéesestcontrôléparlescapacitésd’entréeetdesortie.L’appeld’uneprocédureprotégéecorrespondàunecommutationdesregistrentdesegmentdecapacité.Le systèmechange5segmentsdecapacités(sur16) : le segment4 (appeléP pour“Program”)qui spécifielescapacitésnécessairespourl’exécutiondela procédureprotégée,le segment5 (appeléI pour“Interface”)qui spécifielesdroitsd’accèsassociésà l’appelant,le segment6 (appeléRpour“Resource”)qui spécifielescapacitésdel’instancedela procédureprotégéedansle contexted’un objetprotégé,le segment2 (appeléA pour“Argument”)qui spécifielescapacitésàpasserenparamètreà l’appeldela procédureprotégéeetfinalementle segment3 (appeléN pour“New argument”)qui estutilisépourconstruirela C–listeàpasserà la procédureprotégéeetretournerlescapacitésauretourdel’appel (le segmentA estremplacéparN aumomentdel’appel).

Délégation: Il existedeuxmécanismespourla délégationdansCAP, soit paruneC–listepartagéeentreunprocessusetsonsous–processus,soit parunappeldeprocédureprotégée.Lessegmentsdecapacitéssontuniquementpartagésentreflotsdecontrôledansle mêmeprocessusouentreunprocessuset l’arborescenced’un desessous–processus.L’appelàuneprocédureprotégéepermetdepasserlessegmentsdecapacitéentreappelantetappelécommedécritci–dessus.Lessegments, P, I etRspécifientla sphèredeprotectionpourla procédureprotégée.LessegmentsA etN sontutiliséspourdéléguerlescapacités.L’appelantet l’appelés’exécutenttoujoursdansle contextedumêmeprocessus.

Révocation: La structurehiérarchiquedescapacitéspermetàunprocessusderévoquerunecapacitéuniquedansunsous–processuset touslessous–processusdecelui–ci.

Vérification : Il n’y apasdephasedepréparationexplicite, celle–ciestfaiteautomatiquementparle système.


Identificateur de l’objet (64 bits) Droits auxiliaires (8 bits)Droits génériques (16 bits)

FIG. 4.8:Le formatsimplifiédescapacitésd’Hydra

Accèsaux objets : La capacitéfait partiedela désignationetelleestvérifiéeàchaqueutilisation.

Classificationselonnotre taxinomie

Il existedeuxclassificationspossiblesdumécanismedechangementdedomainedansCambridgeCAP. Si le systèmeréinitialiselesregistresà capacités7–16avantl’appel, il réaliseunmécanismed’isolation,sinonil réaliseuneextensiondudomaine.

[classification: bb(a\ c)bbab]

4.4.2 Hydra

Hydraestle systèmed’exploitationd’un multi–processeur(le C.mmp)développéàl’Uni versitéCarnegie–MellonauxÉtatsUnis [Wulf81]. Hydran’estpasunsystèmed’exploitationcomplet,maisfournit unebasepourfairedesexpériencesavecdifférentsservicessystèmes.

Description du systèmedeprotectiond’Hydra

Hydraréaliseunsystèmeàobjetsactifsprotégésparcapacités.LescapacitéssontstockéesdansuneC–listepropreàchaqueinstancedel’objet. L’instancedel’objet estappeléel’espacededésignationlocal (“Local NameSpace”ou “LNS”). Uneinstanceestdécriteparunnomglobalqui identifiel’instance,un typequi déterminequellesopérationspeuventêtreinvoquéessurl’objet etunereprésentationqui décritl’état del’objet y comprisuneC–listepouraccéderàd’autresobjets.La machineC.mmpn’offre aucunsupportmatérielpourl’adressagedela mémoireparcapacités,touslesobjetsdésignéspardescapacités— et lescapacitéselle–mêmes— doiventêtreconfinésdansle noyau.


Le formatreprésentésurla figure4.8montrelesélémentslesplusimportantsd’unecapacitéHydra,c’est–à–direle nomuniquedel’objet, lesdroitsd’accèsgénériques(cesdroitssontdéfinispourtouslesobjets)et lesdroitsd’accèsauxiliaires(cesdroitssontspécifiquesautypedel’objet).Lesdroitsd’accèsgénériquessontréalisésparunbit–mapqui spécifielesdroitssuivants(1 signifiela présencedudroit). Lesdifférentsdroitsgénériquessontreprésentésdanslatable4.1.


GetDataRts , PutDataRts et AppendDataRtsSpécifientle droit delire, modifierou rajouterdesdonnéesà l’état del’objet ;

GetCapaRts , PutCapaRts et AppendCapaRtsSpécifientle droit decopierunecapacitédel’objet, modifierlescapacitésdel’objetou rajouterunecapacitédansla C–listedel’objet ;

DeleteRts Spécifiele droit desupprimercettecapacitéd’uneC–liste;KillRts PermetdesupprimerlescapacitésdanslaC–listedel’objet référencéparlacapacité.

Deplusil fautquela capacitédansla C–listeincluele DeleteRts ;ModifyRts Permetdemodifierl’état d’un objet;EnvRts Permetdestocker unecapacitéendehorsduLNS courant;UncfRts Permetla modificationd’un objetà traversun objetspécifié.Si la capaciténespé-

cifie pasl’ UncfRts , ni la C–listeni lesdonnéesdel’objet peuventêtremodifiées,cecipermetderéaliserunmodèledecontrôled’accèsmandataire;

CopyRts Nécessairepourappelerl’opération$copy .

TAB. 4.1:Lesdroitsgénériquesd’un objetHydra

Unecapacitécomplèted’Hydracontientdesinformationssupplémentaires,notammentliéesàla localisationdel’objet.

Création d’un objet : L’objet type(“type manager”)estresponsabledela créationdetoutobjetdesontype.La créationd’un objetestnormalementfaiteparunappel$create àl’objet type.Le résultatdela créationdépenddoncdu type,maisl’objet typevanormalementcréerunobjet,initialiser lesdonnéeset la C–listeet retournerunecapacitépourl’objet àceluiqui aappelé$create . Cettecapaciténepermetnormalementpasdemodifierl’état del’objetdirectement,maisuniquementà traversdesopérationsdéfiniesparl’objet type.

Manipulation descapacités: Lescapacitésd’Hydrasontconfinéesparle noyau.Toutemanipulationdescapacitéssefait doncà traversdesappelsdusystème.Hydrasupportelesopérationsdecapacitésuivantespourtout typed’objet :

$getcapa qui permetdecopierunecapacitéd’uneC–listed’un autreobjetdanslaC–listelocale(dansle LNS).

$putcapa qui permetdecopierunecapacitélocaledansuneendroitprécisdelaC–listed’un autreobjet.

$appendcapa qui permetderajouterunecapacitélocaleà la fin dela C–listed’unautreobjet.

$compare qui comparedeuxcapacités.

$restrict qui réduitlesdroitsd’accèsd’unecapacité.

$delete qui permetdesupprimerunecapacité.

Pourpouvoir invoquercesopérations,il fautdoncquele sujetpossèdeunecapacitéaveclesdroitsadéquats.

Changementdedomaine: Le systèmeutilisedesmodèlesdeparamètre(“parametertemplates”)pourvérifier le typedescapacitéspasséesenparamètredansl’appeld’uneopérationsurunobjet.Un modèledeparamètrespécifiele typed’unecapacitéet lesdroits


requisparl’appel.Avantd’installerunecapacitépasséeenparamètredansla C–listelocale,lesystèmevérifiequ’ellea le bontypeetqu’ellespécifieaumoinslesdroitsspécifiésdanslemodèleduparamètre.Le contextedel’objet secomposedescapacitésspécifiéespourle typeetdescapacitéspasséesenparamètredansunappeldeméthode.

Délégation: Le seulmoyendedéléguerunecapacitéà unobjetestd’appeleruneopérationdansl’objet etdepasserla capacitéenparamètre.Il fautquele sujetait le droit decopierlacapacitédesapropreC–listeetdel’insérerdansla C–listedel’objet. Lesopérations$getcapa , $putcapa et$appendcapa sonteffectivementdesméthodesdéfiniespourtouslesobjets.

Révocation: La combinaisondesdroitsdeKillRts etDeleteRts décritsci–dessuspermetdesupprimerunecapacitédansla C–listed’un objetspécifique.PourpouvoirsupprimerunecapacitédanssapropreC–listeil fautdeplusquele domainecourantpossèdeledroit EnvRts .

Vérification : L’invocationd’uneopérationsurunobjetprovoquela vérificationdelacapacité.Celaestfait automatiquementparle système.

Accèsaux objets : Le systèmevérifiequetouteslesmanipulationsd’un sujetcorrespondentàcellespermisesparla capacitéutiliséepourfairel’invocation,parexemplesi la capaciténespécifiepaslesdroitsPutDataRts etModifyRts , lesdonnéesstockéesdansl’objet nepeuventpasêtremodifiées.

Classificationselonnotre taxinomie

La classificationselonnotretaxinomied’Hydraestdonnéeparla descriptionsuivante:[classification: bbcbbab]

4.4.3 Discussiondessystèmescentralisés

Le modèledeprotectionréaliséparCAPesttrèsgénéral.Il permetla réalisationdespolitiquesmandataireetdiscrétionnaire.Pourréaliserunmodèlemandataire,il fautquetouteslesclassesdeconfidentialitédifférentessoientconfinéesdansdifférentsprocessusauniveau2. Danscecasil fautquetouslespassagesdecapacitéspassentparle MC auniveau1. Le MC peutdoncvérifierquelespassagessefont selonlesrèglesimposéesparla politiquemandataire.Pourréaliserunmodèlediscrétionnaire,il fautquele MC n’imposeaucunerestrictionsurladélégationdescapacités.Le chargementtransparentdusegmentdecapacitéspasséenparamètreestunecaractéristiquetrèsintéressantdusystèmeCAP.Le modèledeparamètresestaussiunecaractéristiquetrèsintéressantdusystèmeHydra.


4.5 Systèmesrépartis

Lessystèmesàcapacitésrépartisn’ont pasdeplate–formeencommun.La capacitédoit doncêtrevérifiéeà chaqueutilisation,soit parla vérificationdela capacitéelle–même(capacitéschiffrées),soitparl’authentificationdusitequi présentela capacitéparuncanaldecommunicationsûre(capacitésconfinées).Nousprésentonsdeuxapprochesdifférentesderéalisationd’un systèmeàcapacitésrépartidansla suite.

4.5.1 Amoeba

AmoebaestunsystèmerépartiàobjetsdéveloppéauVrije UniversiteitàAmsterdam[Tanenbaum86, Tanenbaum90]. Amoebaestconçucommeunmicro–noyauoùdifférentesressourcespeuventêtregéréespardesserveursdansl’espaceutilisateur. La notiondesystèmedoit doncinclurelesserveursqui gèrentlesressources,parexemplele systèmedefichiers.Lesapplicationssontégalementdéveloppéesselonle modèleclient/serveur.

Description du systèmedeprotectiond’Amoeba

Lesobjetsgérésparunserveursontdésignéspardescapacités.Le serveurcontrôletouslesaccèsàsesobjets,qui nesontnormalementpasvisiblesdel’extérieur. Le serveurencapsuledonclesobjetscommelesobjetsencapsulentleurétat.Unecapacitéautorisele clientàexécutercertainesopérationssurunobjet.L’opérationprendle formed’un appelà distancetraditionnel[Birrell84]. L’appeldoit passerparunpointd’entrée— appeléunport— définiparle serveur.Remarquonsqu’il n’existepasunedistinctionpréciseentreclientset serveurs.Si unclientpasseunecapacitépourunobjetenparamètreàunserveur, ceserveurvadevenir le clientduserveurqui gèrel’objet référencéparla capacité.


Unecapacitéd’Amoebasecomposedequatrechamps(cf. la figure4.9).

Droits d’accèsId objet SignatureId port

FIG. 4.9:Le formatd’unecapacitéd’Amoeba

Lesquatrechampscontiennentl’information suivante:

1. le port qui sertdepointd’entréedansle serveur;

2. un identificateurdel’objet localauserveur;

3. unbit–mapqui contient1 bit pardroit d’accèspossible;

4. unesignaturequi permetdevérifier lesdroitsd’accès.

La sémantiquepourlesbit–mapdesdroitsd’accèset l’algorithmeutilisépourfairela signaturedépendentduserveur. La clédechiffrementestégalementgéréeparle serveuretelleestnormalementstockéeavecl’objet.

4.5. SYSTÈMESRÉPARTIS 79

Création d’un objet : Un clientpeutdemanderàunserveurdelui créerunnouvel objet.Sile clienta le droit decréerdesobjets,le serveurcréel’objet et retourneunecapacitéauclient.Le formatdecettecapacitéet la sémantiquepourleschampsdedroitsd’accèsetdelasignaturedépendentduserveur, maisils incluentnormalementle droit d’accéderà l’objet.

Manipulation descapacités: Lesmécanismesdemanipulationdescapacitésdépendentduserveur. Normalementlesclientspeuventcopierunecapacitésansl’interventionduserveuretil existeégalementunschémaderestrictiondesdroitsd’accèsqui permetauclientdedériverunecapacitémoinsprivilégiéeavantdela passerà quelqu’und’autre.Il existedeuxmoyensderestreindreunecapacitédansAmoeba: soit le clientdemandeauserveurdela restreindre,soit la gestiondecapacitésuit le formatsuivant.À la créationdel’objet, le serveurstockeavecl’objet le motdepasseutilisépourcréerdescapacités.Le serveurdoit définirunefonctiondehachageàsensuniquecommutative5 parvaleurdanslebit–mapdesdroitsd’accès.Pourretirerundroit spécifiquedansla capacitéil suffit demettresavaleurdansle bit–mapàzéroetd’appliquerla fonctiondehachageà la signature.Pourvérifierunecapacité,le serveurappliquetouteslesfonctionsdehachagequi correspondentàundroit retiré— dansle champdesdroitsd’accèsinclusdansla capacité— aumotdepassestockéavecl’objet. Ensuiteil comparele résultatavecle motdepasseinclusdansla capacité,si lesdeuxcorrespondentla capacitéestvalable.La fonctiondehachagedoit êtrecommutativepourquel’ordre danslequelon retirelesdroitsn’ait pasd’importance.

Changementdedomaine: Le serveurspécifieunouplusieurspointsd’entréedansleserveur(le domaine)qu’il exporteauxclients.Un pointd’entréeestspécifiéparle premierchampdela capacité.Le portestunnombregrand(normalement48bits), la connaissancedecenombrepeutdoncêtreprisecommeindicationquele clientà le droit decontacterle serveur(le serveurestlibre denepasrépondreouderetournerunmessaged’erreurauclient).Le serveurvad’abordvérifiersi lesdroitsd’accèsinclusdansla capacitécorrespondentavecceuxencodésdansla signature.Si lesdroitssontintègreset s’ils autorisentl’opération,leserveurinvoquel’opérationsurl’objet et retournela réponseauclient.

Délégation: Lescapacitéssontdesstructuresdedonnéesgéréesparlesclients.Un clientpeutdonccopierunecapacitétellequelleet l’envoyeràquelqu’und’autre.Lesschémasderestrictiondécritsci-dessuspermettentégalementauclientderestreindrelesdroitsd’accèsinclusdansla capacitéavantdela copier.

Révocation: LesalgorithmesdesignaturecourammentutilisésdansAmoebadépendentd’un motdepassestockéavecl’objet. Il suffit doncdechangercemotdepassepourinvalidertouteslescapacités.

Vérification : Le serveurvad’abordchercherl’objet désignéparle deuxièmechampdelacapacitépourtrouver la clédechiffrement(oumotdepasse)associéeà l’objet. Le serveur

5Une fonctionde hachageà sensunique(“one-way hashfunction”) estdéfiniepardeuxpropriétés: l’imagedela fonctionestdetaille fixe (normalementd’unetaille inférieureà cellededépart,maisdansle casd’Amoebad’unetaille égale)etelledoit êtrefacileà calculermaisl’inversedoit êtred’unegrandecomplexité.


utilisecetteclépourvérifier la signatureet lesdroitsd’accèsinclusdansla capacité.Si lesdeuxcorrespondent,le serveurinvoquel’opérationdemandéeparle client.Le schémadevérificationdépenddu formatdela capacitéetduschémademanipulationdescapacitésutiliséparle serveur.

Accèsaux objets : lesclientsn’ont pasd’accèsdirectauxobjets,touslesaccèspassentdoncà traversunpointd’entréedansle serveur. La vérificationdécriteci–dessusestfaiteparleserveuràchaqueaccèsà l’objet.

Classificationselonla taxonomie

La classificationdela révocationdescapacitésdansAmoebadépenddel’utilisation dusystème.Si le systèmegèreunmotdepasseparutilisateur, le systèmepeutréaliserunerévocationsélectivechezl’objet, sinonil estobligédefaireunerévocationenblocdetouteslescapacitésqui existentpourl’objet. [

classification: bacb(a\ c)ab]4.5.2 Mach

Machestunmicro–noyaudesystèmedéveloppéà l’universitédeCarnegieMellon [Accetta86,Boykin93, Loepere92a,Loepere92b].Il fournit lesmécanismesdebasepermettantdeconstruiredessystèmesrépartis.Il aservinotammentdebaseà la réalisationdessystèmesOSF/1(systèmeUnix) etGuide–2(systèmerépartiàobjets).Le systèmeMachreposesurlesnotionsdetâche(unespaced’adressagemulti-thread)etdeport (uneadressepermettantl’émissionet la réceptiondemessages).Un portappartientàunetâche,cettetâchepouvantrecevoir desmessagessurceport.Toutetâcheayantconnaissancedeceportpeutpotentiellementlui envoyerunmessage.Lesportspeuventêtreéchangésentrelestâchesparenvoi demessage.

Description du systèmedeprotectiondeMach

DansMach,touteslesressourcessontidentifiéesetprotégéespardesports.Un portpeutserviràcontrôlerle droit decouplerunsegmentdemémoirepartagée,oucorrespondreàunpointd’entréedansunserveurd’objets.Un portpeutdoncêtrevu commeunecapacité.Machpermetd’échangerdesportsentrelestâchespardesenvoisdemessage,commedescapacités.Lesdroitsassociésà unport sontprincipalement: le droit d’envoyerununiquemessageou le droit d’envoyerunnombrequelconquedemessages.Il estpossiblederestreindrelesdroitsassociésàunportavantdel’envoyerdansunmessage.DansMach,lesportssontgérésparle noyaudusystème.Lesportssontdésignésdansunetâcheparun identifiantlocalà la tâche.Cetidentifiantestinterprétéparle noyauàchaquefois quela tâcheprésentele portaunoyau,soit pourémettreou recevoir unmessage,soit pourpasserunportdansunmessage(le portdoit êtreexplicitementdéclarédansle message).Lorsqu’unportesttransmisd’unetâcheT1 àunetâcheT2, l’identifiant localestreçuparMachqui vérifiequele portexisteeffectivementdansT1, puisMachajoutele portdansla tâcheT2 et lui associeun identifiantlocalàT2 qui lui estretourné.Notonsquelesportssontgérésparle noyauetnepeuventêtreforgés.

4.5. SYSTÈMESRÉPARTIS 81

Création d’un objet : La créationd’un objetdansMachcorrespondenfait à la créationd’un portqui représentel’objet dansunserveur. Le serveurpeutalorsrecevoir desrequêtes(messages)surceportet lestransmettreà l’objet qu’il héberge.La connaissancedeceportpeutêtretransmiseauxclientsduserveursoit enretourd’unerequête,soit parl’intermédiaired’un serveurdenoms.

Manipulation descapacités: Lescapacitéssontmanipuléesexplicitementparlesprogrammes.Un programmequi désireenvoyerunmessagesurunportdoit construireunestructurededonnéescorrespondantaumessage.Cettestructurededonnéesdoit incluredesinformationsdetypagedesdonnées,etnotammentindiquerquellesdonnéesdumessagecorrespondentàdesports,permettantaunoyauderéaliserle transferteffectif desportspassésenparamètre.

Changementdedomaine: L’envoi demessagesurunport correspondàunchangementdedomaine,caril permetderéaliserl’exécutiond’uneopérationdansuneautretâche(undomainedeprotection).Le noyauvérifie lorsdel’envoi demessagesi l’utilisation duportd’envoi estlégaleet si lestransfertsdeportsenparamètre(décritsdansla structuredumessage)le sontégalement.

Délégation: LesdroitssurlesportsdeMachpeuventêtreéchangésentrelestâches.Le droitd’envoyerunmessagesurunportpeutêtrecopiéou transféré,maisle droit derecevoir unmessagepeutuniquementêtretransféré.

Révocation: Il existeuneopérationmach_port_destroy qui permetausystèmederetirerle droit d’envoyerourecevoir desmessagessurunport.L’appelsupprimeeffectivementla référenceauportdansla tâche.

Vérification : TouteslesvérificationsdesportsdansMachont lieu dansle noyau.Ceciimpliquequ’il n’estpaspossibledeforgerunecapacité.

Accèsaux objets : Le droit d’envoyerourecevoir unmessagesurunportestvérifiéchaquefois quele port estutilisé.

Classificationselonla taxinomie

Il existedeuxfaçonsdedéléguerle droit surunport,parcopie(unportd’envoi demessage)etpartransfertduport (unportderéceptiondemessage).La classificationdeMachselonnotretaxinomieestdonnéeparla descriptionsuivante:[

classification: bbc(a\ b)bab]4.5.3 Discussion

Amoebaréaliseuncontrôled’accèsparcapacitéchiffréequi permetauxclientsdemanipulerlescapacitéssansinterventiondusystème(le serveur).Parcontre,Machréaliseuncontrôled’accèsparcapacitéconfinéequi exigentquetouslestransfertsdecapacitéspassentparle


système.La portéed’unecapacitédansMachestlocal.Un utilisateurestainsiincapablededéléguerunecapacitésansl’interventiondusystème.

Remarque! Le systèmeAmoeban’a pasbesoindeconnaîtrele formatdescapacitésendétail,il suffit deconnaîtrele numérodeportduserveur. La sémantiquedel’identificateurd’objet, lesdroitsd’accèset la signaturedépendentduserveur. Ceciapourconséquencequeplusieursmécanismesdecontrôled’accèsdifférentspeuventcoexisterdansle système.Il estdoncfaciled’adapterle systèmedecontrôled’accèsàunmodèledeprotectiondonné,mêmesiunmodèlediscrétionnairesembleêtrebeaucoupplusfacileà réaliserqu’unmodèlemandataire.

4.6 Lesmémoiresvirtuelles réparties uniques

Lesmémoiresvirtuellesrépartiesuniquessontdessystèmesrépartisqui gèrentla mémoired’unefaçonglobale,c’est–à–direqu’uneadressevirtuellesertd’identificateurglobalpourlesobjets.La visibilité globaledetoutela mémoirevirtuellenécessiteuneséparationentreladésignationet le contrôled’accès.Le contrôled’accèsà la mémoireestfait parcapacitésdanstouslesprototypesdeMVRUconnus.

4.6.1 Opal

Opalestunsystèmeàmémoirevirtuelle répartieuniquedéveloppéà l’Uni versitédeWashington[Chase92,Chase93,Chase94,Chase95].Le but principald’Opalaétéd’explorerla conceptiond’unemémoirevirtuelle répartieuniquesurdesarchitecturesàadressageétendu(64bits).

Description du systèmedeprotectiond’Opal

Le systèmedeprotectiond’Opal réaliseuneprotectionparcapacitésselonle modèledeDennisetVanHorn. Il implantedeuxtypesdecapacitésdifférents: lescapacitésd’accèsauxsegmentset lescapacitéspourdesobjetsprotégés.Unecapacitéd’accèsàunsegmentestutiliséelorsducouplaged’un segmentdansl’espaced’adressageduprocessus6. La capacitéspécifielesdroitsd’accèssuivants: lecture,écritureouexécution.Unecapacitépourunobjetprotégépermetd’appeleruneméthodedansunobjetprotégé.Lacapacitéidentifieunpointd’entréeouportail (“portal”) qui permetd’entrerdansle domaine.Le portail n’estpasprotégéparle système,touslessujetsqui connaissentle numéroduportailpeuventdoncenvoyerunmessageauportail.La capacitéinclut égalementl’adressevirtuelled’uneprocéduregarde(“guard”) — qui contrôleeffectivementl’accèsà l’objet — etunchampdevérificationutilisépourempêcherla fabricationdescapacités.Le systèmed’exécutioncachelesportailset le passagedescapacitésdansdes“proxies”.

6Le couplageetdécouplaged’un segmentestfait explicitementparlesappelssystèmesattach etdetach .

4.6. LESMÉMOIRESVIRTUELLESRÉPARTIESUNIQUES 83


Lescapacitésd’Opalsontdesstructuresdedonnéesgéréesparlesutilisateurseuxmêmes.La capacitésecomposedequatremotsde64bit. Le premiermot identifiele service(soit leserveurdessegments,soitunobjetprotégé),le deuxièmemotn’estpasutilisé, le troisièmemotspécifieuneadressevirtuelleet le quatrièmemotspécifieunchampdevérification(“checkfield”). Le formatdescapacitésestmontrésurla figure4.10.

a)Capacitéd’accèsausegment

Identificateur

du portail

Portal du domaine

Adresse virtuelle

du segment

Champ de

vérification

Serveur des segments Adresse virtuelle du segment Droits d’accès

Mot de passeAdresse virtuelle du garde

b) Capacitépourunobjetprotégé

FIG. 4.10:Le formatdescapacitésd’Opal

La figuremontredeuxinterprétationsd’unecapacité: unecapacitéd’accèsausegment(cf. figure4.10a)etunecapacitépourunobjetprotégé(cf. figure4.10b).Le rôleprécisduchampdevérificationdépenddesservices.Lesdeuxservicespardéfautd’Opal— serveurdesegmentet le serveurdedomaine— le traitentcommeunsimplemotdepassepouraccéderauservice[Chase99].

Création d’un objet : Chaqueappeldecréationd’uneressourceprotégéeretourneunecapacitépourla ressourceà l’appelant.

Manipulation descapacités: Lescapacitéssontlesstructuresdedonnéesgéréesdanslamémoireparl’utilisateur. L’utilisateurestdonclibre dela délégueràn’importequi.

Remarquonsquela notiondeconfianceesttransitiveetquelescapacitéspeuventêtrevoléesoudonnéespar maladresseà quelqu’unqui n’estpascenséla posséder(leproblèmedeconfinement)[Chase95]

Changementdedomaine Le mécanismedechangementdedomaineestmontrésurlafigure4.11.Le proxyenvoie la capacitéauportail qui la renvoieaugardespécifiéparl’adressevirtuelleinclusdansla capacité.Cegardevérifiequele champdevérificationinclusdansla capacitécorrespondà la copielocalecrééelorsdela créationdela capacité.Si lesvaleurscorrespondentle gardesertdetalonserveurcommedansunappelRPCnormal.


Id. portail Portal

CapacitéGarde Objet protégé

méthodes de l’objet

Talon garde

Proxie

Talon proxy

index de méthode

paramètres

mot de passe

AV garde

FIG. 4.11:Le changementdedomainedansOpal

Délégation: Il existedeuxmoyensdedéléguerlescapacitésdansOpal: parla mémoirepartagéeouparle passagedela capacitéenparamètreàunappeldechangementdedomaine.Le systèmen’imposeaucunerestrictionà la délégationdescapacités.Dansle casdupartagedela mémoire,deuxdomainespartagenteffectivementla mêmecapacité.Dansle casdupassageenparamètre,unecopiedela capacitéestpasséeentreledomainedel’appelantet le domainedel’appelé.

Révocation: La capacitéestprotégéeparunmotdepasse.Unecopiedecemotdepasseeststockéechezle serveur. Le serveurpeutdoncfacilementrévoquertouteslescapacitésenchangeantcemotdepasse.Il n’existeaucunmoyenderévoquerunecapacitéexplicitement.

Vérification : La vérificationdela capacitéd’accèsausegmentprovoquéeparunappelàattach permetauserveurdessegmentsdecouplerle segmentdansl’espaced’adressagedel’appelantaveclesdroitsd’accèsspécifiésparla capacité.Unefois le segmentcoupléenmémoire,l’appelantpeuty accéderdirectement.Il n’y apasdephasedevérificationpourlesappelsd’objetsprotégés,la capacitéestvérifiéeàchaqueappel.

Accèsaux objets : Lorsdel’appelàattach , le serveurdessegmentsmetà jour desstructuresnécessairesdansla gestionnairedela mémoirepourquecelles–cipuissentcontrôlerl’accèsausegment.


La classificationd’Opalselonnotretaxinomieestdonnéeparla descriptionsuivante:[classification: bacbaab]


4.6.2 Mungi

Mungi estuneMVRU développéea l’Uni versitédeNew SouthWales[Vochteloo93, Vochteloo96, Vochteloo98]. Un objectif principaldeMungi aétéderendrelesmécanismesdecontrôled’accèstransparentspourle programmeur.

Description du systèmedeprotectiondeMungi

Le systèmedeprotectiondeMungi réaliseuneprotectionparcapacitéschiffrées7. Le systèmeréaliselesnotionsdecapacité,objet(unobjetsecomposed’unesuitedepagescontiguës,égalementappeléunsegment),domainedeprotectionet l’extensiondedomaine.Mungi offre unmodèledecontrôled’accèshiérarchique.LesC–listessontorganiséesselonunearborescenceglobaleaveclesC–listespubliquesprèsdela racineet lesC–listesprivéesprèsdesfeuilles.Un nœuddanscettearborescence— qui s’appelleunPnode(“Protectionnode”)— inclut unpointeurversuneC–listeetunpointeurverssonprédécesseurdansl’arborescence8. L’arbreestmontrésurla figure4.12.

C-liste

Racine

Pnode

FIG. 4.12:L’arbredescapacitésdeMungi

Le domaineinitial d’un utilisateurestdéterminéparunpointeurversunPnodedanscetarbreet le domainesecomposedela fermeturetransitivedenœudsaccessiblesdepuisle Pnode.Lesutilisateurssontautorisésà rajouteretsupprimerlesPnodess’ils possèdentlesdroitsadéquats.


Nousneconnaissonspasle formatexactd’unecapacitédansMungi, maiselle inclut aumoinsl’adressedel’objet (l’adressedebasedusegment),lesdroitsd’accèset le motdepassequicorrespondàcesdroitsd’accès.Lesdroitsd’accèssontlessuivants:

7La signatureestenfait unmotdepassestockéavecl’objet et inclusdansla capacité.8le Pnodepeutégalementinclure un pointeurversun “protectionfault handler” fourni par l’utilisateur pour

spécialiserla recherchedescapacités.


d détruirel’objetr lire l’objetw écrirel’objetx utiliser l’objet commeducodeexécutable

Remarque! Le droit d’écrireexisteuniquementencombinaisonavecle droit delire l’objet.

Création d’un objet : Aprèsla créationd’un objet,le systèmeretourneunecapacitéquidonnetouslesdroitsdrwx aucréateur. Cetypedecapacités’appelleunecapacitédepropriétaire(“ownercapability”).Le systèmecréeunmotdepassepourcettecapacitéetpourtouteslescapacitésdérivées,puisil lesinsère(aveclesdroitsd’accèscorrespondants)dansuntableaugéréavecl’objet. Cecipermetausystèmedevérifier lescapacitésetauxsujetsdeconstruiredesversionslimitéesdeleurscapacitésexistantes.

Manipulation descapacités: Unecapacitédepropriétairepermetdecréerdesnouvellescapacitésdepropriétaire.Il suffit defaireunappelsystèmeavecunnouveaumotdepasse.Lesystèmeenregistrecemotdepasseet touslesmotsdepassedérivésaveclesmotsdepasseexistants(dansle tableaugéréavecl’objet).Touslesautrestypesdecapacitéspermettentuniquementdecréerunecapacitédérivée.

Changementdedomaine Lesdroitsd’accèsd’un domainedeprotectionMungi peuventêtreaugmentésouréduitsdefaçontemporaireparunappeld’extensiondudomaine(“protectiondomainextension”ou “PDX”). L’extensiondudomainenechangepasle domainedebasemaispermetd’exécuteruneprocédureparticulièreavecdesdroitssupplémentaires.Iln’y adoncpasbesoindepasserdescapacitésentrele domaineappelantet le domaineappelé.Cemécanismepermetégalementl’isolation, si l’appelantfait unerestrictiondesondomaineavantl’appeldela procédurePDX.

rwx

drwx

xrw

r

f

f

xf rw

f

FIG. 4.13:La hiérarchiedescapacitésdérivées

Délégation: Lescapacitéssontdesstructuresdedonnéesgéréesparlesutilisateursqui sontlibresdelescopieretdelespasserdanslesappelsd’extensionsdedomaineoudelespartager


dansunsegmentdela mémoirepartagée.Unetransformationconnuedumotdepassedelacapacitépermetdedériveruneversionrestreintedela capacité.L’applicationd’unefonctionàsensunique(“one–way function”) aumotdepasseinclusdansla capacitédepropriétairepermetdeconstruiredescapacitésréduites.Trois fonctionspubliquessontdéfiniesparle système: ^ , ^ rw et ^ x.Appelonsla capacitédepropriétaireN drwx ; lescapacitéssuivantespeuventêtredérivéesdecettecapacité: N rwx O ^`_�N drwx a , N rw O ^ rw _bN rwx a , N x O ^ x _�N rwx a et N r O ^`_�N rw a . Cettedérivationestillustréesurla figure4.13.La figuremontrelesdifférentespossibilitéspourdériverunecapacitérestreinteàpartir d’unecapacitéplusprivilégiée.

Révocation: Unecapacitédepropriétairepermetdedemanderausystèmedesupprimercertainsmotsdepassedérivésdeceuxinclusdansla capacité.Cecirévoqueeffectivementtouteslescapacitésqui dépendentdecesmotsdepasse.

Vérification : La premièreréférenceàunobjetprotégéprovoqueunefautedeprotection.Larésolutiondecettefautevérifies’il existeunecapacitépourl’objet dansle domaineetcomparele motdepasseinclusdansla capacitéaveccelui stockéavecl’objet qui donnelesmêmesdroitsd’accès.Si lesmotsdepassecorrespondent,l’accèsestaccordéet le systèmemetà jourlesstructuresnécessairespourcouplerl’objet dansl’espaced’adressagedudomaine.

Accèsaux objets : La vérificationdudroit d’accèssefait aumomentd’unefautedepage.Le systèmevérifie le droit d’accèsà l’objet dansunestructure(“ProtectionLookasideBuffer”ou“PLB”) géréedela mêmefaçonquela structuredespagesenmémoireactives(“TranslationLookasideBuffer” ou “TLB”). Cesdeuxstructuressontexploréesenparallèle.


La classificationdeMungi selonnotretaxinomieestdonnéeparla descriptionsuivante:[classification: baabaab]

4.6.3 Angel

AngelestuneMVRU développéeàCity University,Londres[Murray93a,Murray93b, Wilkinson95].

Description du systèmedeprotectiond’Angel

Le systèmedeprotectiond’Angel sebasesurlescapacités,lesdomainesdeprotectionactifsetla communicationentredomainesparinterruptionslogicielles.La notiondecapacitésebasesurunecombinaisondescapacitésconfinéesetdescapacitéschiffrées.Unecapacitéconsistededeuxparties: unedescriptionducontrôled’accès(“accesscontroldescriptor”ou “ACD”) confinéetunbiscuit(unecapacité)publiquequi donnele droitd’utiliser l’A CD.Lesdroitsd’accèsfondamentauxsontlessuivants:


lir e, : le droit delire unobjet;écrire, : le droit d’écrireunobjet;exécuter, : le codeexécutéparle sujet;lir edroits, : le droit delire lesdroitsassociésaubiscuit;écriredroits, : le droit demodifierlesdroitsassociésaubiscuit;supprimerbiscuit, : le droit desupprimertoutaccèsà l’objet

utilisantcebiscuit;créerbiscuit : le droit decréerunnouveaubiscuitavecun

nouvel ensembledesdroits;rendexécutable : le droit derendrel’objet exécutable;“upcallable” : le droit defaireuneinterruption

logicielleversl’objet.


Enréalitél’A CD n’estpasunecapacitéconfinée,parcequ’il peutêtresoumisà desconditionssupplémentaires; parexempleil donnele droit delire unobjetuniquementsi le sujetpossèdedesdroitspourunautreobjet.Le biscuitinclut del’information pourquele systèmepuissele vérifier; ceciestprobablementunmotdepassecommeOpaletMungi.Outrecetteséparationdela capacitéendeuxparties,nousn’avonspastrouvédedescriptionplusprécisedu formatdescapacitésdansAngel.

Création d’un objet : Lesgestionnairesd’objetsontresponsablesdela créationdesobjets.Quandle gestionnairecréeunobjet,il créeégalementl’A CD etunbiscuitqu’il retourneauutilisateurqui demandaitla création.Le contenuprécisdel’A CD dépenddugestionnaired’objet.Un biscuitqui identifiel’objet à traversl’A CD estretournéaucréateur.

Manipulation descapacités: LesACD sontconfinésparle gestionnaired’objethorsdeportéedesutilisateurs.Lesbiscuitssontdesstructuresdedonnéesstockéesparlesutilisateurs.Lesdroitsdecréerunbiscuitavecdesdroitsdifférentsetdesupprimertouteinstanced’unbiscuitsontcontrôlésparle système.

Changementdedomaine Il n’y apasd’appeldechangementdedomainedansAngel.Lechangementdedomaineesteffectuéparuneinterruptionlogicielledansle domaineappeléquipasseuneadresseenparamètreà l’interruption.Il fautdoncquechaquedomainepossèdeledroit defaireuneinterruptionlogiciellechezl’autre (l’appelantpourfairel’appelet l’appelépourretournerl’appel).L’adressepasséeenparamètredoit pointerversunobjetpartagéqui contientlesparamètresdel’appel.

Délégation: Lesutilisateurspeuventpasserlesbiscuitslibremententre–eux.Cecin’impliquepasforcémentle passagedudroit d’accès,parcequ’il fautquele récepteursatisfassetouteslesconditionsinclusesdansl’A CD.


Révocation: Le droit desupprimerunbiscuitpermetdesupprimerle droit d’accèspourtouteslesinstancesdubiscuit.Celan’estpasunerévocationtotaledetouslesdroitsd’accèspourla ressource,parcequed’autresbiscuitspeuventexisterpourle mêmeACD. Si unsujetqui possèdeun tel biscuitsatisfait lesconditionsdansl’A CD il peutdonctoujoursaccéderà laressource.

Vérification : La vérificationdudroit d’accèsàunobjetsefait aumomentdela premièreréférenceà l’objet. Le systèmevérified’abordquele biscuitestvalable,puisil vérifiesi ledomaineappelantsatisfait lesconditionsdansl’A CD. Si le systèmeassocieunobjetàchaqueutilisateuretexigeuniquementlesdroitssurcesobjets,l’A CD réaliseunesimplelistedecontrôled’accès.L’ACD estdoncplusgénéralequel’A CL. Le schémadecontrôled’accèsestprésentésurla figure4.14.

Biscuit

Objet A, lire Objet B, lire

Objet C

Objet A, supprimer Objet B, supprimer

Objet A, écrire

Objet B, écrire

Objet A, lire

AND

ACD

lireécrire

supprimer

OR

AND

OR

FIG. 4.14:Le schémadecontrôled’accèsd’Angel

La figuremontreunbiscuitqui permetd’accéderàObjet C selonlesrèglessuivantes:

1. Le sujetestautoriséà lire Objet C si sondomainepossèdedéjàle droit delire Objet AouObjet B ;

2. Le sujetestautoriséà écrireObjet C si sondomainepossèdedéjàle droit d’écrireObjetA ou lesdroitsdelire Objet A etd’écrireObjet B ;

3. Le sujetestautoriséà supprimerObjet C si sondomainepossèdedéjàle droit desupprimerObjet A etObjet B.

Accèsaux objets : La vérificationdudroit d’accèssefait aumomentd’unefautedepagecommedansMungi. Angelutiliseunestructure“ddl” pareilleau“PLB” deMungi pourcettevérification.



Le systèmedecontrôled’accèsd’Angel sebasesurunecombinaisondescapacitésetuneACLconditionnellequi nerentrepastrèsbiendansla taxinomie.Il y adeuxpossibilitéspourlaclassificationdela manipulationd’unecapacité: la délégationd’un biscuitpeutêtrefaitesansinterventiondusystème,parcontreil fautl’interventiondusystèmepourcréerdesnouveauxbiscuitset changerlesdroitsd’accèsinclusdansunbiscuit.Il existeégalementdeuxpossibilitéspourla classificationdela révocationd’unecapacité: s’ilexisteunbiscuit(avecsonmotdepasse)parutilisateur, le systèmepeutréaliserunerévocationsélectivechezl’objet, sinonil estobligéà faireunerévocationenblocdetouslesbiscuits.[

classification: b(a\ b)cb(a\ c)cb]4.6.4 Discussion

Opalfournit unmodèledeprotectionparcapacitéschiffréesclassique(la classificationd’Opal(bacbaab)estpresquela mêmequecelled’Amoeba(bacb(a\ c)ab)).Le modèleestpurementdiscrétionnaire; il estdoncimpossiblederéaliserunepolitiquedeprotectionmandatairecommeparexemplela politiquedeDennisetVanHorneouunepolitiquebaséesurlesrôles.L’extensiondedomainedeprotection(PDX) deMungi permetd’augmenterlesprivilègeslorsd’un appeldeprocédure.Ainsi, Mungi permetd’adapterle systèmeauxbesoinsdesapplicationsenutilisantdesserveursprivilégiés.Parcontre,le modèlen’offre aucunsupportdirectpourdesapplicationsmutuellementméfiantes.Le fait quele systèmedeprotectiond’Angel soit trèsdifférentdesautresaugmentelaprobabilitéd’unefauteparmauvaisecompréhensiondela partduprogrammeur.Il semblebizarrequele projetd’Angel proposeunmodèledeprotectionsi différentdesautressystèmessansle décrireplusendétail.Il auraitététrèsintéressantd’apprendreleurexpérienceavecla programmationseloncemodèle.Un mécanismetel queceluid’Angel permetderéaliserlespolitiquesmandataires,il suffitd’exiger l’existenced’un droit supplémentairequi correspondà l’habilitation ou le rôle.Nousnesavonspassi lesopérationspossiblesdanslesACD permettentd’interdirel’accès.Cetypedesupportpermettraitderéaliserle modèledela murailledeChine.


Lescapacitésoffrentunegrandeflexibilité pourla configurationet la délégationdesdroitsd’accès.Malheureusement,cetteflexibilité setraduitsouventparunedifficultédeconfinerlesdroitsd’accès,c’est–à–direqu’unsystèmeàcapacitéclassiquenepermetpasla réalisationd’unepolitiquedeprotectionmandataire.Il existedeuxextensionsdifférentesaumodèleàcapacitésclassiquequi permettentderéaliserunetellepolitique.Le systèmepeutvérifierchaqueutilisationd’unecapacitépourdéterminersi l’utilisation respectela politiquemandataire(l’approchedescapacitésaugmentées)ou lesystèmepeutcontrôlerla délégationdescapacités(l’approched’ICAP).La taxinomiedessystèmesàcapacitésproposéeparKain etLandwehrnesuffit paspourladescriptiondessystèmesàcapacitésrépartis.Nousavonsdoncproposéunenouvelletaxinomiequi permetdemieuxclassifierlespropriétésd’un tel système.Cettetaxinomieaété


utiliséepourdécriredeuxsystèmescentralisés(CambridgeCAPetHydra),deuxsystèmesrépartis“classiques”(AmoebaetMach)et troissystèmesà mémoirevirtuelle répartieunique(Opal,Mungi etAngel).La classificationdecessystèmesestillustréesurle tableau4.2.

CAP Hydra Amoeba Mach Opal Mungi AngelCréationd’un objet b b b b b b bManipulationdescapacités b b a b a a a\ bChangementdesdroits a\ c c c c c a cDélégation b b b a\ b b b bRévocation b b a\ c b a a a\ cVérification a a a a a a cAccèsauxobjets b c b b b b b

TAB. 4.2:Classificationdessystèmesabordésdanscechapitre

Onvoit quetouslessystèmesrépartisfournissentdesvariationsd’un mêmemodèledebasequi seclassifiedela façonsuivante: bacbaab.Onvoit égalementqueMachetAngelsontlesseulssystèmesàcapacitésrépartisqui n’entrentpasdansla classification“ ?a?????” dessystèmesqui nepermettentpasla réalisationd’unepolitiquedeprotectionmandataire(cf. page69).

Chapitre5

Présentationgénéraled’Arias

Danscechapitre,nousallonsprésenterla MémoireVirtuelleRépartieUniqueAriasqui aétédéveloppéedansle cadreduprojetSirac.Nousprésentonsd’abordlesmotivationsqui nousontamenéà réaliseruneMVRU, puislesobjectifsdecelle–ci.Nousdonnonsdefaçonsuccincteunevued’ensembledel’architectureAriasetdesaréalisation.Cettedescriptiond’Arias sertàidentifierlesconditionsrequisespourla protectiondanscesystème.

5.1 Moti vations

Ariasestunservicedegestiondedonnéespersistanteset réparties,réalisécommeunemémoirevirtuelle répartieunique.L’idéeà la based’Arias estdefournir la technologiedebasepourle développementdesapplicationsrépartiescoopérativesdansle cadreduprojetSirac.Cechoixdetechnologieestmotivéparlesargumentssuivants[Balter95] :

– Le modèledeprogrammationfourni parla mémoirevirtuelle répartieestplussimpleàutiliserquele modèleclient–serveurdèslorsqu’il s’agitdemettreenœuvredesapplicationsgérantdesdonnéespartagées.Cefait estmaintenantlargementreconnutantparla communautédessystèmespourle parallélismequeparcelledessystèmesrépartis.

– Lesoutilspourla réalisationdela cohérence,dela persistanceetdela toléranceauxfautesd’unemémoirevirtuelle répartiepeuventêtrerendusgénériqueset réutilisablespourdifférentesapplicationsetenvironnements.

– La mémoirevirtuelle répartiepeutservirdechampd’expérimentationpourlestravauxdeconstructiond’applicationscoopératives.L’adaptationdeceservicesystèmeàdestechniquesdecoordination,demiseaupointetd’observationdesapplicationsestundomaineencorepeuexplorédontonpeutattendred’importantesretombées.

– Lesprogrèsrécentsaussibiendanslesméthodesdemiseenœuvredesmémoiresvirtuellesrépartiesquedanslestechniquesderéseauxlaissentespérerl’obtentiondebonnesperformances.

Cesmotivationssontprincipalementorientéesversl’utilisation d’unemémoirevirtuellerépartiecommebasepourle développementdesapplicationsréparties.Par la suitenousdonnonsquelquesmotivationspourla gestiondecettemémoired’unefaçonuniqueetpersistante.

93

94 CHAPITRE5. PRÉSENTATION GÉNÉRALED’ARIAS

La MVR permetauxapplicationsqui coordonnentl’utilisation deleurespaced’adressagevirtuel departagerdesdonnéesenmémoireprincipaleetd’échangerdesdonnéesparsimpleréférence(enutilisantdespointeursversdesdonnéesstockéesdansla MVR). DessystèmesdeMVR traditionnelscommeIvy [Li89], Munin [Carter91], ThreadMarks[Keleher94] ouCVM [Keleher96]laissentla coordinationà la chargedesapplications.Pourpouvoir partagerlesdonnéesentreapplications,il fautunedésignationglobale,parexempleunecoordinationglobaledesadressesvirtuellesdansuneMVR. La conventiondegérerl’espaced’adressagedesprocessusd’unefaçonuniquepermetl’utilisation desadressesvirtuellescommedésignationglobale.Lesapplicationsn’ont plusbesoindecoordonnerlesadressesdesdonnéespartagées(ellessontcoordonnéespardéfinition),parcontreil fautunecoordinationdel’allocationetdela désallocationdela mémoirepartagée.Outrelesservicesd’uneMVR, unsystèmeMVRU fournit principalementcesservicesd’allocationetdésallocationdela mémoirevirtuelle.La réalisationdecesservicesdansAriasaétéle sujetd’unethèseantérieure[Han96].La gestionglobaledela mémoirevirtuellepermetauxapplications(qui seserventdelaMVRU) d’échangerdesdonnéesparréférence.L’espaceuniquepermetégalementl’introductiondela persistance: eneffet lesadressesvirtuellesidentifientdemanièreuniqueunerégiondemémoirecontiguëqui peutêtrestockéesurdisque.La persistancedela MVRU apportelesavantagessuivants:

– Un seulespacedenommage. Il n’y apasbesoindedistinguerentrelesréférencesvolatiles(lesvariablesduprogramme)et lesréférencespermanentes(lesfichiersoubasesdedonnées).

– Un seulniveaudestockage. Il n’y apasbesoindeconvertir lesstructuresdesdonnéesentreleur formatà l’exécution(structuresstockéesdanslesvariablesduprogramme)etleur représentationpermanente(le flot d’octetsd’un fichierséquentielou lestablesd’unebasededonnées).

5.2 Objectifs

Ariasapourbut defournir unsupportsystèmegénériquepourla programmationdesapplicationscoopérativesoudessystèmesd’exécution(“runtimesystems”)pourlesapplicationscoopératives.Différentesapplicationsetdifférentssystèmesd’exécutiondoiventpouvoir spécialiserAriaspourleursbesoinsprécis.Pourunsystèmedonné,il s’agit depermettreauxapplicationsd’utiliser différentsprotocolesdecohérenceetdesynchronisationouderendretransactionnelleslesopérationsmémoire.Onveutégalementpouvoir réaliserdifférentespolitiques(oumêmemodèles)deprotectionenproposantdifférentsmodesd’installationd’Arias.Lesobjectifsdela conceptiond’Arias sontdonc:

– fournir unsupportdeMVRU générique,qui peutêtrespécialisésuivantle contexted’exécutionet lesbesoinsdesapplications,

– proposerunmodèledeprotectiondebase,qui permetderéaliserdifférentsmodèlesdeprotectionspécifiques(parexemple,contrôled’accèsdu typeUnix oucontrôled’accèsbasésurdesrôles),

5.3. VUE D’ENSEMBLE D’ARIAS 95

– fournir auxapplicationsunensembledefonctionsqui permettentausystèmed’offrircertainesgarantiesencasdepannes,

– intégrerle toutà l’intérieur d’un systèmeexistantenpermettantl’inter–opérabilitéentrelesapplicationsd’Arias et celui-ci.

5.3 Vued’ensembled’Arias

L’architecturedebaseestconstituéed’un ensembledemachineshomogènesreliéesparunréseaulocal.Cesmachinessontdesstationsdetravail Unix muniesdesservicesderépartition(localisation),partage(cohérenceetsynchronisation),permanence(journalisationetgestiondustockage)etprotection(contrôled’accès).Certainesmachinesmuniesdedisques(parfoisappeléesserveurs),sontchargéesdustockagepermanentdesdonnéesgéréesdansla MVRU. Lesserveursfournissentuneinterfacehomogènepourla gestiondela permanencedesdonnéesentermesdevolumespermanents.Lanotiondevolumescachelesdétailsdustockagephysiquedesdonnées: lesdisqueset lessystèmesdefichiers.Parmi lesservicesdepermanence,noustrouvonségalementunservicedejournalisation,qui permetla réalisationdeprotocolesderepriseaprèspanne.La MVRU neconstituequ’unepartiedel’espaceadressabled’unemachine,l’autrepartieétantréservéeauxdonnéesprivéesetauxstructuresd’exécutiondela machine(parexemplelenoyaudusystèmeUnix). La MVRU sertdesupportd’adressagedesdonnéespermanentesmaisellepeutégalementcontenirdesdonnéesvolatiles(donnéespartagéespersistantesn’ayantpasd’imagesurdisque).Lesstructuresd’exécutionsontlesprocessusdusystèmeUnix danslequelcesservicessontintégrés.Le modèled’exécutiond’Arias seratraitéplusendétailen5.4.L’architectureglobaledusystèmeestillustréesurla Figure5.1.

Mémoire libre

Mémoire volatile

Mémoire permanente

Node 1 Node 2 Node 3

Disque A (Node 1) Disque B (Node 3)

processus 3

processus 1

processus 2

processus 4

processus 5

Mémoire virtuelle répartie unique

Espace d’adressage 64 bit

FIG. 5.1:Vued’ensembled’Arias

La mémoireestorganiséeensegments, detaille fixéeà la création,couplésdansla mémoireà


desadressesfixes.Ainsi, lesdonnéespartagéessontvuespartouslesprocessusà la mêmeadressevirtuelle,cequi permetd’utiliser lesadressescommeidentifiantsuniques.Le segmentestunesuitecontiguëdepagesdemémoirevirtuelle, identifiéparsonadressedebase.Il constituel’unité d’allocation,departageetdeprotectiondansArias.L’allocationet ladestructiond’un segmentsontexplicitesmaisle couplagedessegmentsdansla mémoired’uneapplicationestimplicite à la premièreréférence.Pourdiminuerle tempsd’accèsà la mémoire,chaquesegmentpartagéestdupliquésurtouteslesmachinesqui l’utilisent. Pourtraiterlesproblèmesdecohérence,Ariasoffre unservicedecohérencegénérique,qui permetla miseenœuvredeprotocolesdecohérencespécifiquesadaptésauxbesoinsdesapplications.Sinon,l’applicationpeutseservird’unebibliothèquedeprotocolespréfabriqués.Ariasestconçupourêtreintégréavecle systèmehôte(Unix), cequi permetàuneapplicationqui sesertd’Arias d’utiliser lesservicesetbibliothèquesd’Unix et viceversa.Le démarraged’uneapplicationsefait normalementàpartir du “shell” d’Unix. Pourqu’uneapplicationpuisseseservirdela mémoireArias, il fautquele processusréserveunerégiondesamémoirevirtuellepourcelle-ci.Cetteréservationestd’unetaille fixéelorsdel’installationd’Arias etdoit êtrela mêmepourtouslesprocessus.Ainsi, l’espaced’adressagedesapplicationsestdiviséendeux: unepartieréservéeà Unix etuneautreréservéeparArias (la partieAriasoccupeunepartiedu tas(“heap”)d’un processusUnix standard).Cettepartitionestillustréesurla figure5.2.

Machine 1 Machine 2

pile

Processus 1 Processus 2

Mémoire partagée

.text

.data

.bss

Arias

pile

.text

.data

.bss

Arias

FIG. 5.2:L’espaced’adressageArias

Le couplagedessegmentsdansla régionréservéeàAriassefait dynamiquement.La premièreréférenceàuneadressed’un segmentAriasgénèreuneexceptionUnix (“segmentationfaut”) ;le paginateurAriascouplele segmentà l’adressedonnéeet l’exécutionpeutreprendre.

5.4 Modèled’exécution

Il existedeuxfaçonsd’utiliser Ariasetparconséquentdeuxmodèlesd’exécutiondifférents.Ariaspeutêtreutilisésoit commeunservicetraditionneldemémoirepartagée(commelessystèmesmentionnésdansla section5.1),soit commesupportpourdevraiesapplicationsàespaced’adressageunique(applicationsoù le codeet lesdonnéessontstockésdansla

5.4. MODÈLE D’EXÉCUTION 97

mémoirerépartie).Dansle premiercas,Ariasn’apporterienaumodèled’exécutiond’Unix,tandisquedansle deuxièmecasle modèleimpliqueenfait uneintégrationentrelesstructuresd’exécutiond’Unix et cellesd’Arias. Par la suite,nousnousintéressonsuniquementàcederniertyped’applicationsquenousappelonslesapplicationsArias.UneapplicationArias regroupeunensembled’activitésqui coopèrentpouratteindreunbutcommun.Uneactivité consisteenunflot d’exécutionquelconquequi s’exécutedanslecontexted’un processusUnix. Touteslesactivitésqui s’exécutentdansle mêmeprocessusontlesmêmesdroitsd’accèscommedanslesprocessusnormaux(parexempleceuxd’Unix [Thompson74]), destâchesdeMach[Loepere92a] oudescontextesdeGuide-2[Cayuela92]).Ainsi le processusencapsulelesdroitsd’accèset sembled’êtreuncandidattrèsintéressantpourla réalisationd’un domainedeprotection(cf. 6.3.2).Arias fournit deuxmodesdecommunicationentreactivitésdansdeuxprocessusdifférents,parmémoirepartagéeouparappelsdirect(“IPC”) entreactivitéssurla mêmemachine.Outrecesmodesdecommunication,l’intégrationavecUnix permetauxactivitésdecommuniquerpartouslesmoyensdecommunicationfournisparcesystème.Chaqueactivité secomposed’un ouplusieursmodulesdecodestocké(s)dansl’espaceunique.Cesmodulespeuventappelerd’autresmodulesAriasoudesmodulesUnix sousformedelibrairiespartagées.Pourqu’uneapplicationAriaspuisseêtredémarréedepuisUnix, il fautqu’ellecontienneunefonctionmain standardUnix qui peutêtrelancéeparl’ exec standardUnix, normalementappeléeparle shell . La fonctionmain appelleunefonctiond’initialisationArias(AriasInit ) etaumoinsunefonctiondansunmoduleArias.Le main constitueainsilepontentrele systèmeUnix et le systèmeArias.LesfonctionsAriaspeuventappelerdesfonctionsAriasoudesfonctionsUnix.CommetouslesobjetsArias,unefonctionAriasestdésignéeparsonadressevirtuelle.Nousvoulonsquecettedésignationpuisseêtreréaliséesoit statiquementparuneéditiondeliens,soitdynamiquementaucoursdel’exécutiond’uneapplicationenpassantàunmoduleuneadressevirtuelledésignantunefonction.Unevueglobaledecemodèleestdonnéesurla figure5.3.

main

f1

f2

f2()

f = &f3f()

f3

printf

mod2

mod1

mod3

libC

main

f1()

printf()

FIG. 5.3:Vueglobaled’uneexécutionArias.

La figure5.3montrecommentl’applicationlancéeparUnix (le main ) appellela fonctionArias f1 dansle modulemod1, cettefonctionappelleuneautrefonctionArias f2 dansle


modulemod2. Cettefonctionappellela fonctionUnix printf suivi del’affectationdel’adressedela fonctionf3 aupointeurdefonctionf ; la fonctionf estensuiteappelée,cequiprovoquel’appeldela fonctionf3 dansle modulemod3.Cetexemplemontrecommentlesliaisonsentremodulespeuventêtreétabliesstatiquementàuneadressefixe (f1 et f2 ), statiquementà uneadressevariable(l’adressedeprintf estgéréeparle chargeurUnix) oudynamiquementàuneadressefixe(f = &f3 ). Enréalité,il estaussipossibledelier desfonctionsdynamiquementàdesadressesvariables,maiscelasepasseentièrementdansl’espaceUnix.

5.5 Réalisationd’Arias

Ariassecomposed’un ensembledeservicesprésentssurtouteslesmachinesdusystèmeréparti.Cesservicessont,pourl’essentiel,intégrésdansle noyaudusystèmeUnix pardesextensionsdunoyau(“LoadableKernelModules”).Ainsi, cesservicesprofitentdelaprotectiondel’espacedunoyauet ils nepeuventpasêtremodifiésparlesapplications.L’architecturelogicielledusystèmeestillustréesurfigure5.4.

Journalisation deGestionnaire

Communication

GCL

VOL

LOG

LOCGestionnaire

Protocoles spécifiques de cohérence/permanence

Applications

Paginateur

Noyau Unix

LOG = JournalisationVOL = StockageGCL = CohérenceLOC = Localisation

Modules STREAMS

Multiplexeur Arias

desVolumes

FIG. 5.4:L’architecturelogicielled’Arias

Surcettefigure,on trouveauplushautniveaulesapplicationsqui s’exécutentenespaceutilisateuretqui utilisentlesservicesoffertsparArias.L’interactionentrelesapplicationsetAriassefait principalementà traversdesmodulesqui réalisentlesdifférentsprotocolesspécialisésdecohérenceetdesynchronisationet lesprotocolesdepermanence.Cesmodulespermettentd’adapterle systèmeauxbesoinsparticuliersdesapplications.Lesdifférentsmodulesdecohérenceetdesynchronisationpermettentauxapplicationsdechoisirle modèle

5.6. CONDITIONSREQUISESPOURLA PROTECTIOND’ARIAS 99

le mieuxadaptéauxbesoinsdel’application,parexempleunecohérenceà l’entrée(“entryconsistency”) ouunecohérenceà la libération(“releaseconsistency”). La conceptionet lamiseenœuvredela cohérenceetdela synchronisationsonttraitéesplusendétaildansd’autresdocuments[Cortes95a,Cortes95b, Cortes96a,Cortes96b].De la mêmefaçon,lesmodulesdepermanencepermettentauxapplicationsdechoisirle modèledepermanencelemieuxadaptéauxbesoinsdel’application: parexemplecesmodulesfournissentdesprimitivespourmettreuneimagepermanentesurdisqueavantdetermineroupermettredesopérationstransactionnellessurla mémoire[Knaff96].Lesmodulesspécialiséss’appuientsurunepile deSTREAMS[STREAMS90]qui metenœuvrela plupartdesservicesd’Arias. Cettepile desmodulesSTREAMSréaliselesservicesgénériquesdecohérenceetsynchronisation(“GenericConsistency Layer(GCL)”) utilisésparlesmodulesspécialisésdecohérenceetsynchronisation,le servicegénériquedejournalisation(LOG) et le servicedegestiondevolume(VOL) qui sontutilisésparlesmodulesspécialisésdepermanence,le servicedelocalisation(LOC) qui permetdelocaliserunsegmentà partirdesonadressevirtuelle.Outrecettepile demodulesSTREAMS,noustrouvonsquelquesservicesdebase,notammentle paginateurArias.Il s’agitd’un gestionnaired’exception(“exceptionhandler”)qui traitetouslesdéfautsdesegment(“segmentationfaults”)générésparl’application.Si l’adressed’exceptionappartientàunsegmentArias, il s’occupedetrouveruneversioncourante(peutêtredansunvolumesurdisque)decesegmentet le chargedansla mémoiredel’application.Sil’adressen’appartientàaucunsegmentArias, le paginateurfait suivre l’exceptionausystèmeUnix (dansle plupartdescas,le gestionnaired’exceptiond’Unix varetourneruneerreuretarrêterl’application).

5.6 Conditions requisespour la protectiond’Arias

La réalisationd’uneMVRU tellequ’Arias imposecertainesconditionspourla protectionentreapplicationsetusagers.Cesconditionssedivisentendeuxgroupesprincipaux,cellesqui sontimposéesparla gestiond’un espaced’adressageuniqueetcellesqui sontimposéesparlacoopérationentreAriaset le systèmehôte.La réalisationd’un espaced’adressageuniquenécessiteuneséparationtotaleentreadressageetprotection.Le fait depouvoir désignerunestructurededonnéesenmémoirenesignifieplusquel’on peuty accéder, commec’estle casdanslessystèmestraditionnelsàbasedeprocessus(parexempleUnix).Le segmentestl’unité degestiondesdonnées: lesprotocolesdecohérenceetdesynchronisationet lesprotocolesdepermanencesontassociésauxsegments.Il noussembledoncnatureldelier égalementla protectionauxsegments.L’accèsàunsegmentestexplicitelorsdela créationetdela destructiondusegmentet implicite lorsducouplagedusegment.Lemécanismedeprotectiond’Arias doit réaliserunmoniteurderéférencesqui intervientlorsdecesopérations.Lesdroitsd’accèsauxsegmentsdoiventcorrespondreauxmodesd’accèsauxsegmentsdansunemémoirepartagéenormale,c’est–à–dire: lecture,écritureetexécution.Cetteinterprétationestconformeà la sémantiquedemmapdusystèmeUnix BSD[McKusick96].Normalement,lesdroitsdelectureetd’écritures’appliquentauxsegmentsdedonnéeset ledroit d’exécutionauxsegmentsqui contiennentducode.


Dansle chapitre3, nousavonsmontréquel’autorisationdoit sebasersurlessujetsabstraitsaulieu del’identité del’utilisateurqui adémarrél’application.C’estpourquoinousproposonsdebaserle mécanismed’autorisationsurla notiondedomainedeprotection(classiquedanslemodèleàcapacités)aulieu del’identificateurdel’utilisateurcourant.L’interactionpossibleentreAriasetUnix exigeunecorrespondanceentrelesdomainesd’Ariaset lesutilisateursUnix, c’est–à–direl’identificateurd’utilisateuretdugroupe.CesdeuxidentificateurssontdescaractéristiquesduprocessusUnix utiliséespourréaliserundomainedeprotection.NousdevonsdoncassocieràchaquedomainedeprotectionAriasuneidentificationsecondairequi consisteenunepaire<UID,GID> d’Unix. Cettepaireestassociéauprocessusdebased’uneapplicationparUnix lorsdela créationduprocessus.Lesvaleurssontdéterminéesparle mécanismed’authentificationd’Unix lorsdela procéduredelogin(1) . CesvaleurspeuventdoncêtreutiliséesparAriasdansle but d’authentifierl’utilisateurqui lancel’application.Pourlesdomainesd’Arias qui n’ont pasd’interactionsavecUnix, nousproposonsd’associerla paire<“nobody”,“nogroup”> d’Unix. Nousreviendronssurl’interactionentreAriasetUnix en7.1


Le modèledeprogrammationoffert parunemémoirevirtuelle répartieestplussimpleàutiliserquele modèleclient/serveurou le modèleàpassagedemessages.La MVRU donneunetransparencevis–à–visdela répartitionphysiqueetmasquela communicationentreprocessuscoopérants.Pournepascompromettrela transparenceainsiobtenue,le mécanismedeprotectiond’Arias nedoit pasla remettreencause.La réalisationd’uneMVRU nouspermetd’utiliser lesadressesvirtuellescommeidentificateursuniques.Cecinousoblige,d’unepart,à réaliserunmécanismedecontrôled’accèsauxdonnéesetnouspermet,d’autrepart,deréalisercemécanismeàbasedecapacités(l’adressevirtuellepeutservird’identificateurdel’objet). Le mécanismeàbasedecapacitéspoursondynamisme— la facilitéavecquelleonpeutfaireévoluerlesdroitsd’accès— etpoursagénéricité— la possibilitéderéaliserplusieursmodèlesdecontrôled’accèsdifférents— démontréplusloin (cf. 8.2).Pourpouvoir rendrela mémoirepersistanteet la partagerentreapplications,lesadressesdesdonnéesdoiventêtrefixespendanttoutela duréedevie desdonnées.Lesopérationsqui doiventprovoquerl’interventiondumoniteurderéférencesontlessuivantes: la créationet la destructionexplicite d’un segmentet le couplageimplicite d’unsegmentdansl’espaced’adressaged’un processus.L’interactionavecle systèmeUnix fournit uneauthentificationd’utilisateuràbasedesmotsdepasse,qui setransformeen<UID,GID> pourla partieinitiale d’uneapplicationArias,c’estàdire la partiemain qui s’exécutedansl’espaceUnix.

Chapitre6

Modèledeprotectionproposépour Arias

Le chapitreprécédentaprésentéle systèmeAriasd’unemanièregénéraleeta identifiéuncertainnombredeconditionsrequisespourla miseenœuvredela protectiondansuneMVRUtellequ’Arias.Danscechapitre,nousprésentonsunmodèledeprotectionpourAriasquipermetdemettreenœuvreungrandnombredepolitiquesdeprotectiondifférentes.La protectiona déjàétéle sujetdeplusieursétudes[Hagimont95, Saunier95]dansle cadreduprojetSirac,qui ontconduità la définitiondumodèledeprotectionparcapacitéscachées[Hagimont96]. Unepremièrethèseaétudiéla gestiondescapacitésdansle noyaudusystèmeet l’organisationdesdomainesdeprotection[Saunier96].Cettethèseseconcentresurla gestiondynamiquedesdroitsd’accèset surla réalisationdedifférentespolitiquesdeprotectionselonunmodèlegénérique.

6.1 Moti vations

La motivationpourla réalisationd’un mécanismedeprotectiondansAriasestderépondreauxproblèmesdeprotectionidentifiésen5.6etdefournir unmécanismedebasepourlaréalisationdedifférentespolitiquesdeprotectionpourdesapplicationsetdessystèmesd’exécutiondifférents.Lesconditionsrequisespourlesapplicationscoopératives(le typed’applicationviséparArias)sontlessuivantes:

1. Lesdonnéeset lesapplicationspeuventavoir uneduréedevie longue; il estdoncimportantquelesdroitsd’accèspuissentévoluerdynamiquement.

2. La natureinteractivedesapplicationscoopérativesimpliquele besoindediffusiondynamiquedesdroitsentreapplicationsouentredifférentsutilisateursdela mêmeapplication.

3. Lesutilisateursdesapplicationscoopérativespeuventappartenirà différentesorganisationsdansla mêmeentrepriseouàdesentreprisesdifférentesdansuneentreprisevirtuelle. Il fautdoncquele mécanismedeprotectionpermettedemettreenœuvreunepolitiquedeméfiancemutuelleentreutilisateursouservicesdusystème.

4. Pourrenforcertouslesmécanismesdeprotectionetdiminuerlesdégâtspotentielscausésparunprogramme,nousproposonsenplusdepermettrela miseenœuvreduprincipedumoindreprivilège(“the need–to–know principle”).

101

102 CHAPITRE6. MODÈLE DE PROTECTIONPROPOSÉPOURARIAS

6.2 Objectifs

Nousrappelonslesobjectifsdumodèledeprotectionmentionnésen1.3.

1. Généricitédumodèle. La généricitéaétéunbut principaldansla conceptiond’Arias.Pourcelail estnaturelquele supportpourla protectionpuisseêtremodifiéselonlemoded’installationd’Arias.

2. Facilité deprogrammation.Le modèledoit êtrefacileàcomprendreetutiliser, sinonilneserapasutiliséou lesspécificationsrisquentd’êtrefausses1.

3. Évolutivité.La spécificationdela protectiond’uneapplicationdoit pouvoir changerpendantla duréedevie del’application,sansrecompilationni re-éditiondesliens.

4. Réutilisabilitédescomposantslogiciels.Lesmêmescomposantslogicielspeuventêtreutilisésdansdescontextesetdesapplicationsdifférents.

5. Possibilitéd’intégrationdelogicielsconçusailleurs.Leslogicielsconçusailleurspeuventêtreencapsulésparle systèmeet leur interfaceaveccelui–ciouavecd’autresactivitésdansAriasdoit êtrecontrôléeparceluiqui installel’application.

6.2.1 Généricitédu modèle

Ariasaétéconçucommeunsupportgénériquepourlesapplicationset lessystèmesd’exécutionrépartis.Lesclassesd’applicationscibléesparle prototypesonttrèsvariéescommelesapplicationscoopératives,lessystèmesdegestiond’unebasededonnéesrépartieou le supportdansle noyaud’un systèmedefichier réparti.La généricitéd’Arias semanifestepardesinterfacesgénériquesqui permettentauxprogrammeursd’étendrele systèmeavecleurpropresmodulesqui adaptentle systèmeauxbesoinsdel’application.Pourl’instant il estpossiblepourunprogrammeurd’adapterlesprotocolesdecohérenceetdepermanencedela mémoireArias.Cecipermetderéaliserunlargespectred’applicationsdifférentes.Cesapplicationsont desbesoinsdeprotectiondifférents: lesapplicationscoopérativesontbesoindeprotégerlesdonnéesd’un utilisateurcontrelesmodificationsnon-autoriséesparlesautresutilisateurs; parcontrele systèmedefichier répartigèrelui–mêmele contrôled’accèsetil n’a pasbesoind’un supportdeprotectionparticulier. Il sembledoncnatureldeprendrelamêmeapproche,c’estàdire la généricité,parrapportà la protection.Cecinécessiteunmodèledeprotectioncapabledes’adapterauxbesoinsdesclassesd’applicationsdifférentes.Plusprécisémentnousvoulonsunmodèlesuffisammentgénéralpourpermettrela réalisationdemécanismesdifférentsqui mettentenœuvrela plupartdesmodèlesdecontrôled’accèsdécritsauchapitre3.La généricitédumodèlesetraduitparuneapprocheminimalisteauniveaudumodèleetceladirigecertainschoixderéalisation.

6.2.2 Facilité deprogrammation

La MVRU assureunetransparencevis–à–visdela répartitiondesdonnéesqui facilite laprogrammationdesapplicationsréparties.Le modèledeprotectionproposépourAriasdoit

1Une mauvaisespécificationde protectionestpire qu’unespécificationmanquante,parcequeceladonneunfauxsentimentdesûreté.

6.2. OBJECTIFS 103

faciliter la programmationdesapplicationsrépartiesdela mêmefaçon,c’est–à–direrendrelaprotectionla plustransparentepossiblepourle programmeur. Le programmeurdoituniquements’occuperdesaspectsalgorithmiquesdel’applicationet confierla spécificationdela protectionàunadministrateursystèmeouauresponsabledela sécurité.

La questiondetransparenceestunequestionrécurrentedansla conceptiondessystèmesrépartis.Nousnecroyonspasàunetransparenceabsolue,maisonpeutespérerrendretransparentela politiquedeprotectionspécifique.Nousreviendronsà la transparencedanslasection6.3.7.

6.2.3 Évolutivité

L’évolutiondesdroitsd’accèsdoit êtreconsidéréeendeuxtemps: pendantl’exécutiond’uneapplicationetentredeuxexécutionsdela mêmeapplication(oudeuxapplicationsdifférentesqui manipulentlesmêmesdonnées).

Lesapplicationscoopérativessecaractérisententreautreparun fort tauxdepartageentreutilisateursetunensembled’utilisateurstrèsdynamique.L’échangedesdonnéesentreutilisateursdansungroupedetaille variablenécessiteunmodèledeprotectionflexible.

Lesapplicationset lesinformationsstockéesdansle systèmeAriaspeuventavoir unelongueduréedevie et,pendantcetteduréedevie, lesdonnéespeuventêtreutiliséespardesapplicationsdifférentesoudansdescontextesd’exécutiondifférents.Il fautdoncquelesdroitsd’accèsassociésauxsegmentsd’Arias puissentévoluerdynamiquement

Enrésumé,l’évolutivité demandeunmodèledeprotectionflexible et trèsdynamique.C’estpourquoinousproposonsunmodèledeprotectionàbasedecapacités.

6.2.4 Réutilisabilité descomposantslogiciels

La rechercheengénielogiciel seconcentreaujourd’huibeaucoupsurla réutilisationducodeetla programmationparcompositiondescomposantsdéjàexistants.Parmi lesrésultatsdecetterecherche,on trouve leslangagesdeconfigurationd’applicationsetdedescriptiond’architectureslogiciellescommeOlan[Bellissard97] ouAster[Issarny97] ou lesplates–formespourexécuterlesapplicationscomposéescommeJavaBeans[Monson-Haefel99],CORBA [Geib97]etCOM [Kirtland98].

NoussouhaitonsprofiterdenotreMVRU pourpouvoir réutiliserla plupartdesmodulesdéveloppéspourArias.UneMVRU donneunevisibilité globaleauxmodulesdecode(composants),autrementdit “un espaced’adressageuniquerendle partagefacile,maisrendlenon–partagedifficile”.

Un moduledecodepeutenmêmetempsservirà l’intérieur d’uneapplicationouoffrir unserviceàdesclientsdifférentsdansunscénarioclient/serveur. Dansle premiercaslaspécificationdela sécuritédumodulehéritedela spécificationdel’application,dansladeuxièmecasla spécificationdela sécuritédel’interactionentreclientset serveurdoit êtreexpriméeexplicitement.La spécificationdela sécuritédoit doncêtredécoupléedelaspécificationducode.


6.2.5 Possibilitéd’intégration de logicielsconçusailleurs

L’intégrationdelogicielsconçusailleurspeutsefaireàdeuxniveaux: soit parl’intégrationd’Arias avecUnix, soit enmettantleslogicielsconçusailleursdansla mémoireAriasetenlesutilisantcommedesmodulesArias.CettedernièreméthodepermetdesoumettreceslogicielsaumodèledeprotectionArias.Lesprimitivesdela gestionducoded’Arias permettentd’extrairele coded’unebibliothèquedynamiqueUNIX etdele mettredansunmoduledecodeArias.Ensuite,cemodulepeutêtrelié avecd’autresmodulesAriaspourconstitueruneapplication.

6.2.6 Discussion

Le modèleàcapacitésaprincipalementétéchoisipoursasouplesseetsondynamismepourladistributiondesdroitsd’accès.La programmationparcomposantsintroduitdeuxmenacescontrela sécurité: le composantrisqued’êtreremplacéparuncheval deTroieet le composantn’estpasgarantideréaliserunepolitiquedeprotectionadéquat.Pourprotégerl’appelantcontreuncheval deTroie, il fautquele systèmegarantissel’authenticitéducomposant.Le risquequ’uncomposantneréalisepasunepolitiquedesécuritéadéquate,nécessiteunesuspicionmutuelleentrecomposants.Deplus,le systèmedoit impérativementrespecterle principedumoindreprivilège.Nousallonsd’abordrappelerlesraisonspourutiliser lescapacités,qui ont étédonnéesauchapitre3, etmontrercommentlescapacitésrépondentauxobjectifslistésci–dessus.

6.3 Modèledescapacitéscachées

Le modèledeprotectionparcapacitéscachéesaétédéveloppépourrépondreauxbesoinsdelaprotectiondansAriasetatteindrelesobjectifslistésci–dessus.Il s’agitd’uneextensiondumodèleclassiquedescapacitésconfinéesoù la gestiondescapacitéssefait parle système.

6.3.1 Vued’ensembledu modèle

Le modèledescapacitéscachéesestfondésurle modèleclassiquedeprotectionparcapacitéset lesélémentsdumodèled’exécutiond’Arias.Le droit d’accéderàunobjetprotégéestaccordéà undomainedeprotectionenpossessiond’unecapacitépourl’objet. Le domainedeprotection(ousimplementle domaine)estunsujetabstraitqui correspondà la définitionclassiquedudomainedeprotection(parexempleladéfinitionoriginaledela sphèredeprotectionparDennis& VanHorn).La gestionet la vérificationdescapacitéssontfaitesparle systèmed’unefaçontransparentepourlesapplications.Le modèlerespecteuneversionmodifiéeduprincipedela tranquillitédéfiniparexempleparle modèledeBell & LaPadulaoù la classificationd’un objetnepeutpaschangerpendantquel’objet estutilisé.Dansunmodèleàcapacités,cecisetraduitparle faitqu’unecapacitén’estpasrévocablependantl’utilisation del’objet qu’elledésigne.Nousproposonsdepermettrela révocationdela capacitésanssupprimerle droit d’accèsdéjàaccordéausujet.Cecinouspermetderéaliseruncontrôled’accèsbeaucoupplusefficaceoùlescapacitéssontvérifiéeslorsdupremièraccèsàunobjetprotégé.

6.3. MODÈLE DESCAPACITÉSCACHÉES 105

L’intégrationavecle modèled’exécutiond’Arias sefait dela façonsuivante: uneactivités’exécuteà toutmomentdansundomainedeprotectionqui définit lesdroitsd’accèsaccordésà l’activité. Cesdroitssontdéterminésparlescapacitésstockéesdansunelistedecapacités(C–liste)associéeaudomaine.Au coursdesonexécution,uneactivité particulièrepeutévoluerentreplusieursdomainesselonlesbesoinset la structuredel’application.La définitiondesdomainesdeprotectionet lesinteractionsentredomainessefaitindépendammentducodedel’applicationdanslesinterfacesdeprotection(voir 6.3.7pourlesdétails).Lesapplicationspeuventavoir plusieursactivitésrépartiess’exécutantdansle mêmedomainedeprotectionet/ouplusieursactivitéss’exécutantsurla mêmemachinemaisdansdesdomainesdeprotectiondifférents.Cettestructurationestillustréeparla figure6.1.

Appel direct

Domaine1 Domaine2 Domaine3

Site1 Site2 Site3

Activité1 Activité2 Activité3 Activité4

FIG. 6.1:Applicationsd’Arias protégées

La figuremontreuneapplicationcomposéedequatreactivitésdifférentess’exécutantdanstroisdomainesdeprotectiondifférentset répartiessurtroismachines.Lesdeuxactivitéssituéessurla mêmemachine(Activité1etActivité2)communiquentparappeldirecttandisquela communicationaveclesautresactivitéssefait uniquementparmémoirepartagée.Deuxactivités(Activité2etActivité3)s’exécutentdansle mêmedomainedeprotectionmaissurdeuxmachinesdifférentes.L’appeldirectentredeuxdomainesdeprotectionpermetl’amplificationou la dégradationtemporairedesdroitsd’accèsd’uneactivité enpassantparundomaineplusoumoinsprivilégié.Leslistesdecapacitésassociéesàchaquedomainepeuventcontenirdeuxtypesdecapacités:descapacitésd’accèsetdescapacitésdechangementdedomaine.Lescapacitésd’accèspermettentauxactivitésd’accéderauxobjetsprotégésdansle domainedeprotectioncourantetlescapacitésdechangementdedomainepermettentauxactivitésdefaireunappeldirectàunpointd’entréedansunautredomainedeprotection.Lesdomainesdeprotection,lescapacitéset lesappelsentredomainessontdécritsplusendétaildansla suite.

6.3.2 Domainesdeprotection

Un domainedeprotectionconstitueuneenceintedeprotectionqui décritl’ensembledesobjetsaccessiblesauxactivitésqui s’exécutentdanscetteenceinte,ainsiquelesdroitsenvigueurauseindudomainepourtouslesaccèsàcesobjets.Le domainedéfinitdoncnotammentl’ensembledecapacitésoudeC–listesdisponiblespouruneactivité àun instantdonnéen


identifiantuneC–listeprincipaleaudomaine.Cettelistepeutinclured’autreslistesetreprésenteainsipartransitivité unarbredecapacités,c’estpourquoinousappelonscetteC–listela liste racinedudomaine.La créationet la destructiond’un domainedeprotectionsontdesopérationsexplicitesdanslemodèle.La créationd’un domainesefait àpartird’uneC–listeexistantequi devient la C–listeracinedudomaine.UneC–listepeutainsiservirà la créationd’un seuldomaine.La destructiond’un domainesupprimel’associationentrela C–listeet le domaine.Mêmes’iln’y aplusdedomaineassociéà la C–liste,ellepeuttoujoursappartenirà l’arbredecapacitésd’un domainedifférent; nousnepouvonsdoncpasdétruirela C–listeavecle domaine.Nousremarquonsques’il n’y a pasderéférenceversla C–liste,la mémoireoccupéeparla listeesteffectivementinaccessibleetpeutêtreramasséeparle système.Un domainepeutêtrerépartiafindeprofiterdespossibilitésdeparallélismephysiqueoupourpermettreauxactivitéss’exécutantsurdesmachinesdifférentesd’avoir lesmêmesdroitsd’accès.Uneactivité peutévolueraucoursdesonexécutiond’un domainedeprotectionàunautre.Cependant,pourconserver l’étanchéitédecesdomainesdeprotection,il estnécessairedecontrôlerle passaged’un domaineàunautre.Cecontrôlesesitueàdeuxniveaux: lespointsd’entréequi permettentauxactivitésdetransférerle contrôleaudomaine,et le droit detransférerle contrôleà traverscespointsd’entrée.Ainsi uneactivité n’a pasle droit defranchirle domainedeprotectionpardespointsd’entréearbitraires,maisseulementpardespointsd’entréedéfinispourle domaine.Cesontexclusivementcespointsd’entréequi permettentàuneactivité dechangerdedomaineetqui peuventainsiservirdeguichetsdecontrôlepourvaliderourejeterl’entréed’uneactivité. Le changementdedomaineetsaréalisationdansAriassontdécritsplusendétailen7.8.La figure6.2donneunevisionglobaledesdomainesetdesarbresdecapacités.

partagé local non-partagéArbre de capacités arbre de capacités

partagé répartiArbre de capacités Activité

Domaine1 Domaine2 Domaine3

Site1 Site2 Site3

FIG. 6.2:Lesdomainesdeprotection

Cettefiguremontrela mêmeapplicationquela figure6.1.LesdeuxactivitéssurSite1partagentlocalementunsous–arbredecapacitésentrelesdeuxdomainesDomaine1 etDomaine2 et ils ontchacununsous–arbredecapacitésnon–partagées.LesdeuxactivitésdansDomaine2 s’exécutentsurdeuxsitesdifférentsmaisellesont le mêmearbredecapacitésà leurdisposition.La dernièreactivité s’exécutedansundomaineetsurunemachineàpart.Cetteactivité partageenrépartiunsous–arbredecapacitésavecDomaine2 .


Le fait quelesC–listespeuventêtrepartagéesenrépartirequiertunesynchronisationetunemiseencohérenceentremachinesqui accèdentauxmêmesC–listes.Cessynchronisationsetmisesencohérencenefont paspartiedumodèle,maisdoiventêtreréaliséesparla miseenœuvredumodèle.

6.3.3 Changementdedomaine

Le changementdedomaineestunmécanismequi permetunchangementtemporairedesdroitsd’accèsd’uneactivité. Le changementdedomaineprendla formed’un appeldeprocédurequitransfèrel’activité dudomained’origine(le domaineappelant)versundomainequi contientlesdroitssouhaités(le domaineappelé).L’activité s’exécuteaveclesdroitsdudomaineappelépourla duréedel’appelpuis,auretour, lesdroitsd’originesontrétablis.Ainsi le changementdedomaineestcomparableàunappelàdistancenormaldanslesarchitecturesclient/serveur.C’estpourquoinousappelonsle domaineappelantle clientet le domaineappeléle serveur.Uneactivité peuttraverserplusieursdomainesdeprotectionaucoursdel’exécutiond’uneapplication.Cecipermetàchaqueinstantà l’activité des’exécuteraveclesprivilègesminimauxnécessairespourréalisersatâche.Le changementdedomainepermetégalementla constructiondesystèmesextensibles(à partirdesservicesprotégés).L’appeld’un serviceprotégénécessitesouventle transfertdeparamètresentreappelantetappelé.Pourlesparamètrespassésparréférence,le modenormalpouruneMVRU, il peutaussiêtrenécessairedepasserle droit d’accèsauxdonnéesréférencéesparlesparamètres.Lesdroitsà transféreraveclesparamètressontexprimésdansuneinterfacedeprotection.Le changementdedomaineestuneopérationprivilégiéequi nécessitel’interventiondusystème.La structured’un changementdedomaineestmontréesurla figure6.3.

Arias

61

3 4

2

5

Domaine client Domaine serveur

FIG. 6.3:La structureduchangementdedomaine

L’activité qui s’exécutedansle domaineclientappelleuneprocédurequi doit êtreexécutéedansundomainedistant(le domaineserveur).Le sytèmeintercepteceappelet le transformeenunappelsystèmepourchangerdedomaine(1). L’appelsystèmeidentifiele domaineserveuret transfèrelesparamètreset lesdroitsd’accèsselonl’interfacedeprotection(2).Aprèsavoir transférélesdroitsd’accès,le systèmefait un “upcall” dansle domaineserveur, qui


appellela procédureappropriéeaveclesparamètresappropriés(3). La procédures’exécutenormalementmaisle systèmeinterceptele retourdeprocédurepourretourneraudomaineappelant(4). Le systèmetransfèrelesparamètresduretouret lesdroitsd’accèsassociésà cesparamètresselonl’interfacedeprotection(5). Puisle systèmeretournenormalementdansledomaineappelantcommesi la procédureavait étéappeléelocalement.La réalisationduchangementdedomaineestdécriteplusendétailen7.8.

6.3.4 Capacitésd’accès

Unecapacitéd’accèspermetàuneactivité d’accéderàunobjetdansle domainedeprotectioncourant.Touteslesactivitésqui s’exécutentdansle mêmedomainepeuventainsiaccéderàl’objet.Le modèlesupposel’utilisation decapacitésconfinées,c’est–à–diredecapacitésgéréesparlesystèmeetstockéeshorsdeportéedessujets.Cettegestiondescapacitéspeutêtreréaliséeparle noyaudusystèmeouparunmoniteurderéférenceexterneaunoyau.Enréalitéle modèlevaplusloin ensedonnantpourbut depermettreunetransparencetotaledel’utilisation descapacitésparrapportauxprogrammeursdesapplications.Le modèleproposeunevérificationimplicite descapacitésaumomentdupremieraccèsàunobjetprotégé.À cemoment,le systèmevérifiequele domainecourantdel’activité contientunecapacitépouraccéderà l’objet. Donc,il n’y apasdeprésentationexplicite dela capacitécommedansAmœbaoudansMach,ni debesoind’unecommandeexplicite pourpouvoiraccéderauobjet(commel’ open(2) d’Unix ou l’ attach() d’Opal).La transparencedel’utilisation descapacitésrendsuperflueuneinterfacedeprogrammationpourla protectionetparconséquentle modèleneprévoit aucuneinterfacedeprogrammationpourpermettrela manipulationexplicite descapacitésparlesactivités.Cecidit, le modèlen’interdit pasla réalisationd’unetelle interfaceparuneinstancedonnéedumodèle.L’utilisation descapacitésd’accèsdansle contexted’Arias estdécriteplusendétailen7.7.

6.3.5 Capacitésdechangementdedomaine

Le changementdedomaineestuneopérationprivilégiée.Pourpouvoir effectuerunchangementdedomaine,il fautquele domaineappelantpossèdele droit dele faire; cedroitexistesousla formed’unecapacitédechangementdedomaine.La capacitédechangementdedomainepermetà l’activité dechangersondomainedeprotectionà traversunpointd’entréeprédéfini.La capacitédechangementdedomaineidentifie: le pointd’entrée,le domainedeprotectionappeléet l’interfacedeprotectionà utiliserpourtransférerdescapacitésentrelesdeuxdomaines.La réalisationduchangementdedomaineestdécriteplusendétailen7.8.

6.3.6 Listesdecapacités

ChaqueC–listecontientunensemblededroitsqui peuventconstituerla based’un domainedeprotection.Cecinouspermetdegérerlesdomainesdeprotectionet lesC–listesdela mêmefaçon.Lesdroitsd’utiliser, inspecteroumodifierlesC–listesdoiventêtreprotégésparlesystème,c’est–à–direpardescapacités.


Lesdroitsd’accèspouruneC–listedoiventcomprendrelesdroitssuivants: utiliserunecapacité,rajouterunecapacité,copierunecapacitédansuneautreC–liste(soit la capacitéentière,soit unerestrictiondela capacité),lire la C–listeet supprimer/retirerunecapacité.Onpeutégalementenvisagerderajouterle droit deretirercertainescapacitésmarquées.Parexempleundomainepeutsupprimerlescapacitésqu’il a rajoutéesdansuneC–listepartagée.Cecipeutaussifaciliter la tâchederetirerlescapacitéspasséesenparamètrelorsd’unchangementdedomaine(undomaineappelantpeutsupprimer, auretourdel’appel, lescapacitéstransféréesà l’appeldansla C–listedudomaineappelé).Pourl’instantcesdroitsnesontpasbiendéfinisetnousavonstrouvéunautremoyenderetirerlescapacitésauretourd’unappeldechangementdedomaine.PourrajouterunecapacitédansuneC–liste,il fautquele domainepossèdele droit decopierlacapacitédansla C–listesourceet le droit derajouterunecapacitédansla C–listedestination.Lescapacitésdechangementdedomaineposentunautreproblème.Un serveurpeutavoirbesoindeconstruireunecapacitédechangementdedomainepourunservicequi n’existait pasauparavant,maisil fautempêcherle serveurdefabriquerunecapacitéquelconque.Sinonlacapacitéfabriquéepeutêtreutiliséepourdétournerlesappelsselonle schémasuivant: si undomainedeprotectionpossèdele droit derajouterunecapacitédansuneC–listepartagée,ilpeutrajouterunecapacitédechangementdedomainepourunefonctionfréquemmentutilisée(parexempleunappelauservicedenom)qui remplacele domainededestinationparundomainepiraté; toutesle capacitéspasséesenparamètreàcettefonctionsontalorstransféréesaudomainepiraté.Pouréviterceproblème,le droit derajouterunecapacitédechangementdedomaineestrestreintauxcassuivants: lescopiesdescapacitésdechangementdedomaineexistantes,lescapacitésdérivéesd’unecapacitéd’exécutionexistante(cecipermetàundomained’exporterdescapacitésmaisempêchela fabricationdescapacitéspourlesfonctionsfréquemmentutilisés— la fonctionlocalen’a pasla bonneadresse)ouunecapacitégénéréeparl’administrateurdusystème.L’administrateurdusystèmeestdanscecontextequelqu’unqui possèdeunecapacitéd’écrituresurle moduledecodeet le droit derajouterdescapacitésdansla C–listedudomaineappelé.

6.3.7 Interfacesdeprotection

La transparencedela protectionparrapportauxprogrammeursestl’innovationprincipaledumodèledeprotectionàcapacitéscachées.Cettetransparenceestobtenueparl’utilisation descapacitésconfinées,etparla façondefaireévoluerlesdroit d’accès— c’est–à–direl’échangedesdroitsd’accèspendantleschangementsdedomaine.L’échangedesdroitssespécifiecommeuneextensionà la descriptiond’interfaceavecl’IDL(“InterfaceDefinitionLanguage”)utilisépourla constructiondel’application.Nousappelonscettedescriptiond’échangedesdroitsuneinterfacedeprotection.L’interfacedeprotectiondoit identifierle pointd’entréedansle domaineappelé,et lesdroitspassésentreappelantetappelé.Lesdroitsd’accèséchangés,lorsd’un changementdedomaine,sontexprimésentermesdecapacitésd’accèset capacitésdechangementdedomaine.Pourrespecterla suspicionmutuelleet conserver l’étanchéitéentrelesdomaines,l’interfacedeprotectiondoit permettreà l’appelantetà l’appeléd’exprimerchacunleurproprevuesurlesdroitsà échanger. La listeexhaustivedescontrôlessurl’échangedescapacitéspeuts’exprimerparle tableausuivant:


pourle domaineappelant pourle domaineappeléà l’appel droitsofferts(capacitéssortantes) droitsnécessaires(capacitésentrantes)auretour droitsnécessaires(capacitésentrantes) droitsofferts(capacitéssortantes)

L’installationd’uneinterfacedeprotections’effectuedoncavecla participationduclientetduserveur, chacunspécifiantunepartiedescontraintespourleur interaction.Il fautdoncquel’interfacedechaquecotésoit inclusedansla capacitédechangementdedomaine.La capacitédechangementdedomainefixeainsilesdroitsqui peuventêtreéchangéslorsd’unchangementdedomaine.Le contrôledesinterfacesdeprotection(le contrôledescapacitésdechangementdedomaine)permetdoncla réalisationduconfinementparcequ’undomainenepeutpaspasserplusdedroitsd’accèsquel’interfacedeprotectionn’enspécifie.La réalisationdesdeuxinterfacesséparéespermetdebienréaliserla suspicionmutuelle.Enpratique,lesdeuxinterfacespeuventêtrespécifiéesparunadministrateurdusystèmeouunresponsabledela sécurité(celuiqui installel’application)qui prendencomptelesintérêtsdechaquepartie.

6.3.8 Changementdynamiquededomaine

Le changementdedomainedécritci–dessuspermetd’associeruneprocéduredansuncomposantavecundomainedeprotection.À chaqueappeldela procédure,l’activité esttransféréeversle domainespécifié.Danslesapplicationscoopératives,lesdonnéessontsouventstructuréesendifférentsdomainesselonl’utilisateur responsabledela gestiondesdonnées.Si plusieursutilisateursgèrentlesmêmestypesdedonnées,l’applicationvaavoir besoind’appelerlesmêmesfonctionsdansdifférentsdomainesdeprotection.Ceciestuniquementpossiblesi le systèmearriveà faireunelistedesdomainespotentiels(lesdomainesverslesquellesle domainecourantpossèdeunecapacitédechangementdedomaine)etàdistinguerentrecesdomainesaumomentdel’appel.La solutionproposéeici reposesurla gestiondescapacitésetdesinterfacesdeprotection.D’abordnousproposonsdepermettred’associerplusieurscapacitésdedomaineaumêmepointd’entrée.Cecipermetaudomaineappelantd’appelerla mêmeprocéduredansdesdomainesdifférents.La gestiondescapacitésestdécriteplusendétailen7.2.Prenonsl’exempled’un correcteurd’orthographedansunéditeurcoopératif.Chaquechapitred’un documentsetrouvedansundomainedeprotectionlié à l’usager(ougroupe)qui estresponsableduchapitre.Pourfaireunecorrectionorthographiqueglobaleil fautdoncappelerle correcteurd’orthographedanslesdifférentsdomainesdeprotection.Pourdistinguerentredomaines,il fautd’abordfairel’observationquela différenceprincipaleentrelesdomainesportesurl’ensemblededroitsqu’ils possèdent.Au niveaufonctionnel,iln’y apasdedifférenceentreappeleruneprocéduredansle domaineA ou le domaineB si touslesdeuxarriventà accéderauxdonnéesauxiliaires(lesdonnées— outrelesparamètres—nécessairesaubondéroulementdel’appel).Lesdeuxprocéduressontidentiques,donclesresultatsobtenusparlesdeuxappelssontidentiques.Alors la distinctiondoit sefaireauniveaudesdroitssurlesdonnéesauxiliairesgérésdansle domaine.Unepremièresolutionpourraitêtredefairel’appeletderevenirenarrièresi l’appelnepeutpassedéroulercorrectement,puisdechercheruneautrecapacitédedomaineet refairel’appel,etc.Cettesolutionnousgarantitle déroulementcorrect,si possibleaveclesdroitsdel’appelant,maisellen’estpastrèsefficaces’il y aungrandnombrededomainesàessayeret il fautquela

6.4. L’EXEMPLE D’UN SERVEUR D’IMPRESSION 111

fonctionsoit idempotente.Nousavonsdonctoutdesuitedecidéd’abandonnercettepiste.Unemeilleuresolutionsebasesurl’observationquelesdonnéesauxiliairessontnormalementidentifiéesparuneouplusieursréférencespasséesenparamètreà l’appel.Nousproposonsd’étendrela specificationdesinterfacesdeprotectionavecunelistedesréférenceset lesdroitsnécessairespourle déroulementcorrectdel’appel.Pourillustrer la solution,nousrevenonsàl’exempled’un correcteurd’orthographe(cf. figure6.4).

correcteur_orthographe(char *chapitre);

a) La signaturedela correcteurd’orthographe

correcteur_orthographe(CAPA_W RITE char *chapitre);

b) L’interfaceducorrecteurd’orthographe

FIG. 6.4:L’exempled’un correcteurd’orthographe

La signaturedela fonctionqui réalisele correcteurd’orthographeestmontrésurlafigure6.4a).L’interfacedeprotectionétendueestmontrésurla figure6.4b). Cetteinterfacespécifiequele domaineappelédoit possèderunecapacitéd’écriturepourl’adressepasséenparamètre(le chapitre ). Le systèmecherched’abordundomainedeprotectionqui possèdeunetellecapacitéparmilesdomainespotentiels(ceuxpourlesquelsle clientpossèdeunecapacitédechangementdedomaine)avanteffectuerl’appel.La spécificationcomplètedesinterfacesdeprotection(avecle changementdynamiquededomaine)estdécriteen7.9et la réalisationduchangementdedomaineen7.8.

6.4 L’exempled’un serveur d’impr ession

Lesprincipesdumodèlesontillustrésà l’aide d’un exemple: unserveurd’impression.Le serveurd’impressionabesoind’avoir unaccèsexclusif à l’imprimantepouréviterqueplusieursprocessusn’imprimentenmêmetempsetqueleslignessemélangent.Pourcela,undomainedeprotectionestcréépourle serveurd’impressionqui contientle droit d’accéderàl’imprimante.Le serveurd’impressionexporteunpointd’entréequi permetauxclientsd’appelerla procédureprint(char *texte) dansle domaineduserveur.Lesclientspeuventimprimerleurstextessurl’imprimante,à traverscepointd’entrée,endonnantenparamètreuneréférenceautexte.Pourpouvoir imprimerle texte, le serveurd’impressiondoit avoir le droit delire le segmentqui contientle texte.Le serveurpeutcontenirle droit delire touslessegments,maiscelaestenconflit avecle principedumoindreprivilège,doncnousproposonsquele client fournisseunecapacitédelectureavecle pointeur.Le pointd’entréeestdoncconstituédel’adressedela procédureetdel’interfacedeprotection(la signaturedela procédureet lesdroitsà transférerentredomainesà l’appelouauretour.)Unecapacitédechangementdedomaineestdistribuéeà touslesclientspotentielsduserveur(oudynamiquementà traversunservicededésignation).Cettecapacitépermetauxclientsde


passerdeleurdomaineaudomaineduserveur. L’appelduserveurd’impressionestmontrésurla figure6.5.

ced�f g�h�iej k�glh mon�kprint()

Client Serveur d’impression

1 23pbqrceqlpbf h nsi�kut k�pbh v�mok

texte

FIG. 6.5:Serveurd’impression

Quandunclientappellela procédureprint(char *texte) , le systèmevérified’abordquele clientpossèdela capacitédechangementdedomaineappropriée,puisl’interfacedeprotectionemballelesparamètreset transfèrelesdroitsd’accèsnécessaireset lesenvoieauserveur(1). Le serveurdéballelesparamètreset installela capacitédansle domainelocal (2),puisle serveurimprimele textesurl’imprimante(3) grâceà la capacitédelecturereçue.Auretourdel’appel le systèmedoit supprimerla capacitédansle domaineduserveur.

6.5 Récapitulation

Danscechapitrenousavonsidentifiélesbesoinsdeprotectionpouruneclassed’applicationsviséeparle systèmeArias : lesapplicationscoopérativesréparties.Nousavonsanalysélesimplicationspourle modèledeprotectionaveclesobjectifsmentionnésen1.3.La notiondedomainedeprotectionpermetdeconstruiredesservicesextensibles,parcequelefonctionnementd’un serveurpeutêtreencapsuléetprotégé.La principedetranquillitéimpliquequele contrôled’accèspeutsefaireuniquementlorsdupremieraccèsauxobjets.Il permetégalementun tauxdepartagedesdonnéesplusimportantentreutilisateurs(domainesdeprotection)mutuellementméfiants,parcequ’undomainepeutcontrôlerlesopérationssurlesdonnéesenexportantunecapacitédechangementdedomaineaulieu dudroit d’accéderdirectementauxdonnées.Pourconclure,la spécificationdumodèlequenousavonsprésentéeestvolontairementgénérale.Eneffet, le modèledeprotectionproposédanscettethèseestrelativementpeudépendantdesoncontexted’implantation(le systèmeArias)etnousverronsenconclusionquecemodèleseprêtebienàd’autresenvironnementsrépartis.

Chapitre7

Réalisationdu modèleproposé

Cechapitreprésenteuncompte–rendudétaillédela réalisationdumodèledeprotectiondansArias.Cetteprésentationestimportanteparcequ’elledéfinitetprécisele modèledanslecontexted’un MVRU, maisaussiparcequela réalisationdumécanismedeprotectionestdécisivepourla sécuritédusystème(cf. 2.9).

Avantdeparlerdela réalisationdumodèle,nousreprenonsle modèled’exécutiond’Arias etétudionsl’impact dela décisionderéaliserAriasd’unefaçoninteropérableavecle systèmehôte.

Ensuitenousanalysonsla gestiondescapacitésqui étaitomisedansle chapitre6 afindegarderla généralitédela descriptiondumodèle.La réalisationdumodèledansle contexted’Ariasnécessitedesprécisionssurle formatet la gestiondescapacités,maisaussisurla délégationetla révocationdescapacités.Cesprécisionssontdonnéesdanscechapitre.

Enfinnousdécrivonsl’utilisation descapacitéspourle couplagedessegmentsd’Arias et leschangementsdedomaine.Cecinouspermetenfindecaractériserle modèleselonla taxonomieintroduiteenchapitre4.

7.1 Inter opérabilité entreArias et Unix

L’interopérabilitéentreAriasetUnix aétéunbut importantdansla conceptiond’Arias. Celaimpliquequela réalisationd’Arias soit uniquementconstituéedecomposantsUnix,principalementdesbibliothèqueslogicielles,desextensionsdunoyauetdesprogrammesUnixpourdévelopperet installerlesapplicationsArias.

L’intégrationapourconséquencequetoutélémentdumodèled’exécutionAriasdoit avoir uncorrespondantdansle systèmeUnix qui le réalise.Dansla suitenousrappelonsle modèled’exécutiond’Arias etétudionscommentcetteinteroperabilitéaffectela réalisationd’Arias.

UneapplicationAriasestcomposéed’uneouplusieursactivités.LesactivitésexécutentlecodestockédanslessegmentsAriasoudanslesbibliothèquespartagéesUnix. Lesmodulesdecodesontcouplésdansl’espaced’adressagedel’activité selonlesbesoins.

Nousprécisonsdansceparagraphela définitiondesapplications,domainesdeprotection,activitésetmodulesdecode.

113

114 CHAPITRE7. RÉALISATION DU MODÈLE PROPOSÉ

7.1.1 Applications

UneapplicationAriassecomposed’uneouplusieursactivitésqui peuvents’exécutersurdessitesdifférentsetavecdesdroitsd’accèsdifférents.

7.1.2 Activités

Uneactivité d’Arias décritunflot decontrôleparticulierdansundomainedeprotection.Ellecorresponddoncà la notionde“thread”dansle systèmeAIX ; nousavonsdoncchoisideréaliserlesactivitésparles“threads”natifsdusystème.Uneactivité peutfaireunchangementdedomainetemporairepourexécutercertainsopérationsdansundomainedifférent(processus).

7.1.3 Domainesdeprotection

Un domainedeprotectionestdit passifs’il n’y apasd’activité associéeaudomaineouactif s’ily ena.Le domaineconsisteenunouplusieurscontextessurlessitesou le domaineestactif.La notiondecontexte ressemblebeaucoupà la notiondeprocessusdansle systèmehôte(AIX). Plusieuresactivitéspeuvents’exécuterenparallèleaveclesmêmesdroitsd’accès.Cesdroitsincluentenparticulierlesdroitsd’accèsàunensembledepagesdansla mémoire.Un domainepeutavoir plusieurscontextessurle mêmesite.Ils s’exécutenttousavecle mêmesdroitsd’accèsparcequ’ils partagentla C–listedebasedudomaine.Il existedeuxfaçonsdecréeruncontexte,soit commedomaineinitial d’uneapplicationArias,soit commeunserveurdedomaine.Cesdeuxtypesdecontextessontdécritsdansla suite.

Domaineinitial

Nousrappelonsqu’uneapplicationAriasestlancéeparunprocessusUnix. Ceprocessusfournit le contexted’exécutionparrapportaunoyaud’Unix. L’appeld’initialisationd’Ariastransformeceprocessusencontexte localdudomaine.Cettetransformationsecomposeprincipalementdel’initialisation desstructuresdegestiondemémoireAriasetdel’associationd’un domainedeprotectioninitial auprocessus.Si l’usagerdémarreplusieursapplicationsAriasenparallèleplusieurscontextesdumêmedomainevontêtrecréés.La créationdudomaineinitial estdécriteplusendétailen7.6.1.

Serveur dedomaine

Il existeunseulserveurdedomaineparsiteoù le contexteestactif. Le rôleduserveurestd’exécutertouslesappelsà cedomainesurle site.Pouréviterquele serveurdevienneungoulotd’étranglement,il gèreunnombred’activitéspourpouvoir répondreàplusieursrequêtesenparallèle.Touteslesactivitésdansle serveurs’exécutentavecla mêmeC–listedebase,maislescapacitéspasséesenparamètreauserveursontuniquementaccessiblesparl’activité quitraitel’appel.La créationd’un serveurdedomaineestdécriteenplusdedétaildans7.6.2.

7.2. GESTIONDESCAPACITÉSDANS ARIAS 115

Interopérabilité Arias - Unix

Pourpouvoir associerundomaineinitial auprocessus,Ariasgéreunelistedetouslesusagersetdeleursdomainesdeprotectioninitiaux.Pourqu’unserveurdedomainepuisseinteragiravecUnix, il fauttrouverunmoyend’associerlesdroitsd’accèsd’Unix (définisparunUID etunGID) audomaine.Soit l’UID etGID del’utilisateurcréateursontassociésaudomaine,soit unepaire w UID, GID x estprédéfiniepourchaquedomaine,parexempleà la créationdudomaine.Nousavonschoisid’associerunepaire w UID, GID x àchaquedomaineparcequecelacorrespondmieuxà la sémantiqued’un domainedansnotremodèle— touteslesactivitésquis’exécutentdansle mêmedomaineont lesmêmesdroitsd’accèssurlesobjetAriasetUnix. Engardantl’identité del’utilisateurcréateurdudomaine,différentesactivitésontdesdroitsd’accèsdifférents.

7.1.4 Modulesdecode

Lesmodulesdecodesontcomparablesauxbibliothèquespartagéesd’Unix. La visibilité d’unmoduledecodeestglobale,c’est–à–direquele moduleestdisponiblepourtouteslesapplicationsqui possèdentunecapacitépoury accéder.La résolutiondesréférencesàunmoduleeststatique,maisle chargementdumoduleestfaitdynamiquementselonlesbesoinsdel’application.

7.2 GestiondescapacitésdansArias

Ariasestconçupourunegrappedesmachineshomogènes.Nousnesommesdoncpasconcernésparlesmotivationsprincipalespourl’utilisation descapacitéschiffrées:l’hétérogénéitédesmachines,lesréseauxàgrandeéchelleet lessystèmesouverts.Nousespéronspouvoir offrir unserviceplusadaptableetplusefficaceengérantlescapacitésparle noyausanschiffrement,c’est–à–direenutilisantdescapacitésconfinées.Lescapacitésconfinéessontentièrementgéréesparle systèmequi connaîttouteslescapacitéspermettantd’accéderàunsegmentetqui peutmettreenœuvredesmécanismesingénieux; parexemplele systèmepeutgérerdescompteursderéférencespoursavoir quandunsegmentn’estplusaccessible(il n’existeplusdecapacités)etpeutêtresoumisauramassemiettes.La gestiondescapacitésconfinéesposenombredeproblèmes,notammentla création,lestockage,la délégationet la révocationdescapacités.Cesproblèmessonttraitésdansla suiteduchapitre.

7.2.1 Unepremièreétude

La gestiondecapacitésconfinéesétaitle pointcentraldela premièrethèsesurla protectiondansArias [Saunier96].A l’époque,la premièreversiond’Arias étaitencoursderéalisationet,parexemple,la gestionducodenécessaireà la réalisationduchangementdedomainen’étaitpasencoreréalisée.Enplusla réalisationdeSauniersebasesurl’utilisation desmodulesSTREAMSabandonnéedansle deuxièmeprototyped’Arias (Ariasv. 21). Pourêtre

1La version1 d’Arias a étéla plate-formededéveloppementpourla plupartdesmécanismesdécritdanscettethèse,maisla conceptiondela deuxièmeversiond’Arias étaitdéjàencoursdèsle départ.


compatibleavecla v. 2, nousnepouvonspasprofiterdecetteréalisation,maisnousallonstirerpartiedesanalysesfaiteparSauniersurle stockageet la recherchedescapacités.Lesrésultatsdela premièrethèsesontdécritdansla suite.

Stockagedescapacités

Dansla réalisationdeSaunierlescapacitésétaientstockéesdanslesstructuresdunoyauet lesmodulesdeSTREAMSétaientutilisépourgérerla répartitionet la cohérencedesC–listesentresites.La réalisationétaitentrelacéeaveccelle,desautresmodulesavecle risquedeprovoquerdesavalanchesdefautessi unemodificationetaitintroduitedansle moduledecohérence.Pournousrendreindépendantsdela versiond’Arias, nousproposonsdestockerdescapacitésdanslessegmentsd’Arias même.Celanouspermetdemanipulerlescapacitésselonl’APId’Arias (la probabilitédechangementdansl’API esttrèsfaible).Un segmentdecapacitésnedevra jamaisêtrecouplédanslesapplications.Le stockagedescapacitésdanslessegmentsd’Arias estdécritplusendétailen7.2.2.

Recherchedescapacités

Saunierproposedestocker lescapacitésdansdesarbresAVL2 pourpouvoir rapidementrechercherlescapacités.Il géraittouslestypesdecapacitésdansle mêmearbre.NousadhéronsàsonanalyseetgéronségalementlescapacitésdansdesarbresAVL.Sauniergéraitlesstructuresdansle noyauavecdespointeursde32bitsmaisnousallonsgérerlescapacitésdansla MVRU où lespointeurssontde64bits.Pouréviterungaspillagedemémoire,nousallonschangerla réalisationpourutiliser l’adressedebaseetundéplacement.Nousnepouvonsdoncpasreprendrela réalisationdeSaunier.La réalisationduchangementdedomainedécritedanscechapitrenécessiteunerecherchedela capacitédechangementdedomaineàchaquechangement.Nousavonsdécidédepartitionnerlescapacitésselonleur type,c’est–à–direqu’uneC–listecontienttroissous–arbres: unpourlescapacitésd’accès,unpourlescapacitédechangementdedomaineetunpourlescapacitésderedirection(cf. 7.2.4).

Résolutiondescapacitésdupliquées

L’échangedescapacitésposeunproblèmesi undomainedeprotectionreçoitunecapacitésurunsegmentsurquelil possèdedéjàunecapacité.La solutionproposéeparSaunierestderejeterla capacitéaveclesdroitslesplusrestrictifs.Si le domainepossèdeunecapacitédelectureet il reçoitunecapacitéd’écriturela capacitédelecturevaêtreremplacéeparcelled’écriture.Dansle casinverse,la capacitédelecturevaêtrerejetée.Dansle casd’unecapacitédechangementdedomaine,plusieurscapacitéspeuventexisterquipermettentdepasserdansdesdomainesdifférents.Le résultatdanscecasestnon–définiselonSaunier, maisil proposed’utiliser la premièrecapacitétrouvéedansle domaine.Nousavonsintroduit le changementdynamiquededomaineetunmécanismepourchoisirla capacitédedomaineàutiliser.

2La référenceoriginaledesarbresAVL estpubliéeenrusseenUnionSoviétique[AVL62], notreréalisationsebasesurla descriptionparKnuth [Knuth].


Récapitulation

Pourrendrelescapacitésinaccessiblesauxapplications,Saunierproposaitdelesstockeretdelesgérerdansle noyaudusystème.Nousproposonsdelesstockerdanslessegmentsd’Ariasmêmeetdelesgérerdansle noyau.Le systèmedoit s’assurerquelescapacitésd’accèsauxsegmentsdecapacitésnesontjamaisdiffuséesauxapplications.Nousadhéronsà l’analysequi aconduitSaunierà stocker lescapacitésdansunarbreAVL.Nousnepouvonspasreprendrela réalisationdeSaunieretnousavonsdécidédepartitionnerlesC–listesdanstroissous–arbresselonle typedela capacitéNousavonsreprisle mécanismederesolutiondescapacitésdupliquéesproposéparSaunieraveclesmodificationsliéesauchangementdynamiquededomainedécritesauparavant.

7.2.2 Stockagedescapacités

Uneservicedestockagedescapacitésdoit prendreencomptelesélémentssuivants:

– Persistancedescapacités

– Partagedesarbresdecapacitésentredomainesetmachines

– Séparationentrel’espaced’adressagedesapplicationset l’espaceréservéauxcapacités

Arias fournit desobjets(segments)répartis,partagésetpersistants.Il noussembledonclogiquedegérerlescapacitésdansla MVRU elle–même.Cecirèglelesproblèmesdepersistanceetdepartagedescapacités.Il fautseulementtrouverunesolutionpourlaséparationentresegmentsutilisésparlesapplications(pourlesdonnéeset le code)et segmentsutilisésparle systèmepourstocker lescapacités.Ceproblèmeesttraitédanscequi suit.

Segmentsdecapacités

La séparationentresegmentsdedonnéesetsegmentsdecapacitéspeutêtreréaliséededeuxfaçondifférentes: partypagedessegmentsouparrestrictiondedélégationdescapacités.Le typageassocieun typeàchaquesegment,parexempleunsegmentdedonnéespartagées,unsegmentdecodeouunsegmentdecapacités.À la demandedecouplagedusegment,lesystèmevérifie le typeet la demandeselonle type.Enreprenantlesexemplesci-dessus,lemodedecouplaged’un segmentdedonnéesdépenddescapacitésdisponiblesdansle domaine,le couplaged’un segmentdecodedéclenchela liaisondynamiquedeslibrairiesUnix utiliséesparle codeetunsegmentdecapacitéspeutuniquementêtrecoupléparl’administrateurdusystème(ceciestnécessairepourréaliserdesoutilsd’administrationdescapacités).La restrictiondedélégationdescapacitésadéjàétémentionnéeci–dessus.La créationd’unsegmentdecapacitésestuneopérationprotégéequi s’effectuedansundomainedeprotectionparticulier(le super–domaine).Touteslescréationsdesegmentsdecapacitéssontfaitesparunchangementdedomaineverscedomaine.Cedomainerécupèrela capacitéd’accèsausegmentet retournel’adressedusegmentà l’appelantavecunecapacitépourmanipulerla C–listestockéedansle segment.L’applicationpeututilisercetteC–listepourcréerundomainedeprotectionoumanipulerdescapacités(si le systèmeréaliseuneinterfacedeprogrammationpourlescapacités).Le systèmenedonnejamaisdecapacitéd’accèssurlessegmentsquistockentlescapacitéset il n’acceptejamaisdemanipuleruneC–listequi nesetrouvepasdansle superdomaine.


La deuxièmesolutionmontrequela gestiondessegmentsdecapacitéspeutêtreréaliséeàl’intérieur dumodèle(ceciestunevertudumodèle).Elle estla plusattrayantesurle planesthétiqueet théorique,maisla premièreestplussimpleà réaliser. Nousavonsdoncchoisi,dansunpremiertemps,deréaliserle typagedessegments.

Remarque! La réalisationdu typagedessegmentsn’exclut pasla restrictiondedélégationdescapacités.Il suffit encapsulerl’appeldecréationdesegmentdansunmoduleducodeArias(qui estuniquementaccessibleparle superdomaine)et forcerlesapplicationsàutilisercemodule,c’est–à–direl’appelsystèmedecréationdesegmentdoit vérifierquel’appelestissudusuperdomaine.

7.2.3 C–listes

Lescapacitésd’unemêmeC–listesontstockéesdansunmêmesegment; enfait l’associationdirecteentreuneC–listeetunsegmentd’Arias nouspermetdenommerla C–listeparl’adressedebasedusegment.Chaquesegmentqui contientuneC–listedébuteparuneen–têtecontenantquelquesinformationsadministratives(parexemplel’UID et le GID Unix àutilisersi la C–listesertdebaseà undomainedeprotection)et la racinedechaquearbredecapacitésdetypesdifférents.

7.2.4 Format descapacités

Nousavonsbesoindequatretypesdecapacités: capacitésd’accès(pourcouplerlessegmentslocalement),capacitésdedomaine(poureffectuerunchangementdedomaine),capacitésderedirection(pouroutrepasseruneinterfacedeprotectiondansunecapacitédedomainereçuedynamiquement)etcapacitésdelistes(pourpouvoir utiliser lescapacitéstockéesdansuneC–liste).Lesformatsdecestypesdecapacitéssontdécritsparla suite.

Capacitésd’accès

Le formatd’unecapacitéd’accèsestillustrésurla figure7.1.

Adresse du segment Droits de délégationDroits d’accès

FIG. 7.1:Formatd’unecapacitéd’accès

L’adressedusegment(8 octets)identifiele segmentauquella capacitéautorisel’accès.Lesdroitsd’accèssontspécifiésparunvecteurdebitsde(2 octets)et lesdroitsdedéléguerlacapacité(cf. 7.4)sontspécifiésparunvecteurdebits (2 octets).Unecapacitéd’accèsoccupedonc12octets.

Capacitésdechangementdedomaine

Le formatd’unecapacitédechangementdedomaineestillustrésurla figure7.2.


Adresse de la procédure

Droits de délégation

Adresse du talon client Adresse du talon serveur

Domaine appelé

FIG. 7.2:Formatd’unecapacitédechangementdedomaine

L’adressedela procédure(8 octets)identifiele pointd’entréeautorisédansle domainespécifiéparle domaineappelé(8 octets)3. Le talonclient (8 octets)identifiele segmentdecodeàcouplerà la placedela procédure,et le talonserveur(8 octets)spécifiel’adresseà laquellelesystèmedoit faireun“upcall” dansle domaineappelé.Lesdroitsdedélégationsontlesmêmesqu’avecunecapacitéd’accès.

Capacitésde redirection

Le formatd’unecapacitéderedirectionestillustrésurla figure7.3.

Adresse du talon clientAdresse de la procédure

FIG. 7.3:Formatd’unecapacitéderedirection

L’adressedela procédure(8 octets)identifiela procédurequ’il fautsurchargeret l’adressedutalonclient (8 octets)identifiele segmentdecodequi doit êtrechargéàsaplace.La tailled’unecapacitéderedirectionest16octets.

Listesdecapacités

Le formatd’unecapacité4 suruneC–listeestillustrésurla figure7.4.

C-liste Droits de manipulationAdresse de la C-liste

FIG. 7.4:Formatd’unecapacitésuruneC–liste

L’adressedela C–liste(8 octets)spécifiel’adressedusegmentqui contientla C-liste.LechampC–liste(2 octet)identifiela capacitécommeunecapacitésuruneC–liste.Outrelesdroitsdedélégationspécifiéspourunecapacitéd’accès,lesdroitsdemanipulationincluentlesdroitssuivants: utilisationd’unecapacitédansla C–liste,rajouterunecapacitédansla C-liste,révoquerunecapacitédansla C-listeetsupprimerla C–liste.

Discussion

Lesformatsdecapacitésspécifiésici permettentdegérerlescapacitésdansdesstructuresdetaille fixe,soit 32octetspourla plupartdescapacités,soit 64octetspourlescapacitésdechangementdedomaine.Cecifacilite l’allocationet la gestiondesC–listesdanslessegmentsd’Arias parcequelesstructuresdedonnéessonttoujoursalignéessurunepage.

3Nousutilisonsl’adressedu segmentqui contientla C–listedebasedu domainecommeidentificateuruniquedudomaine

4Le formatestle mêmequela capacitéd’accès,maisleschampssontinterprétésdifféremment.


Nousn’avonspasdenotiondepropriétaired’unesegmentoud’unecapacité,maisladifférenceentaille entrelesstructuresdegestiondescapacitésdansl’arbreAVL (32octets)etlescapacitésd’accèset lescapacitéssuruneC–listes(12octet)estsuffisammentgrandepourqu’onarrive,si nécessaire,à inclurel’identificateurdupropriétairedudomainedanslacapacité.

7.3 Création descapacités

Lescapacitéssontnormalementcrééslorsdela créationd’un segmentet lorsqu’undroitd’accèsesttransféréentredeuxdomainesdeprotection.Lorsdela créationd’un segment,unecapacitéqui contienttouslesdroitssurle segmentestrajoutéedansla C–listeracinedel’appelant.Le transfertdedroitsd’accèsestréaliséparunecopiedela capacitéqui correspondauxdroitsd’accèsdansle domaineappelantet l’installationdecettecapacitédansle domaineappelé.

Cesmécanismesdecréationdescapacitésnécessitentunsystèmebienconfiguré.Il y adoncunproblèmededémarragedusystème(créationet configurationdespremiersdomainesdeprotection).Pourrésoudreceproblème,nousproposonsunensembledeprimitivesdecréationetd’administrationdescapacitésuniquementdisponiblepourl’administrateurdesystème.Cesprimitivesdoiventlui permettredecréer, initialiseroumanipulerdeslistesdecapacitésdansdesdomainesdeprotectiondifférents.Cesprimitivessontdécritesdansl’annexeB.

L’administrateurdesystèmeobtientle droit demanipulerlesC–listesparcequ’il créelessegmentsd’Arias qui contiennentlescapacités(le stockagedescapacitésesttraitéplusendétaildansla section7.2.2).Danscesens,tout le mondepeutêtreadministrateurdecertainesapplicationsouutilisateurs(encréantlesdomainesdeprotectioncorrespondants)etonn’a pasbesoindeprivilègesparticuliersoud’un utilisateurtout-puissant.Cecipermetuneadministrationdesystèmesoupleetdécentralisée.

Mêmesi l’administrationsefait demanièredécentralisée,le besoind’intervenird’unefaçonglobalepeutseprésenter(parexemplepourretirerunecapacitéglobalement).Nousproposonsdoncd’insérertoutesleslistesdecapacitésdansunehiérarchieglobaledescapacités(lescapacitésnesontpashiérarchiquesparnature,nousn’attendonsdoncpasquecettehiérarchiedeviennetrèsprofonde).La hiérarchieglobalenouspermetderéaliserdesmécanismesd’administrationglobaledescapacités,parexemplela recherchedesdomainesqui contiennentunecapacitésurunsegmentdonnéou la révocationglobaled’unecapacité.Cesopérationssontnormalementtrèsdifficilesdanslessystèmesàcapacitésmaisavecla hiérarchieglobale,ils seréduisentàunsimpleparcoursd’un arbreenmémoirevirtuelle.

Le domainedeprotectioncontenantla C–listeracinedevientunsuper–domainedemêmefaçonqueroot estunsuper–utilisateurdansunsystèmeUnix. Nousproposonsdoncd’associercesuper–domaineausuper–utilisateurdusystèmeUnix qui constituenotreplate–formedebase.De toutefaçonle root d’Unix aplusieursfaçonsdecontournerlesmécanismesdeprotectiond’Arias (il peutaccéderdirectementauxsegmentspermanentssurdisque,il peutaccéderà lamémoiredirectementpar/dev/kmem et il peutassumerl’identité dechaqueutilisateurdusystèmeetdémarrerdesapplicationscommecetutilisateur).Il n’y adoncpasderaisonspourlimiter l’accèsdu root d’Unix auxC–listesd’Arias si celaestjugécommode.

7.4. DÉLÉGATION DESCAPACITÉS 121

7.4 Délégationdescapacités

Uneapplicationqui possèdelesdroitsd’accèsnécessairepeutcopierdescapacitésentreC–listesdanssonpropredomaineou transférerdescapacitésàunautredomainedeprotection.

7.4.1 Le droit dedélégation

Le droit decopieretdetransférerunecapacitéestdéterminéparunchampdansla capacitémême(le droit dedélégation).Lesopérationsdecopieoudetransfertd’unecapacitésontidentiquesdansle sensoùuneC–listepeutêtrepartagéeentreplusieursdomaines.La restrictionsurle droit decopierlescapacitéspermetderéaliserunmodèledeconfianceplusouvert,parcequ’undomainepeutdéléguerunecapacitéàunautredomainesansrisquerladiffusionglobaledela capacité.Le droit decopierunecapacitédoit êtrevérifiéparle moniteurderéférenceavantquelacapacitésoit copiéeentreC–listesouqu’ellesoit passéeenparamètrelorsd’un appeldechangementdedomaine.La vérificationestfaiteparunmodulappelémoduledepolitiquedansle moniteurderéférence5. Un moduledepolitiqueestdéfiniparl’administrateuretfixéaumomentdel’installationdusystèmeArias.Par la suitenousprésentonsla politiquepardéfautd’Arias.

7.4.2 La politique par défaut d’Arias

Unecapacitépeutêtrecopiéetellequelleou lesdroitsinclusdansla capacitépeuventêtrerestreintsavantla copie.Le formatd’unecapacitéd’accès(ouunecapacitésuruneC–liste)contientdeuxchampsqui peuventêtrelimitésavantla copie.Il y adonccinqpossibilitéspourle droit dedélégation: aucundroit decopierla capacité,le droit decopierla capacitéavecunerestrictionsurlesdroitsd’accès,le droit decopierla capacitéavecunerestrictionsurlesdroitsdedélégation,le droit decopierla capacitéavecunerestrictionsurlesdroitsd’accèset lesdroitsdedélégationet le droit decopierla capacitésansrestriction.

Aucun droit dedélégation.La capacitépeutêtreutiliséeparle domaine,maisellenepeutpasêtrecopiéedela C–listed’extensiondudomaineoupasséeenparamètreàunautredomaine.

Restriction sur lesdroits d’accès.La restrictiondesdroitsd’accèsimpliquequ’unecapacitédelectureouunecapacitédechangementdedomainenepeutpasêtrecopiée,unecapacitéd’écritureesttransforméeencapacitédelectureetunecapacitéd’exécutionesttransforméeenunecapacitédechangementdedomaineversle domainecourant.Lanouvellecapacitépossèdelesmêmesdroitsdedélégationquel’originale.

Restriction sur lesdroits dedélégation.La restrictionsurlesdroitsdedélégationimpliquequela capacitépuisseêtrecopiéedela C–listed’extensiondedomaineetinstalléedansla C–listedebasedudomaine.La copienepossèdeaucundroit dedélégation.

5Unecapacitéderedirectionpermetà un domainedeprotectiondesurchargeruneprocéduredansle domainecourant.Il n’y a pasde ressourceprotégéeassociéeà la capacité; le systèmepermetdonctoujoursdecopiercetypedecapacité.


Restriction sur lesdroits d’accèset lesdroits dedélégation.Lesdroitssontlimitéscommedécritci–dessus.

Aucunerestriction. Le domainequi reçoitla capacitéestlibre dela copierentresesC–listesetdela passerenparamètreauxautresdomaines.

Lesrestrictionsdécritesci–dessussontvérifiéesparle système,maisellesdoiventégalementêtrespécifiéesparlesinterfacesdeprotection.Cettespécificationpermetà l’applicationdelimiter lesdroitsdescapacitéspasséesenparamètre.Si l’interfacespécifieundroit plusprivilégiéqueceluiquele domainepossède,unmessaged’erreurestretournéà l’application.À la créationd’un segment,le systèmeinstalleunecapacitéavectouslesdroitsdansla C–listedebasedudomaine.Cettecapacitépeutserviràcréerd’autrescapacitésetà lescopierdansd’autresC–listes.Unecapacitépasséeenparamètreestinstalléedansla C–listetemporairedel’activité qui traitel’appel (cf. 7.8.4)etelleestrévoquéeauretourdel’appel.Si la capacitéinclut la droit dela copier, le talonserveurpeutdemanderausystèmedecopierla capacitéversunedecespropresC–listes,parexemplela C–listedebasedudomaine.

7.5 Révocationdescapacités

Le problèmederévocationdescapacitésestunproblèmeclassiqueet importantdanslessystèmesàcapacités.Nousavonsidentifiédeuxméthodespourretirerunecapacité: larévocationautomatiqued’unecapacitétransféréelorsdu retourd’un appeldechangementdedomaine,et la révocationexplicite.

7.5.1 Révocationautomatique

Lescapacitéstransféréeslorsd’un appeldechangementdedomaine,serventnormalementpourquele serveurpuisseaccéderauxdonnéesnécessairesdudéroulementdel’appel.Aumomentdu retour, le serveurn’a normalementplusbesoindecesdroitsd’accèset ils doiventêtreretirés(d’aprèsle principedumoindreprivilège).Pourpouvoir retirerlescapacitéslorsduretourdel’appel, le systèmedoit garderunedescriptiondescapacitésreçuesdechaqueclient (cf. 7.8).Le systèmedoit aussiassurerqueunetellecapaciténepourraêtrecopiéeparle serveurques’ilena reçule droit.

7.5.2 Révocationexplicite

Leslistesdecapacités(lesdomaines)sontorganiséesdansunearborescence,cequi permetàunadministrateursystème(celuiqui a crééla premièreliste)deparcourirtoutesleslistesdecapacitésetderévoquerlescapacitésselonsessouhaits.

7.6 Création d’un domainedeprotection

La définitiond’un domainedeprotectionestpersistante,c’est–à–direquele domaineexisteindépendammentduprocessusqui le réaliseeffectivement.Un domainedeprotectionpeutêtreassociéàunprocessusdedeuxfaçonsdifférentes: audémarraged’uneapplicationArias (le

7.6. CRÉATION D’UN DOMAINE DE PROTECTION 123

domaineinitial del’application)età la créationd’un processuspourexécuterunappelavecchangementdedomaine(ceprocessusestappeléunserveurdedomaine).

7.6.1 Création d’un domainedeprotection initial

Lesapplicationsd’Arias sontlancéesà partirdushelld’Unix, soit commedesprogrammes,soitparun lanceurgénériquedesapplicationsd’Arias. Au momentdu lancement,l’applicationexisteuniquementdansla partieUnix dusystème.L’appelàAriasInit (décriten5.4)vatransformerle processusUnix enapplicationArias,c’est–à–direqu’il vaassocierundomainedeprotectionauprocessus.Cetteassociationpeutêtrefaiteinteractivementparl’utilisateur (parexempleà l’aide d’un motdepasse),ouparle système,qui choisitundomaineinitial à partirdesparamètresdudémarrage(nomdel’applicationet l’UID et le GID del’utilisateur).Pourpouvoir exécuterlesapplicationsenarrière–plan(sansinterventiondel’utilisateur)nousavonschoisid’associerundomainedeprotectionàpartir desparamètresdudémarrage.L’interprétationduGID dépenddela versiondusystèmeUnix : dansSystemV l’utilisateurchoisitsongroupecourantavecla commandenewgroup(1) , parcontredansBSDl’utilisateurs’exécuteà toutmomentavectouslesdroitsdetouslesgroupesauxquelsilappartient.Nousavonschoisidenousreposersurl’interprétationduGID la plusgénérale,c’est–à–direcelledeBSD.regarderle GID duprocessus.La déterminationdudomaineinitial àpartir dela combinaisondela commandeetdel’utilisateursupprimedumodèledeprotectionunedécisionsurla sécurité.Enplus,elleintroduitplusieursproblèmessupplémentaires: parexemplecommentréagirsurdifférentsnomspourla mêmecommande(différentliensversle mêmebinaire)ouqu’est-cequi sepassesi unecommandeestrenommée? Enfin lesdifférentesapplicationsvontnormalementappelerdifférentsmoduledecode,onpeutdoncs’assurerquedifférentesapplicationssontexécutéesdansdifférentsdomainesdeprotectionendonnantdifférentescapacitésdechangementdedomaineaudomaineinitial. C’estpourquoinousavonschoisid’associerundomaineinitial àchaqueutilisateur. Le choixdudomained’applicationàpartirdudomaineinitial estmontrésurla figure7.5.

Domaine "client base des données"

edit()

Domaine "tableau blanc réparti"

Domaine "editeur coopératif"

Domaine initial

select()

draw()

FIG. 7.5:Domaineinitial et lesdomainesapplicatifs


synchronisation

f()f()

structure de

proto-serveur

19

4

5

6

Application client

2

3

Domain

Serveur de domaine

Protection

87

Daemon

DomainModule

Protection

FIG. 7.6:Créationd’un serveurdedomaine

La figuremontreundomaineinitial et troisdomainesapplicatifs.La premièrefonctionappeléeparl’applicationdécideversqueldomainel’applicationvapasser: la commandeedit() vapasserdansle domainedel’editeurcoopératif,draw() vapasserdansle domainedu tableaublancrépartietselect() vapasserdansle domainedela basededonnées.

7.6.2 Création d’un serveur dedomaine

Quandle clientappelleunefonctionqui nepeutpasêtrecoupléedansle domainedeprotectionduclient, le systèmevachercherunecapacitédechangementdedomaine.Si unetellecapacitéesttrouvée,l’appelvaêtretransforméenappeldechangementdedomaineversle domaineserveuridentifiéparla capacité.L’appelsedérouledansunprocessuscrééspécialementpourtraiterlesappelsdechangementdedomaine; ceprocessusestappeléunserveurdedomaine.Un serveurdedomaineestcréedynamiquementaupremierappelà cedomainesurle site.Ceserveurserautilisépourlesappelssuivants.Pouréviterungoulotd’étranglementdansleserveurdedomaine,chaqueserveurest“multi–threadé”,le nombrede“threads”étantunparamètred’installationd’Arias. Le schémadela créationestmontrésurla figure7.6.Le traitementd’un appeldechangementdedomainecherched’abordà identifierle processusqui réalisele serveurdedomaine(1). S’il n’existepasle systèmevacréerunprocessusetl’initialiser commeserveurdudomaine.Le systèmecréelesstructuresdesynchronisationentreclientet serveur, chaînelesparamètresdel’appeldanscettestructureet interromptl’appelantcommedansunappeldedomainenormal(2).Ensuitele systèmepassel’adressedela structureenparamètreàun “upcall”6 versle serveurqui s’occupedela créationdesserveursdedomaine.Notreversiond’Unix (AIX) nepermetpasla créationdesprocessusdepuisdesextensionsdunoyau,noussommesdoncobligés

6Il n’y a pasun mécanismed’“upcall” généraldansUnix, donctousnos“upcalls” sonten réalitédesretoursauxappelssystèmeprécédents.

7.7. COUPLAGED’UN SEGMENT 125

d’avoir undaemonArias (le “ProtectionDomainDaemon”– PDD)aveccommeseuletâchedecréerlesserveursdedomaine(3). Ceserveura lesdroitsderoot pourpouvoir initialiser leprocessusavecle domainedeprotectionet lesUID etGID correspondantàcedomaine.Le serveurdecréationdesdomainescréeunprocessusqui exécutele programmeproto–serveur(4). Le proto–serveurinitialise l’utilisation d’Arias et créeplusieurs“threads”qui font unappelsystèmepourattendredes“upcalls” (5). Un decesappelsvaeffectivementtrouver le clientsuspendudanssastructuredesynchronisation(6) et retournetoutdesuitepourtraiterl’appel (7). Aprèsavoir traitél’appel le “thread”va faireunappelsystèmepourretournerla réponse(etdébloquerle client)etattendred’autresappelsdechangementdedomaine.

Remarque! L’“upcall” versle serveurdecréationdedomaineavecl’adressed’unestructuredansle noyau,qui vaplustardêtreinterprétéecommel’adressed’unestructuredesynchronisationrisqued’êtredétournéesi quelqu’unarriveàmodifiercetteadresse.Lasécuritédeceschémadependdoncdel’invulnérabilitéduserveurdecréationdesdomainesetdubinaireduproto–serveur– c’est–à–diredel’invulnérabilitédel’utilisateur rootsurlesmachinesdansla grappe.

7.7 Couplaged’un segment

Le couplaged’un segmentAriassefait automatiquementlorsdela premièreréférenceàuneadresseà l’intérieur dusegment.La référenceprovoqueunefauted’adressage(“segmentationfault”) dansle systèmehôte,qui esttraitéeparle paginateurArias.Le paginateurAriasprendenchargela fauted’adressageetmetà jour lesstructuresnécessairesdansle noyaud’AIXpourquelesfautesdepagessuivantespuissentêtreprisesenchargeparle paginateurnormaldusystème.Avantdecouplerle segmentdansl’espaced’adressagedudomaine(le processusqui le réalise)le systèmedoit consulterle moniteurderéférencesd’Arias poursavoir si le couplageestautorisé,c’est–à–diresi le domainecontientunecapacitépourle segment.La vérificationdescapacitésparle paginateurestmontréesurla figure7.7.

print()

Domaine client

premier accès => faute d’adressage

Noyau du système

Moniteur de référencecapacité?

accès

couplage en mémoire

éxecution

lecture/écriture/ domaine

accès

Paginateur Arias

FIG. 7.7:Vérificationdescapacités


Quandle paginateurdemandel’autorisationdecouplerunsegmentaumoniteurderéférences,le moniteurderéférencesvachercherunecapacitépourle segmentdansla C–listeassociéeaudomainedeprotection.S’il trouveunecapacitéd’accès,l’autorisationestdonnéeet le segmentestcouplédansl’espaced’adressagedudomainequi a provoquél’exceptionselonle moded’accèsspécifiéparla capacité(lecture,écritureouexécution).S’il trouveunecapacitédechangementdedomaine,unappeldechangementdedomainevapermettrel’exécutionducodedansle domainedeprotectionspécifiéparla capacité.Le changementdedomaineestdécritenplusdedétaildansla sectionsuivante.

7.8 Changementdedomaine

Il estimportantdepréciserdansquellesconditionsunchangementdedomainepeutintervenir.Toutevérificationdesdroitsd’accèsestfaiteaumomentduchargementd’un segmentAriasdansundomainedeprotection.L’appeldechangementdedomaineprendla formed’un appeldeprocédure,c’est–à–direquela vérificationestfaitelorsdu traitementdedéfautdusegmentqui contientla procédure.

Remarque! Le changementdedomainelorsdel’accèsàunsegmentdedonnéesposelesproblèmessuivants.Si onprendle schémad’appeldeméthodedeC++,chaqueobjetcontientunpointeurversunetabledeméthodes(VTBL). Ondoit doncavoir accèsà l’objet appelépourcalculerl’adressedela méthodeappeléeet celaavantd’exécuterl’appel.Lorsd’un défautd’objet,ondoit êtreenmesurederetrouver lescaractéristiquescomplètesdel’appel,àsavoirl’indice ou l’adressedela méthodeappelée,lesparamètres,etc. . .pourrecréerle contextedel’appeldansle domainedestination.Ceciparaîtdifficile alorsquelesparamètresdel’appeln’ont peutêtrepasencoreétéempilés.Il fautdoncquele systèmeet l’environnementdulangagecoopèrentpourquele systèmepuisseretrouvercesinformationslorsd’unefaute.Ceciparaîtdifficile si onneveutpaspénalisertouslesappelsdeméthodesetsurtoutsi onveutpaslimiter l’utilisation dusystèmeàunenvironnementd’exécutionspécifique.

Remarquonségalementqu’il n’estpasévidentquele changementdedomainesurunefauted’accèsàunsegmentdedonnéessoitnécessairepourréaliserdesmécanismesdeprotectionsurlesobjets.Il estpeutêtresouhaitablederéaliserla protectionàungrainplusgrosauniveaudecomposantlogicielsou lesserveurscommedansCORBA [OMG98]. De toutefaçon,leslangagesàobjetcompiléssontsouventtransforméen“C” avantd’êtrecompiléencodeexécutable.Danscecontexte, il n’y apasbeaucoupdedifférenceentreunappeldeméthodestandardobjet.méthode(paramètre_1, ...) etunappeldefonction“C”méthode(&objet, paramètre_1, ...) outrela syntaxe.Alors le modèlesebasesurl’interceptiond’un appeldeprocedureet la transformationdecetappelenunappeldechangementdedomaine.Le mécanismedechangementdedomaineestétudiédansla suite.

7.8.1 Inter ceptionde l’appel

Le premierappelàuneprocéduredansunmoduledecodequi n’estpasencorecouplévaprovoquerunefauted’adressage.Cecinouspermetd’intervenirauniveaudu traitementdela

7.8. CHANGEMENTDE DOMAINE 127

faute.Onpeutalorsenvisagerdeuxschémasdifférentspourle déroulementdel’appeldechangementdedomaine: 1) soit effectuerl’appeldechangementdedomaineàpartir du traitementdelafaute,2) soit couplerun talonà la placeduvrai code.Le talontransformel’appel localenunappeldechangementdedomainedela mêmefaçonqu’un talondeRPCtransformeunappellocalenunappeldistant.

Traitement transparent par le système

La transformationtransparented’un appeldefonctionenappeldechangementdedomainedoit comprendrelesétapessuivantes: vérificationdela capacitédechangementdedomaine,identificationdudomaineserveuretpassagedescapacitésselonl’interfacedeprotection.Ledomaineserveuret l’interfacedeprotectionsontidentifiésparla capacitédedomaine.L’interfacedeprotectionestuniquementutiliséeparAriasetdoit doncêtrestockéeparlesystème,soit directementdansla capacité(celan’estpassouhaitableparcequelescapacitésdeviennentdetaille variable,)soitdansunestructureréférencéeparla capacité.La gestiondel’interfacedeprotectionparle systèmepermetausystèmedegarantirlaconformitéentrel’interfaceduclientet l’interfaceduserveuravantdepoursuivre l’appel.Celaestrelativementsimplepourlescapacitésd’accèsmaisbeaucouppluscompliquépourlescapacitésdedomaine.Si le client reçoitunecapacitédedomaineauretourduserveur, le systèmedoit garantirquel’interfacedeprotectionencodéedanscettecapacitécorrespondà la spécificationdel’interfacedeprotectionduclient.Alors la capacitédoit contenirunespécificationrécursivedesinterfacesdeprotectionqui estvérifiéeparle systèmeavantd’installerla capacitédansla C–listedudomaineclient.Celaapourconséquencequele formatdescapacitésdeviententrelacéavecle codedepassagedescapacités,cequi réduitla possibilitédechangerunou l’autreultérieurement.Deplus,la gestiond’un arbred’interfacesdeprotectionet la vérificationrécursivedelaconformitédecesinterfacesrajouteà la complexité dela réalisationetaugmentela probabilitéd’introduireunefautequi comprometla sécuritédusystème.Ceproblèmeestaggravé parl’environnementdeprogrammationmoinsrichedansle noyau(seulementunsous–ensembledesappelssystèmessontdisponiblesdepuislesextensionsdunoyau)etparla difficultédelamiseaupointdansl’environnementdunoyau.Pourcesraisonsnoussommesenclinsà rejetercettesolutionsi le couplaged’un talonnouspermetdebienréaliserle modèle.

Couplaged’un talon

La techniquederemplacerunefonctionparun talonestbienconnuedansle contextedesappelsRPC.Un talondeRPCnormals’occupedela transformationdesparamètresdansunformatcompréhensiblepourle serveuretdela communicationavecle serveur. Ariasestconçupourunegrappedesmachineshomogènes,doncnousn’avonspasbesoindetransformerlesparamètres.Par contrele talonpeuttransformerl’appelpourréaliserl’interfacedeprotection,c’est–à–direrajouterunedescriptiondescapacitésà transféreravecl’appelet vérifier lescapacitésreçues.Le talonclientvaêtrecouplédansl’espaced’adressageduclientàuneadressefixe.Un clientmalveillantnepeutpasmodifierle talonparcequ’il nepossèdepasunecapacitéd’écrituresur


le segment(si le clientpossèdeunecapacitéd’écrituresurle segmentà l’adresseducode,cesegmentvaêtrecoupléaulieu du talon),maisil peutdéchiffrer le formatdel’interactionentrele talonet le systèmeetappelerle systèmedela mêmefaçon.Le systèmen’a pasdemécanismepourdistinguerentreunappeldepuisun talonproprementcoupléetuncheval deTroie.Le talonclient ressemblebeaucoupà la définitiond’un proxyselonShapiro[Shapiro86], il estle représentantlocald’un objetdistant.Shapiroproposequele proxypuisseêtreconsidérécommeunecapacité,maiscelanécessitequele proxyet le serveursoientdécomposables,c’est–à–direquele proxysoit le seulmoyendecommunicationentreclientetserveuretqueleclientn’ait pasle moyendechangerle comportementduproxy. DansArias le talonclientet leserveursontdeuxentitésséparéesavecleurspropresidentités(adressesvirtuelles).Le clientpeutfairel’appelsystèmepourle changementdedomainedirectementsanspasserparle talon,doncle talon(le proxy)n’a paslespropriétésnécessairespourservircommecapacité.Celaapourconséquencequetouslesparamètresfournisparle clientdoiventêtrevérifiésavantd’êtrepassésauserveur. Noussommesdansunétatdeméfianceglobale,le systèmeseméfiedestalonsclientet serveur, le talonserveurseméfiedu talonclientet le talonclientseméfiedu talonserveur. Lestalonsdoiventfaireconfianceausystème,sinonil n’y apasderaisonsd’utiliser le système.La méfianceentrelesdeuxtalonsestunélémenttrèsimportantdansnotreréalisationduchangementdedomaine.

7.8.2 Changementdedomaine: Vued’ensemble

Le changementdedomaineadéjàététraitéen6.3.3et ci–dessus.Nousrappelonsla vued’ensembleduchangementdedomaineavantdedécrirele traitementdel’appelduclient, lecotéserveuret le retourauclient.

Talon

1

2

6

5

3

4

print()

clientTalon

Système Arias

Domaine serveur

ServeurClient

Domaine client

serveur

FIG. 7.8:Changementdedomaineparcouplaged’un talon

La figure7.8montrele schémad’ensembled’un changementdedomaine.Le premierappeld’unefonctiondansunmodulequi n’a pasencoreétécouplévaprovoquerunefauted’adressage.Le systèmecherched’abordàcouplerle segmentdansle domainecourant,mais


si le domainepossèdeunecapacitédedomaineaulieu d’unecapacitéd’accès,un talonvaêtrecoupléà la placeduvrai code(1). L’adressevirtuellepermanentedecetalonestspécifiéedansla capacitédechangementdedomaine.Le talonfait unappelsystèmepourchangerdedomaine.Le systèmevérifie lesparamètresdel’appelet transfèrelescapacités,puisunmoduledepolitiqueestappelépourvérifiersi leclientpossèdele droit detransférerlescapacités(2). Un “upcall” avecl’adressedela fonctiondansle talonduserveur(l’adressedu talonserveurestaussistockéedansla capacitédechangementdedomaine)esteffectuédansle domaineduserveur, cequi peutprovoquerunefauted’adressagedansle serveurdedomainequi vacouplerle talonserveur(si le serveurn’apasle droit decouplerle talonunerreurestretournéauclient).Le talonappellele codedansleserveuretattendle retourdel’appel (3). Au retourle talonfait unappelsystèmepourretournerchezle client (4). Commeà l’appel, le systèmevérifiequele serveurpeuttransférerlescapacitésauclient (5). Enfin,l’appeldechangementdedomainesetermineet le talonpasselerésultatauclient (6).Lestalonsduclientetduserveurpeuventréaliserlesinterfacesdeprotectionduclientetduserveurrespectivement.Nousallonsétudierlesélémentsdel’appeldechangementdedomaineplusendétaildansla suite.

7.8.3 Changementdedomaine: l’appel declient

Le schémadel’appelestmontrésurla figure7.9.Aprèsavoir étécouplé(1), le talonclientsertd’abordàcopierlesparamètresdela pile localedansunmorceaudela mémoiretamponquipeutêtretransmisentredomaines.Puisle talonvaappelerle systèmepourchangerdedomaine(2).

Vérifier que le client possède toutes les capacités

dans la C-liste, puis les transférer au domaine appelé

print()

Système Arias

Client

paramètres

Domaine client

Talon client

C-liste

2

1

FIG. 7.9:Changementdedomaine

Le talonpassel’adressedela fonctionàappeler, la mémoiretamponaveclesparamètresetunelistedecapacitésà transféreraudomaineserveur, enparamètreà l’appeldechangementde


domaine.L’ensembledela mémoiretampondesparamètreset la listedescapacitésàtransférerestappeléle blocd’appel.

L’appelsystèmenepeutpasdistinguerentreunappelfait depuisun taloncouplécommerésultatd’unerecherchedecapacitéouunappelfait depuisn’importequelautremorceaudecode.Le systèmedoit doncvérifier l’existenced’unecapacitédechangementdedomaineàchaqueappel.

Aprèsavoir vérifié la capacitédechangementdedomaine,le systèmevérifiequele domaineclientpossèdetouteslescapacitésdansla listespécifiéeet lesdroitsdelestransférer.

Un moduledevérificationdela politiquedeprotection(le ProtectionPolicy Module— PPM)estappeléensuitepourvérifiersi le transfertdescapacitésestpermisselonla politiquedeprotectionenvigueur. Cemoduleestréaliséparuneextensionséparéedunoyauqui peutêtreremplacéepourréaliserdifférentspolitiquesdeprotection7 (parexemplelespolitiquesmandataireoudiscrétionnaire).

Si unserveurdedomaineexistedéjà,le blocd’appelestchaînédansla structuredesynchronisationet l’appelsystèmesebloquesurunsémaphore.Sinonla créationdedomainedynamiqueestdémarréed’abord.

Unedesactivitéscrééesparle serveurdedomaineestdébloquépoureffectuerl’“upcall” dansle domaineserveur.

7.8.4 Changementdedomaine: Cotéserveur

Le traitementduchangementdedomaineducotéduserveuresteffectuéparuneautreactivité(unecrééeparle serveurdedomaine).Le schémadedéroulementdel’appelestmontrésurlafigure7.10.

7Le seulmodulequi existepour le momentréaliseunepolitiquediscrétionnairequi permettousles transfertsdescapacités.


vérifier C-liste

2

5

Installation des capacitésdans la C-liste temporaire

1

Domaine serveur

Talon serveur

Serveur

Système Arias

Vérifier C-liste et transférer capacitésRévoquer les capacités dans la C-liste temporaire

3

4


L’activité reveilléeparl’appelduclient vad’abordinstallerlescapacitéstransféréesdansunelistedescapacitéstemporairedudomaine.Cetteliste temporaireestassociéà l’activité etpermetausystèmederestreindrel’utilisation descapacitésàuneactivité particulière,qui traitele changementdedomaine.Cetterestrictionnes’étendpasà l’accèsauxdonnéesparcequ’unefois couplé,le segmentestaccessibleà touteslesactivitésdansle domaine,maiselleempêcheuneautreactivité depasserla capacitéàquelqu’unautre.Le systèmecalculeensuitel’adresseà laquellel’“upcall” esteffectué.Ceciestnécessaireparcequele clientneconnaîtpasapriori l’interfacedeprotectionduserveur. Cetteinterfaceestdéterminéeparla capacitédedomaineutilisée,c’estpourquoil’adressedela fonctionàappelerdansle talonserveurnepeutpasêtrespécifiéedirectement,maisdoit êtrecalculéecommele déplacementdela vraiefonctiondansle vrai segmentducode.Notregestionducodenouspermetdegarantirquele déplacementdela fonctiondansle taloncorrespondàceluiduvrai code.L’activité revientdansl’espaced’adressagedudomaineserveuretappellela fonctionàl’adressecalculéeenpassanttout le blocd’appelenparamètre(1).A cemomentle systèmegarantitquelesparamètressontceuxreçusparle clientetquetouteslescapacitésspécifiéesparla listedansle blocd’appelontététransféréesaudomaineduserveur. Alors le talonserveurpeutvérifierquelesintervallesdesvaleurs,le nombreet lestypesdesparamètrescorrespondentacellesattendues8. Ensuitele talonvérifiequela listedecapacitésestconformeàcelleattendue— c’est–à–direquele client fournit aumoinslescapacitésrequisesparle serveur. Le clientestlibre defournir plusdecapacitésquenécessaire

8La réalisationcourantevérifie uniquementle nombredesparamètres,mais nousenvisageonsen outre depouvoir vérifier l’intervalledevaleurdesparamètrepourprotégerunserveurcontreundébordementdela mémoiretampon.


(2).

Si lesparamètreset lescapacitéssontconformesàcellesattendues,le talonappellela fonctiondansle serveur(3), sinonunmessaged’erreurestretournéauclient.

Au retourdel’appelduserveur, le talonenregistrele codederetour, dépilelesparamètresderetouretcopiel’ensembledansunmorceaudela mémoiretampon.Ensuitele talonrajouteunelistedecapacités,qui ontététransféréesparle client lorsdel’appel,à installerdansledomaineduserveur. Le talonpouraitinstallercescapacitésavantd’appelerle serveur, maiscelan’estpasnécessaire(pendantl’appelcescapacitésontétédisponibledansla listetemporaire)etnouspréferonsfaireun“piggyback”surl’installationauretourpouréviterunappeldesystème.Enfin le talonrajouteunelistedescapacitésà transfereraveclesparamètresauclientetappellele systèmepourretournerchezle client (4).

L’appelsystèmederetourvérified’abordquele serveurpossèdele droit d’installerlescapacitéstransféréespuisil copielescapacitésdansla C–listespécifiéeparle talonserveur.Ensuitelescapacitéstransféréespoureffectuerl’appelsontrévoquées(la listedescapacitéstemporairesestmiseà zero).

Remarque! Lescapacitésnepeuventpasêtreinstalléesautomatiquementparcequecelapermettraitauclientd’installern’importequoidansle domaineduserveur. Parexempleleclientpourraitinstallerunecapacitédechangementdedomainepourunefonctionutiliséefréquemment,qui détournel’appelversundomainesousle contrôleduclient.Alorsl’installationactivedescapacités(aprèsavoir étéinspectéesparle talonserveur)estunélémentnécessairepourla suspicionmutuelle.La vulnérabilitéduserveurestminimiséependantl’appelparcequela vérificationdescapacitéstransféréesestfaiteavantl’appel.Si letalonserveurdétecteunproblèmeunmessaged’erreurestrétournéauclient.

Ensuitele systèmevérifiequele domaineduserveurpossèdelescapacitésspécifiéesdanslalistedescapacitéà transférerauclientetqu’il possèdelesdroitsdelescopier. Puisle PPMestappelépourvérifierquele transfertdescapacitésestenaccordavecla politiquedeprotection.Le blocd’appelestdéchaînédela structuredesynchronisation,le blocd’appeldu retourestchaînédansla structuredesynchronisationduclient, l’activité duclientestreveillé et l’activitéduserveursebloquesurunsémaphoredansla structuredesynchronisationduserveur(5).

7.8.5 Changementdedomaine: retour au client

La figure7.11montrele traitementauretourduserveur.


Vérificationde la C-liste

Installation des capacitésdans la C-liste par défaut

Client

3

Domaine client

Talon client

Système Arias

Installation des capacités

dans la C-liste temporaire

1

2


Unefois réveillé, le flot decontrôleduclient installelescapacitéstransféréesauretourduserveurdansla listedescapacitéstemporairesduclient.Puislesparamètresderetoursontcopiésdansun tamponà transfererautalonclientet l’appeldechangementdedomainerevientdansle talonclient (1). Le talonclient fait la mêmevérificationdesparamètreset lescapacitésquele serveurfaissaità l’appel (2). Si toutestenrèglele talonclientappellele systèmepourinstallerlescapacitéstransféréesparle serveurlocalement.Mêmes’il n’y a pasdecapacitésàinstaller, l’appelsystèmeestnécessairepourvider la listedescapacitéstemporaires(3). Enfinlesparamètressontempiléset l’appelseterminecommes’il étaitunappellocal.

7.8.6 Surchargedesinterfacesdeprotection

Quandundomainereçoitunecapacitédedomaine,cettecapacitécontientdéjàuneinterfacedeprotectionduclient (l’adressedu talonclient).Si le clienta confiancedansle serveurlacapacitépeutêtreutiliséedirectement,sinonil fautunmoyenpourle clientd’exprimersoninterfacedeprotection,c’est–à–diredesurchargerl’interfacedeprotectionencodéedanslacapacité.Nousenvisageronsdeuxméthodesdifférentespourfairecela: modificationdel’adressedu talondansla capacitéou introductiond’unecapacitéderedirectionàutiliseravecla capacitédedomaine

Modification de la capacité

La modificationdela capacitéelle–mêmeestla solutionla plussimple.L’appelqui installelacapacitédansuneC–listelocalevasimplementremplacerl’adressedu talonclientparuneadressefournieparle client.Si le client transmetla capacitéversunautredomainedeprotectionla capacitévaêtretransféréeavecl’interfacedeprotectionduclientetpasavecl’interfacepardefautduserveurinclut dansla capacitéoriginale.Le domainequi reçoitlacapacitédoit sedemanders’il aconfiancedansle clientqui le transmet,sinonil installesapropreinterfacedeprotection.Dansunelonguechaînededélégationsla questionn’estplusdesavoir si le clientaconfiancedansle domaineserveur, maisplutôtsi undomaineaconfiancedanstouslesdomainesqui le


précèdentdansla chaîne.Enplusle domaineneconnaîtpasla chaînededélégation; lesrelationsdeconfiancedeviennentdonctrèscompliquées,et il vautmieuxinstallersapropreinterfacedeprotection.Si la capacitédechangementdedomainevaêtrestockéedansuneC–listepartagée,touslesdomainesvontutiliser la mêmeinterfacedeprotection.Ceciimpliqueaussiquela dernièreinterfaceinstallévaêtrecelleutiliséeparle client.

Installation d’une capacitéderedirection

Au lieu demodifierla capacitéonpeutégalementenvisagerd’installerunnouveautypedecapacitéappeléecapacitéderedirection.La capacitéredirigele couplaged’un segmentversunautresegmentàcouplerà l’adressespécifiéeparla capacité.Quandle systèmechercheà couplerun talonclient, il vad’abordchercherunecapacitéderedirection.Si unetellecapacitéexiste,le talonspecifiéparcettecapacitévaêtrecoupléaulieu du talonspecifiéparla capacitédedomaine.Lescapacitésderedirectiondoiventtoujoursêtreinstalléesdansla C–listedebased’undomaine.Cecigarantitquel’interfacedeprotectionsouhaitéeparle domaineva toujoursêtreenvigueur.

7.8.7 Changementdynamiquededomaine

Le changementdynamiquededomaineutiliseunappelsystèmespécialisé.Outrelesparamètreset la descriptiondescapacitésà transférer, l’appeldechangementdedomainedynamiqueprendunparamètreenplus— l’adressed’un segmentqui contientlesparamètresauxiliaires(nousappelonscetteadressela référencedécisive).La descriptiondescapacitésàtransférerspécifiequelsdroitsd’accèssontassociésacetteréférence(si le domaineappelédoitavoir le droit delire oud’écrirelesdonnéesdansle segment9).Le systèmefait touteslesvérificationsnormalesdesparamètres,puisil construitunelistedecapacitésdechangementdedomaineassociéeà l’adressedela fonctionetdisponiblesdansledomaineappelant.Lescapacitésdanscetteliste identifientlesdomainesdeserveurpotentiels.Le systèmeparcourentcesdomainesunparun,pourtrouverundomainequi possèdelesdroitsnécessaireset transfèrel’appelversle premierdomainetrouvé.Si le systèmenetrouvepasundomaineàappeler, unmessaged’erreurestretournéauclient.

7.8.8 Discussion

La suspicionmutuelleentrelesdeuxdomainesestréaliséedeboutenbout.Le systèmen’offreaucunegarantie,maissertuniquementcommeunmédiateurcrédible.Celanouspermetderespecterle principedeminimalitédansnotreréalisationduchangementdedomaine.L’appeldechangementdynamiquededomaineétendla notionduchangementdedomaineversunmodèledeprogrammationàobjet.Un appeldeméthodeseréalisefacilementparl’appeldechangementdedomainecommementionnéaudébut de7.8.

9On peutégalementimaginerd’associerle droit d’appelerunefonctiondansun domainespécifiéà l’adressed’unefonction,maiscelarendla réalisationbeaucouppluscompliquéeetnousn’avonspasidentifiéuncasoucelaseraitnécessaire.Nousavonsdoncdécidédenepaspermettrecettefonctionnalité.

7.9. INTERFACESDE PROTECTION 135

La granularitéd’un appelestunsegmentd’Arias. La taille minimaled’un segmentAriasest4Ko, cequi correspondàunepagedela mémoirephysiquedela machine.Un systèmeàobjetréalisésurAriasdevrait doncréaliserunmodèleàobjetdegrosgrainougérerplusieursobjetsdansle mêmesegment(ceciestnormalementle casdansunserveurCORBA).Le couplaged’un talonà la placeduvrai codecréedesproblèmessi la mêmefonctiondoit êtreappeléeparfoisdansle domaineduclientetparfoisdansunautredomaine.Si le premierappelcouplele codelocalement,touslesappelssuivantsvontsedéroulerdansledomaineduclient.Ondécidedoncdecouplerle talontouslescasetd’incluredansle talonlecodedela procédurequel’on vientappeler. Il fauts’assurerquele domainenepossèdepasunecapacitéd’exécutionmaisuniquementunecapacitédechangementdedomainedynamique.

Remarque! Il n’existepasdesolutionsimple,auproblèmedesappelsparfoislocalparfoisdistant,avecle traitementtransparentparle système.Le systèmen’arrivepasàdistinguerentrelesappelslocauxet leschangementsdedomaine.Danscecastouslesappelsdesfonctionsdansunautremoduledecodedoiventêtrevérifiésparle système.

Dansle prototypecourant,le problèmepeutêtrerésoluenrajoutantle vrai codeà la fin dutalon10. L’appeldechangementdedomainedynamiquedoit d’abordvérifiersi la référencedécisivepeutêtreatteintedepuisle domaineduclientet retournerunmessagesi c’estle cas,puisle talonpeutappelerle vrai codeà la fin dumodule— cecodeeststockédansle mêmesegmentetneprovoquepasunefauted’adressage.Si lesparamètresnesontpasdisponiblesdansle domaineduclient, le changementdedomainesedéroulenormalement.Cettevérificationva rajouterautempsd’exécutionpourtouslesappelsdechangementdedomainedynamiques,maiselleestnécessairepourle supportd’un changementdedomainegénéral.

7.9 Interfacesdeprotection

La spécificationdesinterfacesdeprotectionestcompiléeendeuxtalonsdifférents,unpourleclientet l’autrepourle serveur, parungénérateurdestalonsmodifié(nousutilisonsuneversionmodifiéederpcgen(1) fourni parSunMicrosystems).Chaqueinterfacecompilée(le talon)eststockéedansunsegmentdifférentd’Arias. L’adressedebasedecesegmentpeutêtreutiliséecommeidentificationdel’interfacedanslescapacitésdechangementdedomaine.L’adressedu talonindiqueausystèmequelsegmentcouplerà laplacedusegmentqui contientduvrai codedansle clientetquelsegmentcouplerpoureffectuerl’“upcall” dansle serveur.Différentescapacitésdedomainepeuventspécifierdifférentstalonsqui réalisentdifférentstraitementsducotéserveur. Ceciressembleauxcapacitésactives,maisle codedansla capacitérestetoujoursducotéserveur.Pourl’instantnousn’avonspasdesidéestrèsprécisesurla fonctionnalitéqui peutêtreintroduitedanslestalonsduserveur, maisnotreréalisationnousdonnela souplessenécessairepourl’introduire ultérieurement.

10Cesmodificationsn’ont pasété faitesdansle prototypecourantparcequ’il fallait changerla gestionde lagénérationdestalons.


7.10 Récapitulation

Pourrécapitulerla réalisationdumécanismedeprotectionprésentédanscechapitre,nousdonnonssonplacementdansla taxonomieintroduiten4.3.3:

1. quesepasse-t-ilà la créationd’un objet? Le systèmeinsèreunecapacitéavectouslesdroitsdansla C–listepardéfautdudomainecréateur.

2. commentpeut-onmanipulerlescapacités?Lescapacitéssontgéréesdansdessegmentsséparésqui nepeuventpasêtrecouplésparunprocessus.Toutesmanipulationsdescapacitéssontfaitespardesappelssystèmes.L’API decesappelssystèmeestdécritdansl’annexeB.

3. commentpeut-onréaliserunchangementtemporairedesdroitsd’accèsd’un sujet?Arias fournit unmécanismedechangementdedomainequi permetd’appeleruneprocéduredansunautredomainedeprotection.

4. commentpeut-ondéléguerunecapacité? Il existedeuxmécanismesdedélégationd’unecapacité,ellepeutêtrecopieedansuneC–listepartagéeouellepeutêtrepasséeenparamètredansunappeldechangementdedomaine.Il fautdetoutefaçonl’interventiondusystèmepourdéléguerunecapacité.

5. commentpeut-onrévoquerunecapacité?Arias fournit unservicederévocationautomatiquedescapacitéspasséesenparamètrelorsduretourdel’appeldechangementdedomaine.L’API dela gestiondescapacitésdéfinitunappelderévocationd’unecapacitédansuneC–liste.Pourcela,il fautlesdroitsadéquatssurla C–liste.

6. commentsontvérifiéeslescapacités?Lescapacitéssontvérifiéesparle systèmelorsdutraitementd’un défautdesegment.

7. quesepasse-t-ilquandunsujetessaied’accéderàuneressourceprotégée?Lorsd’undéfautdepage,le paginateurd’Arias vérifie lesdroitsassociésausegment.

La classificationselonnotretaxinomiedumécanismedeprotectiond’Arias estdonccomparableàceluideMach,c’est–à–direla classificationsuivante: y

classification: bbcbbabz

Chapitre8

Évaluation

Cechapitreprésenteuneévaluationdumodèleproposéetsaréalisationdansla mémoirevirtuelle répartieuniqueArias,danssonétatenjuillet 1998.L’intégartionduprototypen’estpascomplet; l’état courantpermetde:

– vérifier lescapacitéslorsdupremieraccès(le défautdesegment),

– couplerlestalonsduclientetduserveuretd’effectuerunappeldechangementdedomaine,

– créerunserveurdedomainelorsdupremierappelaudomaine,

– transférerlescapacitéspasséesenparamètrelorsdel’appeldechangementdedomaine,et

– révoquerlescapacitéstransféréeslorsduretourdel’appel.

L’étatduprototypepermetdoncd’évaluertouslesélémentsdumodèlesdescapacitéscachées,maisle manqued’intégrationavecArias (parexemplele manqueduservicedepermanence)empêchele développementd’applicationscomplètes.L’évaluationqui suit rappelled’abordlesobjectifsdecettethèseen8.1.Ensuitenoustraitonschacundescesobjectifsdanssontour : la généricitédumodèleesttraitéeen8.2,la facilitédeprogrammationen8.3,l’évolutivité dumodèleen8.4,la réutilisabilitédescomposantslogicielsen8.5et la possibilitéd’intégrationdelogicielsconçusailleursen8.6.Nousallonsétudierquelquesaspectsdela sécuritédela réalisationen8.7avantprésenteruneévaluationdeperformanceduchangementdedomaineen8.8.

8.1 Objectif de l’évaluation

L’objectif del’évaluationestdedéterminersi lesobjectifsdumodèledeprotectionmentionnésen1.3sontatteintsparsaréalisationdansArias.Nousrappelonsd’abordcesobjectifs:

1. Généricitédumodèle. La généricitéaétéunbut principaldansla conceptiond’Arias.Pourdémontrerla généricitédumodèle,nousesquissonsla réalisationdesdifférentsmodèlesdeprotectionmentionnésenchapitre3 surle modèlesdescapacitéscachées.

2. Facilité deprogrammation.Le modèledoit êtrefacileàcomprendreetàutiliser, sinonilneserapasutiliséou lesspécificationsrisquentd’êtrefausses.Nousmontronscommentprofiterdesprogrèsrécentsengenielogicielle (notammentlesarchitectureslogicielles)etnousprésentonsdeuxscénariosd’applicationet leur réalisationpossiblesurArias.

137

138 CHAPITRE8. ÉVALUATION

3. Évolutivité.La spécificationdela protectiond’uneapplicationdoit pouvoir changerpendantla duréedevie del’application,sansrecompilationni rééditiondesliens.Nousmontronscommentfaireévoluerlesdroitsd’accèsd’uneapplicationpendantl’exécutionet commentfaireévoluerla politiquedeprotectiond’uneapplication.

4. Réutilisabilitédescomposantslogiciels.Lesmêmescomposantslogicielspeuventêtreutilisésdansdescontextesetdesapplicationsdifférents.Pourdémontrerla réutilisabilitédescomposantslogiciels,nousprésentonsuneexpériencederéutilisationd’un servicedenomsdansdescontextesdeprotectiondifférents.

5. Possibilitéd’intégrationdelogicielsconçusailleurs.Nousmontronscommentleslogicielsconçusailleurs(bibliothèquespartagéesouapplicationsUnix) peuventêtreencapsulésetprotégéesparle systèmeArias.

L’évaluationdecesdifférentsobjectifssonttraitésdanslessectionssuivantes.

8.2 Généricitédu modèle

Danscettesection,nousanalysonslespropriétésduschémadecapacitéproposépoursavoir sinouspouvonsarriverà réaliserlesdifférentsmodèlesdeprotectionproposésdansle chapitre3.Le but decettesectionestdemontrerquela plupartdesmodèlespeuventêtreréaliséssurlemodèledebaseproposédansle cadredecettethèse.La stratégieproposéepourarriverà cebut, estd’esquisserlesgrandeslignesdela réalisationd’unepolitiqueselonchaquemodèleproposédansle chapitre3, enutilisantnotreschémadecapacitéscachées.

8.2.1 Réalisationd’une politique decontrôle d’accèsmandataire

Nousavonschoisile modèledeBell etLaPadulapourmontrerla faisabilitédela réalisationd’un modèledecontrôled’accèsmandataire.Nousdécrivonsdansla suitelesprincipesd’uneréalisationdecemodèle.Nousrappelonsquele modèledeBell etLaPadulasebasesurdeuxprincipesfondamentaux:unsujetnepeutlire quedesobjetsavecunniveaud’autorisationégalou inférieuràsonniveau,et il nepeutmodifierquelesobjetsqui ontunniveaud’autorisationégalousupérieurausien.À chaqueaccèsàunobjet,le niveaud’autorisationdusujetestcomparéauniveaud’autorisationdel’objet et l’accèsn’estpermisquesi lesrèglesci–dessussontrespectées.Dansunsystèmeàbasedecapacités,le contrôled’accèssefait uniquementparla possessiond’unecapacité.Il n’y apasdevérificationdesniveauxrespectifsdusujetetdel’objet, maisl’autorisationsebaseuniquementsurla présentationd’unecapacitévalablepourl’objet. Celaimpliquequela comparaisondesniveauxd’autorisationdoit sefaireaumomentoùunecapacitéestrajoutéedansunelistedecapacités(dansle domainedeprotection)etnonquandle sujetessaied’accéderà l’objet.Nousmontronssurla figure8.1commentle modèlemandatairepeutêtreimplantésurnotremodèledeprotectionàbasedecapacités.La notationutiliséeici estinspiréedecelledeSnyder(cf. 4.3.1)etnousallonsutilisercettenotationpourdécrirelessystèmesdecapacitésparlasuite.Lesflèchessymbolisentdescapacités,cellesavecuncercleblancsymbolisentlescapacitésd’accèset celleavecuncerclenoir symboliseunecapacitédechangementdedomaine.Lescapacitésd’accèssontannotéesavecle droit d’accèsqu’ellespeuventaccorderetla capacitédechangementdedomaineaveclesdroitsd’accèsqu’ellepermetdetransférer,

8.2. GÉNÉRICITÉDU MODÈLE 139

c’est-à-direquel’interfacedeprotectionpermetuniquementle transfertdescapacitésenlecture.

B

r

Niveau d’autorisation de l’objetNiveau d’autorisation du sujet

A A

B

capacité d’accès capacité de changement de domaine

r,w

r,w

r

FIG. 8.1:Contrôled’accèsmandataire

La figuremontredeuxniveauxd’autorisationA etB où le niveauA estceluiqui a le plusdedroits.Lessujetssontreprésentésàgaucheet lesobjetsàdroite.Un sujethabilitéauniveauAdoit pouvoir lire etécrirelesobjetsauniveauA, maisseulementlire lesobjetsauniveauB. UnsujetauniveauA adoncdescapacitésenlecture/écritureversdesobjetsauniveauA, maisquedescapacitésenlectureversdesobjetsauniveauB.Un systèmedemémoirevirtuellepermetdecouplerunsegmentdemémoireenlectureouenlecture/écriture; il n’y anormalementpasdemoyendecouplerunsegmentdemémoireuniquementenmodeécriture.Cependant,ceciestnécessaireafinqu’unsujetauniveauBpuisseécrire(donner)desobjetsauniveauA sansqu’il n’ait le droit delire desobjetsauniveauA (modèlemandataire).Pourimplanterunmodèlemandataire,nousproposonsd’utiliser le changementdedomainepourréaliserdesécrituresversunniveausupérieursansdonnerdedroit enlecture.Surlafigure8.1,lessujetsauniveauB peuventavoir descapacitésdechangementdedomaineversdesdomainesduniveauA, enpassantdescapacitésenlectureversle niveauA pourdonnerlesinformationsàécrire.L’opérationdansle domaineappeléréalisel’écriture.La configurationd’un domainedeprotectionàuncertainniveaudoit prendrecelaencomptedela façonsuivante:

1. Un domainedeprotectiondoit uniquementposséderdescapacitésdelecturepourlessegmentsavecunniveaud’autorisationinférieuràceluidudomaine.

2. Un domainedeprotectionpeutposséderdescapacitésenlectureouenlecture/écriturepourlessegmentsavecunniveaud’autorisationégalà celuidudomaine.

3. Un domainedeprotectionnepeutmodifierdessegmentsavecunniveaud’autorisationsupérieuràceluidudomainequ’à traversdescapacitésdechangementdedomaine.Ceschangementsdedomaineneprennentenparamètrequedescapacitésenlectureà l’aller.


Cescapacitésdechangementdedomaine(et leursinterfacesprotégées)sontdéfiniesparl’administrateurdusystème.

Pourmontrerla possibilitéderéaliserunepolitiquedecontrôled’accès,noussupposonsquelesystèmepartd’uneconfigurationsûre(configuréeparl’administrateurdusystèmeresponsabledela protection).Nousallonsalorsmontrerquetouteslesmanipulationsqui changentl’état del’arbredescapacitésmènentàuneconfigurationsûre.Dansla politiquedécriteci–dessus,celaveutdirequelesopérationsdecréationdesegmentet changementdedomainerespectentlesrèglesdesûretédela politiquemandataire.

Création d’un segment

À la créationd’un segment,unecapacitéqui donnetouslesdroitsausegment(normalementlectureetécriture),estrajoutéeà la listedecapacitésdudomainecréantle segment.Ledomainecréantestà cemoment–ci,le seuldomaineàpossédercettecapacitéetenconséquencele seuldomaineàpouvoir modifierle segment.La règledesûretéestalorsrespectée.

Délégationdesdroits d’accès

Le changementdedomaineestle seulmécanismequi permetdedéléguerlesdroitsd’accèsentredomaines.Le moded’interactionentredomainesestcontrôléparlesinterfacesdeprotection.Dansla politiquedebase,le changementdedomainesefait uniquementpourpermettreauxdomainesdemodifierlesdonnéesd’un niveaud’autorisationplusélevéqueledomainemême(“write up”). Lesinterfacesinterposéesentreundomainemoinsprivilégiéetundomainesupérieureimposequele passagedeparamètresentrantsnecontiennequedescapacitésenlecture.Celagarantitquele domaineplusélevén’arrivepasàcommuniquerun résultatouàmodifierlesdonnéesdansunsegmentqui peutêtrelu parundomainemoinsprivilégié.La délégationdesdroitsd’accèsrespectealorslesrèglesdesûreté.

Discussion

Lessystèmesqui gèrentlescapacitésdansl’espaced’adressageduprocessus(parexempleAmoebaetOpal),nepeuventpasservirdebased’unepolitiquedecontrôled’accèsmandataire,parcequ’il n’y a pasdemécanismepourcontrôlerla délégationdesdroitsd’accès.Le mécanismedesPDX deMungi permetauprogrammeurd’applicationdecréerunerestrictiondudomainedeprotectionappeléavantl’appeleffectif decedomainedeprotection.Cecipermetderéaliserl’isolation del’appeldansle domaineappeléaulieu del’extensiondedomaine.Cependant,il n’y a pasdemécanismesystèmepermettantd’imposerunetellerestriction.Il n’estdoncpaspossiblederéaliserunmodèlemandatairesurle modèledeMungi.Enfinunepolitiquedeprotectionmandatairenepeutpasêtreréaliséesurle modèleàcapacitésclassique,mêmesi lescapacitéssontgéréesparle système.Eneffet, il fautpourcelaquelesrèglesd’échangedecapacitésentrelesdomainessoientcontrôléesparle système,cequi estlecasavecnosinterfacesprotégéesassociéesauxcapacités(qui sontgéréesparle système).Nousn’enapportonspasunepreuve formelleici maiscelaconstituetoutdemêmeunrésultatsignificatif.


8.2.2 Réalisationd’une politique decontrôle d’accèsdiscrétionnaire

Nousavonschoisidemontrercommentréaliserunmodèledecontrôled’accèsdiscrétionnaireà la Unix parcequ’Unix estunsystèmed’exploitationlargementutilisé.Le modèledeprotectiond’Unix aétéétudiédansla section3.5.L’authentificationd’Unix sebaseuniquementsurl’UID d’utilisateur. Pourfaciliterl’administration,lesutilisateurspeuventêtreregroupésengroupes.Lesmembresd’un groupepossèdentlesdroit définispourcegroupe.Nousrappelonsquele modèlederessourcesd’Unix estcentréautourdusystèmedefichiers.La plupartdesressourcespartagéesont unereprésentationsousformedefichier. L’accèsàunfichierestdéterminéparunvecteurdebitsdeprotectionstocképarmilesmeta-donnéesdufichier (l’inode). Cevecteurcontientlesdroitsd’accès(rwx pourlire, écrireetexécuter)pourle propriétairedufichier, le groupeprincipaldufichieret l’ensembledesutilisateursdusystème.Quandunutilisateuressaied’ouvrir unfichier1 le systèmevérifie le moded’accèssouhaitéavecl’information stockéedansle vecteurdecontrôled’accès.Le systèmevérified’abordsi l’utilisateurestle propriétairedufichier, sinonil vérifiesi l’utilisateurappartientaugroupeprincipaledufichieret finalementil vérifie le moded’accèsavecl’entréeduvecteurpourl’ensembledesutilisateursdusystème.Un versiondecemodèledeprotectionpeutêtreappliquéeauxsegmentsgérésdansle systèmeArias.CemodèlepeutêtreimplantésousformedeC-listespartagées.Il fautuneC-listeprivéepourchaqueutilisateur, qui correspondauxfichiersprivés.Enplusil fautuneC–listepourchaquegroupedusystèmeetuneC–listequi correspondà l’ensembledesutilisateursdusystème.Un processusUnix s’exécutantpourle compted’un utilisateurestinitialiséavecundomainedeprotectiondéfiniparuneC–listedecapacitéscomprenantlescapacitéssurlestroisC–Listessuivantes: la C–listeassociéeà l’utilisateur, la C–listeassociéeaugroupepardéfautdecetutilisateuret la C–listedel’ensembledesutilisateurs.Lorsqu’unsegmentestcréé,lemasquedecréation(umask) estutiliséafindedéterminerlescapacitésurle segmentqu’il fautinsérerdanslestroisC–listedécriteci–dessus.

Vérification desdroits d’accès

Il n’y apasd’open(2) dansArias,maisla vérificationdesdroitsd’accèssefait lorsdupremieraccèsausegment.L’open(2) d’Unix et le premieraccèsausegmentd’Arias mettentà jour lesstructuresdunoyauqui permettentlesaccèsultérieursparle sujetsansvérification.

Délégationdesdroits d’accès

Il existedeuxmécanismesdedélégationdesdroitsd’accèsdansUnix : lesopérationschown ,chmod etchgrp qui permettentdedéléguerundroit particulieret le mécanismedeSUID/SGIDqui permetdedéléguerl’ensemblededroitsd’un utilisateurpendantl’exécutiond’un programme.Le droit dedélégationestassociéaupropriétairedufichier. Pourpouvoirrestreindrele droit demanipulerunecapacitédansuneC–listepubliqueà unseulusager, ilfautunéquivalentdela notiondeproprétaire.Le formatd’unecapacitédoit doncêtreétendu

1L’open(2) d’Unix estun appelsystèmequi serten mêmetempsà mettreà jour lesstructuresinternesdusystèmeetà vérifier lesdroitsd’accès.


avecun identificateurdudomainepropriétairedela capacité2. Celaimpliqueuniquementunemodificationauniveaudela réalisationdumodèle.Lesopérationschown , chmod etchgrp peuventêtreréaliséespardesapplicationsAriasquiont le mêmesyntaxequeleurcorrespondantesUnix.

chown insèreunecapacité(ouuneC–liste)dansla C–listedebasedunouveaupropriétaireet la supprimedansla C–listedel’ancienpropriétaire.L’identificateurdepropriétaireestégalementmodifié.

chgrp modifielesC–listedesgroupesdela mêmefaçonquechown modifielesC–listesdesusagers.

chmod changelesdroitsd’accèsdansla C–listedudomainedepropriétaire,la C–listedugroupeet la C–listeglobale,selonle vecteurdebitsdonnéenparamètre.

Le mécanismedeSUID/SGIDsurunfichierexécutablepermetdedéléguerl’ensembledesdroitsd’accèsd’un utilisateurUnix. Enprenantl’identité dupropriétaire(resp.groupe)dufichier, unprocessuspeutétendresesdroitsd’accès,caril obtientenappelantcetexécutablelesdroitsd’accèsdupropriétairedufichier.Pourréaliserl’extensiondesdroitsd’accèsduprocessuscourant,il suffit d’insérerdansledomainedeprotectionassociéauprocessusunecapacitédechangementdedomaine.Cettecapacitédechangementdedomainecorrespondàunpointd’entréedudomaine(uneprocédure)dontunecapacité(aveclesdroitsd’exécution)setrouvedansle domaineappelé.

Discussion

Onvoit qu’ici, la fonctiondebasepermettantderéaliserle modèledeprotectiondiscrétionnaired’Unix estla gestiondelistesdecapacitéspartagéesentrelesutilisateur, auquelonajoutele mécanismedechangementdedomainepermettantderéaliseruneextensiondynamiquedesdroitsd’accèsd’un processus.

8.2.3 Réalisationd’une politique decontrôle d’accèsbasésur lesrôles

Dansle modèlebasésurdesrôles,unusagerestautoriséà jouerdifférentsrôlesetnoussupposonsqu’uneprimitivedusystèmepermetà l’usagerdechangerderôle.Cerôledéterminelestransactionsquel’usagerpeutréaliser.Le modèledeprotectionàbasedesrôlesseréalisenaturellementdansle modèledeprotectiond’Arias. Chaquedomainedeprotectioncorrespondàunrôleouunetransactionet le faitd’assumerunrôlecorrespondàunchangementdedomaine.L’ensembledesdomainesdeprotectiondisponiblesàunutilisateurpeutêtrereprésentésousformed’un graphe(cf. la figure8.2)où lesnœudsreprésententlesdomainesdeprotectionetlesarcsreprésententlescapacitésdechangementdedomaine.

2Il estpossibled’étendrele formatde la capacitéparcequ’il restesuffisammentd’octetsdansla structuredestockaged’unecapacitédansl’AVL.


Domaine de protection initial

Rôle

Transaction

FIG. 8.2:L’arborescencederôles

La figuremontrel’ensemblededomainesqui estaccessibledepuisle domaineinitial d’unusager(le rôle initial estnormalementtrèsgénéral,puislesrôlesdeviennentdeplusenplusspécialisés).L’usagerestautoriséàassumertrois rôlesetàexécutercinq transactions.Unetransactiondoit êtrereprésentéeparundomainedeprotectionqui encapsulelesdonnéeset lesopérationssurlesdonnées.La C–listed’unetransactioncontientdoncdescapacitésd’accès,desactivitésd’exécutionetdescapacitésdechangementdedomainesi la transactionadessous–transactions.Un rôledoit êtrereprésentéeparundomainedeprotectionqui permetd’assumerd’autresrôlesetd’exécuterdestransactions.La C–listed’un rôlecontientdoncuniquementdescapacitésdechangementdedomaine.

Discussion

Onvoit ici qu’undomainedeprotectionsertenmêmetempsàencapsulerlestransactionsetàdéfinir lesdroitsd’accèsautorisésàunrôle.Lesappelsdechangementdedomainepermettentd’assumerunrôleplusspécialiséoud’exécuterunetransaction.

8.2.4 Réalisationde la politique de la muraille deChine

Dansle modèledela murailledeChine,unusager(unconsultantdansnotreexempledelasection3.7)n’a audépartaucunerestrictionsurlesdonnéesqu’il peutconsulter. Lorsqu’ilprendconnaissancedecertainesinformations,il fautêtreenmesurederestreindresesdroitsafinqu’il nepuissepasavoir accèsàdesdonnéesqui, étantdonnéeslesinformationsprécédemmentutilisées,génèrentunconflit d’intérêt.Enutilisantnotremodèleàcapacités,il suffit degérerundomainedeprotectionparconsultantetundomainedeprotectionassociéà la personnequi distribuelesinformationsauxconsultants(le patron).Lesconsultantsn’ont audépartaucundroit surlesinformations.Lorsqu’uneinformationdoit êtredélivréeàunconsultant,elleesttransmiseparunchangementdedomaineentrele domainedupatronet le domaineduconsultant,enprenantenparamètreunecapacité


surl’information transférée.Le patrondoit gérerdanssondomainedeprotectionl’historiquedesaccèspermettantdedécidersi uneinformationdoit êtretransmiseàsesemployés.

Discussion

Onvoit ici quel’élémentclépermettantderéaliserla politiquedela murailledeChineestlaséparationentredomainesdeprotectionet le passagedecapacitésenparamètrelorsdeschangementsdedomaine.

8.2.5 Récapitulation et discussion

Danscechapitre,nousavonsmontréquele modèleàcapacitésproposépermettaitderéaliserlesdifférentespolitiquesdeprotectionprésentéesdansle chapitre3.Enparticulier, onavu quellescaractéristiquesdecemodèleàcapacitéspermettentderéalisercesdifférentespolitiques:

Politique mandataire.Lesdomainesdeprotectionpermettentdegérerlesdifférentsniveauxd’autorisation.Leschangementsdedomainepermettentderéaliserdesécrituresverslesniveauxsupérieurssansquedesdroitsenlecturesoientdonnésauxniveauxinférieurs.Le fait quelesinterfacesprotégéesdescapacitésdechangementdedomainesoientgéréesdansle système(protégéesetdéfiniesparl’administrateur)permetd’assurerqueleschangementsdedomaineversle hautnepassentquedescapacitésenlecture.

Politique discrétionnaired’Unix. Leslistesdecapacités(partagées)denotremodèledeprotectionpermettentdegéreraisémentlesdroitsdesusagers,desgroupesetdel’ensembledesusagersdansle système.Le changementdedomainedeprotectionpermetderéaliserl’extensiondynamiquedesdroitsd’accès(commele fait le SUID d’Unix).

Politique par rôle. Un domainedeprotectionestassociéàchaquerôle.Le changementdedomainedeprotectionpermetàunusagerdechangerderôledemanièrecontrôlée.

Politique de la muraille deChine. Un domainedeprotectionestassociéàchaqueusager. Le passagedecapacitéenparamètrepermetd’accorderlesdroitsdynamiquementauxusagers.Le superviseurdesdroits(le patron)estchargerdeconserver l’historiquedesaccèsetd’accorderlesaccèsà la demandeengarantissantqu’il n’y apasdeconflit d’intérêt.

Enconclusion,onobservequele modèleàcapacitésesttrèsgénériqueetpermetderéaliserlaplupartdespolitiquesdeprotection.Enparticulier, le modèledeprotectionquenousproposonssecaractériseparle fait quelescapacitéssontconfinéesetquela politiquedegestiondescapacités(principalementcommentlescapacitéssontéchangéesentrelesdomainesdeprotection)estexpriméedansla capacitédechangementdedomaineelle-même.Ceciimpliquequeleséchangesdecapacitésenparamètrelorsd’un changementdedomainesontimposésparla capacitédechangementdedomaineutilisée.Ainsi, il estpossibleàl’installationd’unecapacitédechangementdedomained’imposerdesrèglessurle passagedecapacitésenparamètre(parexempleseulesdescapacitésenlecturepeuventêtrepassées).Cettecaractéristiquenouspermetd’implanterélégammentunepolitiquemandataire.

8.3. FACILITÉ DE PROGRAMMATION 145

8.3 Facilité deprogrammation

Denombreuxchercheurssesontintéresséset s’intéressentà la réutilisationdu logiciel. Lamodularitédeslogicielsa étéungrandpasdanscesens.Deplusenplus,lesapplicationssontdéveloppéessousla formed’un ensembledecomposantspouvantêtreréutilisésdansle cadredeplusieursapplications.Uneapplicationconsisteenunensembledecomposantsinterconnectéspardesconnecteurs.Un connecteurdéfinitunmoded’interactionentredescomposants,parexempleunappeldeprocédure,deméthodeouencorel’envoi d’un message.Dansla plupartdescas,uncomposantestconsidérécommeuneboîtenoireavecdesinterfacesclairementdéfinies.L’implémentationducomposantn’estpasvisibledel’extérieuret laconstructiond’uneapplicationparassemblagedecomposantsnedoit pasnécessiterunequelconqueconnaissancedel’implémentationdescomposantsréutilisés.La politiquedeprotectiond’uneapplicationestgénéralementdéfinieglobalementpourcetteapplication.Ceciimpliquequesi uncomposantestréutilisédansle cadrededeuxapplicationsayantdespolitiquesdeprotectiondifférentes,il devientnécessaired’êtreenmesured’associerdespolitiquesdeprotectiondifférentesà unmêmecomposantréutilisédansdifférentsenvironnements.Le modèledeprotectiond’Arias va toutà fait danscesens,caril permetd’associerdifférentespolitiquesdeprotectionàdesmodules,simplementenspécifiantlesinterfacesdeprotectionassociéesauxcapacitésinstalléesdanslesenvironnementsd’exécution[Jensen98b].

8.3.1 Ar chitectureslogicielles

Unearchitecturelogiciellesebasesurtroisnotionsdebase: lescomposants, lesconnecteurset la configurationdel’application.

Composants

Un composantsimpleconstituel’entité basiquedela compositiond’uneapplication.Quelquessystèmespermetd’assemblerplusieurscomposantsdansunmêmecomposantcomposite.Arias réalisedescomposantssimplepardesmodulesdecodeetdescomposantscompositesparunensembledemodulesdecodes’exécutentdansle mêmedomainedeprotection.

Connecteurs

Un connecteurpermetderelierdeuxcomposants.Il identifielespointsd’entréesutilisésdechaquecomposantavecleur interface.Quelquescomposantspermetdetransformerlesdonnéespasséesenparamètreentrecomposants,si l’interfaceduclientnecorrespondpasexactementàcelleduserveur.Arias réalisedesconnecteursparlesinterfacesdeprotection.La capacitédechangementdedomaineidentifiélesdeuxtalonsutiliséspourrelier lesdeuxcomposants(domainesdeprotection).Outrele transfertdescapacités,lestalonsduclientetduserveurpermetquelquestransformationsdesdonnéessimplespourlesadapterà l’interfacedel’autre,parexempletransformerun int enun long .


Configuration

La configurationidentifielescomposantsconstituantl’applicationet lesconnecteursutiliséspourrelier lescomposants.La configurationdoit égalementspécifierunepolitiquedesécuritépourl’application.

La configurationd’uneapplicationAriasestdéfinitparla C–listedudomainedeprotectioninitial del’application.La configurationd’uneapplicationcorrespondàdéfinirunepolitiquedesécuritépourl’application.

Remarque! : Pourpouvoir utiliser lesinterfacesdeprotectioncommeconnecteurentredeuxcomposants,il fautséparerlescomposantsdansdeuxdomainesdeprotectiondifférents.Si lescomposantsontbesoindesmêmesdroitsd’accèsceciimpliquela créationdedeuxdomainesdeprotectionquasiidentiques,maisengénéralela séparationendeuxdomainespermetd’appliquerla principedela moindreprivilège.

8.3.2 Programmation par étapes

La programmationdesapplicationsrépartiesrestetoujourstrèscomplexe,maislaprogrammationparétapes(“séparationof concerns”)permetdeséparerl’algorithmiquedel’applicationdela spécificationdela protection[Jensen97b]. La conceptiondel’algorithmiquepeutdoncêtreconfiéeàunexpertdudomaineet la spécificationdela protectionàunexpertdesécurité(pourunmeilleurrésultatlesdeuxexpertsdoiventtravailler ensemble).

Pourmieuxmontrercommentutilisernotremodèledeprotection,nousprésentonsquelquesscénariosd’applicationdansla suite.

8.3.3 RéalisationdeNIS sur Arias

Ici nousallonsesquissercommentréaliserdeuxservicesdisponiblesavecNIS (“NetworkInformationService”)développéparSunMicrosystems3.

Servicedegestiondesmotsdepasse

Le servicedegestiondesmotsdepassesecomposed’unebasededonnéesetunensembled’opérationsqui permetdechercheretdemanipulerlesinformationsstockéesdansla basededonnées.Le formatdesinformationsstockéesenNIS estdifferentdeceuxstockéesdanslefichier /etc/passwd , maislesoperationsdeNIS lesprésententsousformed’unelignedansle fichier /etc/passwd . Nouspouvonsdoncégalementmodifierle formatdesinformationssousconditiondelesprésenterdansle formatdufichier /etc/passwd .

3L’annexeC présenteuneintroductiontrèscourteàNIS.

8.3. FACILITÉ DE PROGRAMMATION 147

r

Segment usager

passwd()

rwrw

r

Domaine NIS Domaine usager

Segment passwd

FIG. 8.4:L’architectureduserviceNIS surArias

<login>:<passwd >: <uid >: <gi d>:< gecos>: <home>:< she ll >

a)Formatd’uneentréepasswdenNIS standard

<login>:<passwd >: <uid >: <gi d>:< adre sse du segment usager>

b) Formatd’uneentréepasswdenNIS surArias

FIG. 8.3:FormatdesentréespasswddeNIS

Le formatd’uneentréedansla baseNIS estillustrésurla figure8.3a).L’entréesecomposededeuxparties,unepartiequi identifieetauthentifiel’usager(lesentréeslogin , motdepasse(passwd ), uid etgid ), etunepartiequi decritssonenvironnementd’exécutionpreféré(lesentréesgecos , homeetshell ). L’intégritédela premièrepartieestengénéralegarantitparle système,maisdansla plupartdessystèmeslesusagerssontlibresàmodifierla deuxièmepartieselonleurpréférences.La gestiondesinformationsstructuréesdansun formatàplatposesouventdesproblèmes,ilfautparexempleassurerqu’unusagern’arrive jamaisàsubstituersonshell avecunechainedecaractèresdeformatsuivant“ /bin/sh\npirate::0:0::/:/bin/s h” parcequececicréeuncomptepirate aveclesprivilègesderoot . Pourévitercetypedeproblème,nousproposonsdegérerlesinformationsmodifiablesparl’usagerdansunsegmentséparéapelléle segmentusager. Le formatdela nouvelleentréeNIS estillustrésurla figure8.3b).Chaqueusagerdoit avoir le droit delire lesentréesdansla basedeNIS etdemodifiersonpropresegmentusager. Deplus,le serveurNIS doit exporterunpointd’entréequi permetauxusagersdechangerleurmotdepasse.Le serveurNIS doit avoir le droit delire touslessegmentsusager. Unevuetrèsgénéraledel’architecturedeNIS surAriasestillustréesurlafigure8.4.

8.3.4 Réalisationd’un éditeur coopératif sur Arias

Nousprésentonsle noyaudebased’un éditeurcooperatifpourmontrercommentle modèlesdescapacitéscachéespeutêtreutiliséà réaliseruneapplicationcoopérative.


Le modèledel’applicationestle suivant: le documentestrépartiparmiuncertainnombred’auteursqui sontresponsabledeleurproprepartie,il y aunéditeurqui estchargéd’intégrerlesdifférentespartiesetdemettreunetouchefinaleavantdepublierle document.

La responsabilitéd’un chapitreimpliquequel’auteurdoit êtrele seulutilisateurautoriséà lemodifier, c’est–à–direquechaquechapitredoit êtrestockédansunsegmentséparéetqueledomainedel’auteurdoit êtrele seuldomaineàposséderunecapacitéd’écriturepourcesegment.Le droit delire le segmentdoit êtrediffuséà touslesauteurs.

L’editeurcoopératifsecomposedeplusieursmodulesdecodequi s’occupentdel’affichagesurl’écranet la manipulationdu texte.Nousnousinteressonsuniquementàcederniermodule.

Chaquedomaineexporteégalementquelquespointsd’entrée(procédures)qui permettentauxutilisateursautoriséesdefaireuneopérationbiendéfiniesurle texteduchapitre.Lesopérationsexportéesparundomainecomprennentlesfonctionssuivantes:

c_o(addr_t chapitre) qui réaliseunecorrectiond’orthographeentreuneadressedonnéeet jusqu’aufin duchapitre,et

mettre_ancre(addr_t paragraphe) qui permetdemettreuneancredansletexte (àuneadressedonnée)pourfaireuneréférencecroisée.

La figure8.5montrel’éditeurcooperatifavecdeuxauteursetunéditeur. L’éditeura le droit delire tousleschapitresetdeappelerle correcteurd’orthographedansle domainedechaqueauteur. Lesauteursont touslesdroitsdelire etmodifierleurproprechapitre,delire lesautreschapitresetd’appelerunefonctionqui metuneancredansle chapitredequelqu’und’autre.

Domaine de l’Auteur 2Domaine de l’Auteur 1

Chapitre 1 Chapitre 2

lire

mettre_ancre()lire

mettre_ancre()

c_o(

)lire

c_o()lire

Domaine de l’Éditeur

FIG. 8.5:L’éditeurcooperatif

Il fautdéfinirdeuxinterfacesdeprotectionpourcetteapplication,uneutiliséeentrel’éditeuretunauteur(cf. figure8.6a)etuneautreutiliséeentreauteurs(cf. figure8.6b).

8.4. ÉVOLUTIVITÉ 149

c_o(CAPA_WRITE addr_t chapitre)

a)L’interfacedeprotectionentrel’éditeuretunauteur

mettre_ancre(CAPA_WRITE addr_t paragraphe)

b) L’interfacedeprotectionentredeuxauteurs

FIG. 8.6: Interfacesdeprotectiondel’éditeurcoopératif

Cesinterfacesvont faireunappeldechangementdynamiquededomainedansundomainequipossèdele droit d’écrituresurl’adressepasséeenparamètre.Remarquonsquelesauteursn’ont pasbesoind’appelerla fonctionducorrecteurd’orthographedansunchapitredontils nesontpasresponsablesetquel’éditeurn’a pasbesoindemettreuneancrepourlesréférencescroiséesdansunchapitre.

8.3.5 Discussion

Le modèledescapacitéscachéess’adaptebienà la programmationparcomposantset lesarchitectureslogicielles— deuxtechnologiesproposéespourfaciliter la programmationdesapplicationscomplexes.La programmatioparétapespermetégalementdereduirelacomplexité deprogrammationdesapplicationssûres.Pourdémontrercommentutiliser le modèleenpratique,nousavonsesquisséla réalisationdedeuxscénariosd’applicationdifférentes.Le scénarioNIS montrecommentréaliseuneextensionsystèmeavecle modèledescapacitéscachées.Il n’existequ’unserveurpourchaqueservice,nousn’avonsdoncpasbesoinduchangementdynamiquededomaine.Le scénarioéditeurcoopératifmontrecommentréaliseruneapplicationcoopérativedansArias.Pourpouvoir appelerle correcteurd’orthographeetmettreuneancrederéférencecroiséedansn’importequelchapitre,nousavonsbesoindel’appeldechangementdynamiquededomaine.

8.4 Évolutivité

Il y adeuxaspectimportantspourl’évolutiondesdroitsd’accès: l’évolutiondesdroitspendantl’exécutiondel’applicationet la possibilitédefaireévoluerl’applicationelle–même.Cesdeuxaspectsonttraitésdansla suite.

8.4.1 Evolution desdroits d’accès

La protectionparcapacitéestlargementreconnuecommele mécanismedeprotectionle plusflexible. Lescapacitéssontfacilementpasséesentredomainesdanslesappelsdechangementdedomaine.En fait lesseuleslimitesà la diffusiondesdroitsd’accèssontcellesimposéesparla politiquedesécuritéet réaliséesparle moniteurderéférence.


8.4.2 Évolution de la sécuritéd’une application

Lesarchitectureslogicielleontétéproposéespourfaciliter l’évolutiondesapplications.Nousavonsmontréquele modèledeprotectiond’Arias correspondbienauxarchitectureslogicielles.Lesdomainesdeprotectionencapsulentlesdonnéeset lesopérations(commelescomposants),lesinterfacesdeprotectionserventenfait deconnecteursentredeuxcomposantset l’arbredesC–listesdéfinit la configurationdel’application.

Remarque! Lesinterfacesdeprotectionsontspécifiéesparle programmeurdechaquecomposant,il fautdoncs’assurerquel’interfaceduclientet l’interfaceduserveurcorrespondent.L’accorddesinterfacescorrespondauproblèmedeconformitédedeuxtypesdansleslangagesàobjets[Jensen98c].

8.5 Réutilisabilité descomposantslogiciels

L’évolutionversla programmationparcompositiondescomposantsexistantsnécessiteunsupportpourla réutilisabilitédescomposantslogiciels.Deplus,lescomposantsrisquentd’êtreutilisésdansdescontextesdesécuritédifférents(parfoisà l’interieur d’un composantetparfoiseninteractiondirecteavecunutilisateurpotentiellementmalveillant), il fautdoncavoir lacapacitédechangerla façond’interagiravecle composant.Pourillustrercetavantagedenotremodèle,nousutilisonsl’exempled’un module(composant)implantantunservicedenomssymboliques4. Cemodulepermetdegérerl’associationentredesnomssymboliquesetdesadressesvirtuelles(un identificateuruniquedansArias).Ceservicedenommageexportetroispointsd’entrée: create , add et lookup quipermettentrespectivementdecréerunnouveauservicedenommage(initialisation),ajouteruneunenouvelleentréeassociantunnomsymboliqueà uneadressevirtuelleet rechercherl’adresseassociéeà unnomdansunservicedenommage.LessignaturesdecesinterfacesenlangageC sontdonnéesci–dessous.

void create(addr_t *ns,int elem_size, int no_elem);

void add(addr_t ns, char *name, addr_t addr);

void lookup(addr_t ns, char *name, addr_t *addr);

FIG. 8.7:L’interfaceducode

Il estalorspossibled’utiliser le mêmemoduledecodedanstroiscontextesdeprotectiondifférents.Si le modulefait partieintégrantedel’applicationetestcomplètementprivéàcetteapplication,alorsla configurationdela politiquedeprotectionvaplacerdansle domainedeprotection

4Un articlequi décritcetteexpériencea étéprésentéeau“SecondEuromicroConferenceon SoftwareMainte-nanceandReengineering”[Jensen98a].

8.5. RÉUTILISABILITÉ DESCOMPOSANTSLOGICIELS 151

d’exécutiondel’applicationunecapacitéd’exécutiondumoduledecodedanscedomaine.L’exécutiondecemoduleestlocaleaudomainedeprotectiondel’application.L’applicationpeutappelersansaucunerestrictionlestroisopérationcreate , add et lookup .Dansunautrecontexte,cemodulepeutêtreutiliséafindegérerunserveurdenommageprotégépartagéentreunensembled’applications.Le serveurdeprotections’exécutedansundomainedeprotectionqui inclut unecapacitéd’exécutiondumoduledecode(commeci–dessus).Par contre,lesclientsdeceserveurdenommageseverrontseulementdonnerunecapacitédechangementdedomainepourlespointsd’entréeauxquelsils ontdroit. Danscecas,ils recevrontdeuxcapacitésdechangementdedomainepourallers’exécuterdansledomainedeprotectionduserveuretappelerlesopérationsadd et lookup . Parcontre,iln’ont pasle droit d’appelerl’opérationdecréationet initialisationduserveurdenomqui estpartagéetprotégé.Lesinterfacesdeprotectiondecesdeuxcapacitésdechangementdedomainesontdonnéesci–dessous.

void add(IN addr_t ns,IN char *name, IN addr_t addr);

void lookup(IN addr_t ns,IN char *name, OUT addr_t addr);

FIG. 8.8:L’interfaced’un servicedenoms

Enfin,dansun troisièmecontexted’utilisationdecemodule,nousconfiguronsla politiquedeprotectiondumoduledecoderéutilisépourqu’il secomportecommeunserveurdeprotection.L’objectif est,lorsquele serveurestconsultépourobtenirl’adressevirtuelleassociéeàunnomsymbolique,deretourneraudomainedeprotectionclient (appelant)unecapacitéenlecturesurle segmentAriasdésignéparcetteadressevirtuelle (parexemplepourconsulterle documentstockédanscesegmentdansle cadredel’application).Danscecas,nousavonsla mêmegestiondesdomainesdeprotectionquedansle casprécédent,misàpartquelesinterfacesdeprotectionassociéesauxcapacitésdechangementdedomainesontlessuivantes.

void add(IN addr_t ns,IN char *name, IN CAPA_READaddr_t addr);

void lookup(IN addr_t ns, IN char *name,OUT CAPA_READaddr_t addr);

FIG. 8.9:L’interfaced’un serveurdeprotection

Onvoit que,danscecas,lescapacitésdechangementdedomainedesopérationsd’ajoutetdeconsultationduserveurdeprotectionrespectivementdonnentet récupèrentunecapacitéenlecturepourle segmentidentifiéparl’adressevirtuelle (uniquedansArias)passéeenparamètredel’opération.


La séparationentrela définitiondela politiquedeprotectionet l’algorithmiquepermetderé-utiliserunmêmemoduledecodedansdescontextesd’utilisation trèsdifférentssansavoir àmodifiercemodule.Deplus,cetteséparationrendla définitiond’unepolitiquedeprotectionplussimpleetplusfacileàcomprendre.

8.6 Possibilitéd’intégration de logicielsconçusailleurs

Nousn’avonspasfait uneévaluationparticulièredecetaspect,maisnotregestiondecodenouspermetdedéfinirunmoduledecodeà partird’unebibliothèquepartagéed’Unix ; l’integrationdansAriasdeslogicielssousformed’unebibliothèquepartagéeestdoncfacileà faire.Deplus,il existeaujourd’huidestechniquesqui permettentd’encapsulerducodepropriétaireetdel’utiliser depuisunebibliothèquepartagée.Il suffit dedéfinirunmoduleAriasàpartir decettebibliothèquepourquel’applicationpuisseêtreutiliséeàpartir d’Arias. Le codepropriétaires’exécutetoujoursdansle contexted’un processusUnix normal,maisle moduledecodeAriasqui permetd’y accéderpeutêtresoumisà la politiquedeprotectiondusystème.

8.7 Sécuritéde la réalisation

Nousavonsidentifiédeuxproblèmesdesécuritédansla conceptiondenotremodèledeprotectiondansArias.Cesproblèmessontlessuivants:

8.7.1 Inter opérabilité avecle systèmehôte

L’interopérabilitéavecAIX rendle problèmed’analyserla sécuritédumodèletrèscomplexe(nousavonspasdenoyaudesécuritéglobale),c’est–à–direquenotremoniteurdesréférencesestfacileà identifier(enplusil estsimpleetpetit),maisil nemarchequepourlesréférencesversArias,alorsil estpossibled’éludercemécanismesi onarriveàcontournerlesmécanismesdela protectiond’AIX (parex. si onobtientunaccèsà la mémoiredela machineà travers/dev/kmem ouunaccèsdirectà l’imagepermanentesurdisque)).Enplusnousnemaîtrisonspasle canauxdecommunicationd’AIX, desattaquessontdoncpossibleparcettevoie.

8.7.2 Communication sur le réseau

Cetravail aétéréaliséavantla libéralisationduchiffrementenFrance.Nousn’avonsdoncpaseulesmoyensdeprotégerlesmessagesenvoyéssurle réseauouderéaliseruneauthentificationentremachines.Lesconsignesdesécuritépouruneinstallationd’Arias doitdoncexiger le contrôlephysiquedesmachinesdansla grappe.Le problèmedesécuritédecommunicationsurle réseaupeutêtrerésolu,soit paruncontrôled’accèsphysiquestrict,soit parlestechniquesd’authentificationetdecommunicationsûreétudiéesdansle chapitre2 qui peuventêtreintégréesdansAriasafindeprotégerlacommunicationsurle réseau.

8.8. EVALUATION DE PERFORMANCES 153

8.7.3 Discussion

L’interopérabilitéentredeuxsystèmesimpliquetoujoursquela sécuritédel’ensembleestcelledusystèmele plusfaible.Le sous–systèmedesécuritéd’Arias estpluspetit etmoinscomplexequeceluid’AIX. Nousprétendonsdoncquela réalisationdumodèledeprotectiond’Ariasn’estpasle point faibledela sécurité

8.8 Evaluation deperformances

Notrebut estdemesurerle coûtduchangementdedomaineetdupassagedecapacitéenparamètreentrelesdomainesdeprotectiondansle systèmeArias.Dèsquedesdomainesdeprotectionsontcréés,ils restentactifsjusqu’àcequ’ils soientdétruitsexplicitementouquele systèmesoit redémarré.Ainsi, seuleuneapplicationqui passedansundomainedeprotectioninactif paiele coûtdecréationdudomaine.Pourmesurerlecoûtduchangementdedomaine,nouslançonsle programmeunefois avantlesmesures,afind’éviterd’inclure lescoûtsliésà l’initialisation et la pagination.Nousavonsmesuréle tempsmoyenderéalisationd’un appelinter-domainedeprotection.Lesmesuresontétéeffectuéeslocalementsurunestationdetravail (Bull EstrellaavecAIX 4.1.4),cardansle systèmeArias, la protectionet la répartitionsontorthogonales.

8.8.1 Coût d’ensemblede la protection

Le coûtd’ensembledela protectionestmesurécommele coûtmoyend’un appeldeprocédurevidedansle mêmemoduledecode,entredeuxmodulesdecodedansle mêmedomainedeprotectionetentredeuxmodulesdecodedansdeuxdomainesdeprotectiondifférents.Lesrésultatssontdonnésdansla table8.1.

coûtd’un appeldansle mêmemoduledecode 29nscoûtd’un appelentre2 modulesdecode 47nscoûtd’un appelentre2 domainesdeprotection 750 { s

TAB. 8.1:Coûtd’ensembledela protection

Le surcoûtdenotremécanisme5 deprotectionadeuxorigines: le coûtinduit parla séparationdesfonctionsdansdesmodulesdecodeséparéet le coûtinduit parle transfertdesparamètresetducontrôleentredesdomainesdeprotectiondifférents.La programmationmodulaireséparele codeentreplusieursmodulesdecode,alorsqu’il n’yauraitqu’unseulmoduledecodedansunprogrammemonolithiquenonprotégé.Ainsi, le codeexécutépourunappeldeprocéduren’estpastoujourslocal.Dansle mêmemodule(et tantquela taille dumodulen’estpastropgrande),lesprocéduressontadresséesrelativementaucompteurordinal.Un appelàuneprocédurestockéedansunautremodulepasseà traversunetabled’indirectionappeléeTOC(Tableof Contents)associéeaumodule.Cesurcoûtn’estpastrèsélevé (de29à47ns)etnousnepensonspasquelesapplicationsprotégéesdegrandetailleserontfragmentéesendenombreuxmodulesdecode.

5Le coutd’un RPClocal estde l’ordre de1350 | s. La performancedenotreréalisationestdoncrespectable,mêmesi nousnefaisonspastousle travail d’un appelRPCstandard.


Engénéral,uneapplicationprotégéeinclut plusieursdomainesdeprotection.La troisièmelignedela table8.1donnele coûtd’un appelinter-domainedeprotectionpourunappeldeprocédurevide,c’estàdiresanstransfertdecapacité.Cecoûtestélevécomparéàceuxdesappelslocaux,maisil doit êtrecomparéaucoûtd’un appelàdistance(RPC)localà lamachine,cequi estfait dansla suite.

8.8.2 Surcoûtsliésà l’implantation

Commeexpliquéauparavant,le prototypeAriasestbasésurdesdesmodulesSTREAMSquisontintégrésdansle noyau.L’utilisation desmodulesSTREAMSaétéunbonchoixpourleprototypage,maiselles’estavéréetrèscoûteuse.Dansla suite,nousdécomposonsnotremécanismeendifférentscomposantsafindemesurerle coûteffectivementinduit parl’utilisation desmodulesSTREAMS.Lescoûtsdesdifférentscomposantsimpliquésdansle mécanismedechangementdedomainesontdonnésdansla table8.2.Le coûtd’un composantestmesuréenle court-circuitantetenmesurantla différenceaveclecoûtglobal.

talonsclientet serveur(emballagedesparamètres) 20 { scodenoyau(transfertdescapacités) 20 { sSTREAMS(RPCetchangementdecontexte) 710 { s

TAB. 8.2:Coûtdescomposantsduchangementdedomaine

Lesrésultatsconfirmentquela plusgrandepartieducoûtd’un changementdedomainedansnotreréalisationprovientdel’utilisation desmodulesSTREAMSetduchangementdecontexteentrelesprocessusUnix implantantlesdeuxdomainesdeprotection.Le coûtdepassageà traverslestalonsestrelativementfaiblecomparéaucoûtglobaldumécanisme.Un talonemballelesparamètres,construitla C–listeet vérifiequelescapacitésfourniesparl’autredomaine(l’appelantpourle talonserveuret l’appelépourle talonclient)correspondentauxspécificationsdel’interfacedeprotection.Le codeexécutédansle noyau,qui utiliseenviron 20 { s, redirigelesrequêtesentrelesdomaineset transfèrelescapacitésenfonctiondela C–listeinclusdansle messagedelarequête.Afin dedonneruneidéedel’améliorationentermesdeperformancesquel’on peutattendred’uneré-implementation,nousavonscomparéle changementdedomaineimplantéavecdesmodulesSTREAMS(danslesmêmesconditionsquedansnotresystème)avecunchangementdedomaineréaliséavecdessocketsUnix baséssurTCP. Lesrésultatsprésentésdansla tablequi suitmontrentqu’ungainsignificatifpeutêtreobtenuenremplaçantlesmodulesSTREAMSparunprotocolespécialiséfondésurdesfonctionsdecommunicationdebase.

appelinter-domainebasésurdesSTREAMS 710 { sappelinter-domainebasésurdessockets(TCP) 250 { s

TAB. 8.3:Coûtdedifférentsmécanismesd’appelinter-domaine

8.9. RÉCAPITULATION 155

8.9 Récapitulation

Danscechapitre,nousavonsprésentéuneargumentationpourla généricitédumodèle.Nousavonsmontrécommentlesdifférentsmodèlesdeprotectionprésentésenchapitre3 peuventêtreréaliséssurle modèleàcapacitéscachées.La programmationparcomposantset lesarchitectureslogiciellesontétéproposéespourfaciliter la programmationdesapplicationscomplexes.Nousavonsmontréunecorrespondancedirecteentrelesentitésdumodèleàcapacitéscachéesetcellesdesarchitectureslogicielles.Nousavonsprésentédeuxscénariosd’applicationqui montrentcommentutilisernotreservicedeprotection.Le scénarioNIS montrequele modèleoriginal [Hagimont96] s’adaptebienauxextensionsdusystème.Le scénario“éditeurcoopératif” montrela nécessitéduchangementdynamiquededomainepourla réalisationdesapplicationscoopératives.La programmationparcomposantset lesarchitectureslogiciellesfacilitentégalementl’évolutivité desapplicationsetpermettentderéutiliserlescomposantsdansd’autresapplications.L’expérienceavecle servicedenomsmontrecommentle mêmemoduledecodepeutêtreutilisédanstroiscontextesdeprotectiondifférents.L’évaluationdeperformancedel’appelavecchangementdedomaineindiqueuneefficacitécomparableàcelled’un RPCstandard.Deplus,le remplacementdesmodulesSTREAMSparuneimplantationbaséesurdessocketspermetungaindeperformancesignificatif.LesstructuresdegestiondescapacitéssontessentiellementlesmêmesquecellesutiliséesparSaunier, l’efficacitéet le passageà l’échelledenotreréalisationdoiventêtrecomparablesàceuxrapportésdanssathèse(cf. pages114–120dela thèsedeSaunier[Saunier96]).

Chapitre9

Conclusions

9.1 Principaux résultats

9.1.1 Rappeldesobjectifs

L’objectif decetravail étaitdeconcevoir et réaliserunmécanismedebasepourla réalisationdela protectiondansunsystèmedegestiondedonnéespersistantesrépartiesréalisésouslaformed’unemémoirevirtuelle répartieunique(singleaddressspace). Cemécanismedevaitavoir lesqualitéssuivantes(voir détailsen 1.3).

– Généricité

– Facilitédeprogrammation

– Facilitéderéutilisationdescomposantslogiciels

– Facilitéd’évolutiondela spécificationdela protection

– Protectiondelogicielsrécupérésailleurs

Cesexigencesnousontconduitsàuneexpressiondela définitiondela protectionséparéedutextedesprogrammesd’applications,utilisantdesinterfacesdeprotectionetmiseenœuvreparunmécanismede“capacitéscachées”.Surcesbases,nousavonsconçuet réaliséunsystèmedeprotectionrépondantauxbesoinsexprimés.Cemécanismea étéintégréà laplate-formeArias,servicedegestiondedonnéespersistantesrépartiesréalisésurun réseaulocaldeserveurs.Nousl’avonsutilisépourdesapplicationssimples.Dansla suitedecettesection,nousexaminonsdansquellemesurelesobjectifsdequalitédécritsci-dessusontétéatteints.Nousindiquonsensuitelesapportsdenotretravail.

9.1.2 Satisfactiondesqualités requises

Généricitédu modèle

La généricitéaétéunobjectifprincipaldansla conceptionduservicedeprotection.Nousavonsprésentéuneargumentationpourla généricitedumodèledansla section8.2.Nousavonsmontréquele modèlepermetderéaliserla plupartdespolitiquesdeprotection,y comprisunepolitiquesmandataire,discrétionnaire,parrôle,et la politiquedela murailledeChine.Le confinementdescapacitésparle systèmeet le contrôledela délégationrendupossibleparlesinterfacesdeprotectionsontdesélémentcléspourcerésultat.

157

158 CHAPITRE9. CONCLUSIONS

Facilité deprogrammation

Enraisondesamodularité,le modèles’adaptebienauxarchitectureslogiciellesetà laprogrammationparcomposants.Il s’intègredoncbiendanslestendancesdugénielogicield’aujourd’hui.Deplus,la séparationdela spécificationdela protectionetdel’algorithmiquedel’applicationfacilite la programmationparétapeset fournit unecertainetransparencedela protectionvis–à–visduprogrammeur.

Évolutivité

La spécificationdela protectiond’uneapplicationdansla configurationdudomaineinitial etdanslesinterfacesdeprotectionpermetdefaireévoluerla protectiond’uneapplicationsansmodifiercelle–ci.L’inclusiondesinterfacesdeprotectiondanslescapacitésdechangementdedomainefacilitecetteévolution,parcequ’il n’y apasdetalonsà modifiercommedansunsystèmeRPCstandard.

Réutilisabilité descomposantslogiciels

Notreexpérienceavecdifférentespolitiquesdeprotectionpourle servicedenomsmontrelaréutilisabilitédescomposantslogicielsdansdescontextesdeprotectiondifférents.Il faudraitdavantaged’expérienceavecle systèmepoursavoir si lesmodulesdecodevontvraimentêtreréutilisés.

Possibilitéd’intégration de logicielsconçusailleurs

NousprétendonsquedeslogicielsconçusailleurspeuventêtreencapsulésetprotégéesparlesystèmeArias,maisnousnel’avonspasvérifiéexpérimentalement.

9.1.3 Apports du travail

Etude et classificationdessystèmesà capacités

Nousavonsréaliséuneétudesynthétiquedesmodèlesdecontrôled’accèset leursréalisationsdanslessystèmesrépartisexistants.Nousavonsplusparticulièrementétudiélesmécanismesàbasedecapacitéslogiciellespourlessystèmesrépartis,etnousenavonsproposéunenouvelletaxinomie.

Propositionet analysed’un modèleétendu

Nousavonsproposéunmodèleétendudumodèledescapacitéscachées.Cemodèleutilisedeuxtypesdecapacités(accèset changementdedomaine),et réaliseunetransparencetotaledela manipulationdela capacitéparrapportauxprogrammeursd’applications.Commeindiquéplushaut,uneanalyse(nonformelle)decemodèlenousapermisdevérifierqu’ilpermettaitla réalisationdesprincipauxmodèlesdeprotectionexistants.

9.2. ÉVALUATION 159

Réalisationdu modèledansArias

Nousavonsfait uneréalisationdumodèleproposé,intégréeauservicedegestiondedonnéesrépartiesArias,utilisantunemémoirevirtuellepartagéeàespaceuniqued’adressagepourl’ensembledesdonnéesdusystème.Le servicedestockagedescapacitésutilise lescapacitésdestockagepersistantdusystèmeArias lui-mêmeetgèredemanièrepartitionnéelesdiférentstypesdecapacités.Lesopérationsdechangementdedomaineutilisentégalementlesfonctionsd’Arias pourle couplagedetalonsdansla mémoirevirtuelle.La modularitédela réalisationpermetl’installationdedifférentespolitiquesdeprotection.Nousavonsfait uneévaluationqualitativeetquantitativedumodèleproposéetdesaréalisation.Lesrésultatsfont l’objet dela sectionsuivante.

9.2 Évaluation

L’évaluationdecritedansle chapitre8 nousapermisdefaireuncertainnombred’expériencesavecle modèledescapacitéscachées.Cesexpériencesnousontpermisdevérifierquelesprincipalesqualitésrequisesétaienteffectivementobtenues(9.1).Quelquesremarquessupplémentairessontdonnéesci-dessous.

9.2.1 Expressiontransparentede la protection

Un but dumodèledescapacitéscachéesaétéderendretransparentela spécificationdelaprotection.Nousavonsobtenuunetransparenceauniveaudu transfertdesdroits,maispasauniveaudel’encapsulation.Le programmeurdoit toujoursêtreconscientdela structurationdel’applicationenmodulesqui peuvents’exécuteravecdesdroitsd’accèsdifférents.Le modèles’appliquebienà la programmationparassemblageoù lescomposantssontsouventtrèsautonomes.Le mêmeargumentd’autonomieindiquequele modèledoit biens’appliquerauxenvironnementsdeprogrammationparagentsmobiles.Cetaspectestle sujetd’uneautrethèseencoursdansle cadreduprojetSirac.

9.2.2 Support pour lesapplicationscoopératives

Le besoind’introduireleschangementsdedomainedynamiquesindiquequele modèlen’estpasbienadaptéà la programmationdesapplicationscoopérativesdansuneMVRU. Par contrelesexemplesduserveurd’impression(cf. 6.4)etduservicedenoms(cf. 8.5)montrentquelemodèleestbienadaptéauxservicesconstruitscommedesextensionsdusystème.

9.2.3 Performances

L’évaluationquantitativeestrestéesommaire,d’autantplusquela recherchedeperformancesélevéesnefiguraitpasdanslesobjectifsinitiaux. Elle anéanmoinsmontréquele coûtsupplémentaireinduit parla protectionétaitacceptabledanslessituationspratiquesoù laprotections’exerceentrecomposantsà relativementgrosgrain.Concernantlessurcoûtsdirectementliésànotreimplantation,qui sontrelativementélevés,nousavonspuvérifierqu’ils sontdusenmajeurepartieà l’usagedemodulesSTREAMS(justifiédansuneréalisationprototypepardesconsidérationsdefacilitédeconstruction),etqu’uneréimplémentationsur


unsupportplusefficace(socketsUnix) pouvait apporterungainsignificatif (del’ordre d’unfacteur3).

9.3 Perspectives

Il y aquatrecontinuationsnaturellesdu travail presentédanscettethèse: la continuationdel’intégrationduprototypedansla version2 d’Arias, l’applicationdumodèledescapacitéscachéesàd’autressystèmes,unecontinuationdu travail surla taxinomieetunemodélisationformelledumodèleàcapacitéscachéeset la preuve formelledela généricitédumodèle.Cescontinuationspossiblessontdécritesdansla suite.

9.3.1 Application du modèledansArias

Le prototyperéaliséaétépartiellementintegrédansla premièreversiond’Arias. Pourpouvoirfaireplusd’expériencesavecla programmationselonle modèle,il auraitfallu uneintégrationcomplètedansAriasv. 2 (versionpré-industrielle).Cetteintégrationn’a pasétépossibleenraisonducalendrierduprojet.

Changementdynamiquededomaine

La réalisationduchangementdynamiquededomainepermettraitdefairedesexpérienceavecdesapplicationscoopératives.Pourfairecelail faudraitréaliserunsupportpourunsystèmeàobjetssurAriasousurunsystèmeprésentantdesfonctionséquivalentes,parexempleuneJVM répartiesurunegrappedemachines.Nousenvisageonsdemenerunetelleexpérience.

API decapacités

L’API courantesecomposed’un ensembledefonctionsnécessairespourla miseenœuvreduprototype.Un ensembled’applicationsplusétendunouspermettraitdevérifiersi l’ensembleestcompletet si touteslesfonctionsont desbonnesinterfaces.

Réalisationd’un SGBDsur Arias

Un systèmedegestiond’unebasededonnées(SGBD)estencoursderéalisationsurAriasv. 2 1. Cesystèmeauraitbesoinduservicedeprotectionet lesexpériencesavecceSGBDnouspermettraientdevérifierquele systèmepassebienà l’échelle.

9.3.2 Application du modèledansd’autr essystèmes

La protectionestunaspectnon–fonctionneldesprogrammes.L’idéedeprogrammerlaprotectionendehorsdesmodulesdecodeproposéeparle modèlesembleêtrebonne.Cetteidéea déjàétéappliquéesdansd’autrescontextesparexempledansle contextedeCORBA [Hagimont97a], dansle contextedesagentsmobiles[Jensen97a, Hagimont97b], dansle contextedesarchitecturesdelogiciels[Jensen98b]etdansle contexted’un systèmed’Unix

1La réalisationdeceSGBDestle sujetd’uneautrethèsedansle cadreconjointduprojetSiracetdu laboratoireIMAG-LSR

9.3. PERSPECTIVES 161

standard[Jensen98d]. L’idéeestmaintenantencoursderéalisationpourdessystèmesauto–configurablesprogrammésdansle contextedeJini [Jensen99].

9.3.3 Application de la taxinomie

L’applicationdela taxinomieauxautressystèmesà capacitésrépartisenfindepouvoirclassifieretcomparercessystèmes.Onpourraitainsianalyserlespropriétésd’un systèmeàcapacitésqui sontdéterminéesparlaclassificationdusystème,c’est–à–direquellessontlesforceset lesfaiblessesqui peuventêtreidentifiéesàpartir dela classificationdusystème.

9.3.4 Preuve formelle de la généricitédu modèle

Danscettethèsenousavonsprésentéuneargumentationpourla généricitédumodèle.Unedescriptionformelledumodèleà capacitéscachéespermettraitdefaireunepreuve formelledecerésultat.

AnnexeA

Langagededéfinition desinterfacesdeprotection

Nousavonsfait quelquesmodificationsaulangagededéfinitiondesinterfacesdeprotection(LDIP), parrapportàceluidécritparSaunier. Nousprésentonslesmotivationspourcesmodificationset le LDIP dansla suite.

A.1 Rappeldesobjectifs

Lesobjectifsdu langagesontlessuivants1 :

– le LDIP doit enpremierlieu permettredepréciserla signaturedesprocéduresprotégées;

– celangagedoit depluspermettredespécifierlesmodalitésdetransfertéventueldecapacitéslorsd’un changementdedomaine;

– enfinle langagedoit permettredespécifierquelparamètredéterminele domaineappelélorsd’un appeldechangementdynamiquededomaine.

La spécificationdesmodalitésdetransfertéventueldecapacitésconcernepotentiellementchaqueparamètrequi représenteuneadressevirtuelle,etpourchacunelledoit précisersi unecapacitédoit accompagnercetteadresseoupas.Si oui, la spécificationdoit exprimerqueltypedecapacitédoit accompagnerl’adressevirtuellepasséeenparamètre(capacitéd’accèsoucapacitédechangementdedomaine)et le droit decopieretdéléguercettecapacité.Le choixdelangagededéfinitiond’interfacesebaselargementsurla grammaireproposéeparSaunier. La définitionoriginaleduLDIP permetdespécifieràpartir dequelleC–listeunecapacitédoit êtretransférée(la clausefrom capa–list–ident)etdansquelleC–listela capacitétransféréedoit êtreinsérée(la clauseinstall capa–list–ident).Notredécisiond’identifieruneC–listeparl’adressevirtuelledusegmentqui contientla C–listeintroduit le risquedesetromperparcequele nomn’estpassignificatif.Le problèmepeutêtrerésoluparl’utilisationd’un nomsymboliquedansla spécificationdel’interfacedeprotection,maiscelaouvreunenouvellevoied’attaqueà traversle servicedenoms.Nousavonsdoncchoisidesupprimercesdeuxclausesdansla spécificationdu langage2.

1LesdeuxpremiersobjectifsontétéidentifiésparSaunier.2La supressiondecesdeuxclausesenlève l’ambiguïtédansla grammairedeSaunierqui contientdeuxdéfini-

tionsdifférentesde“direction”.

163

164 ANNEXE A. LANGAGEDE DÉFINITION DESINTERFACESDE PROTECTION

Nousprésentonsd’abordla grammairedu langagedebaseavantdedécrirelesextensionsnécessairespourle supportduchangementdynamiquededomaine.

A.2 Grammair edu langage

La grammairedu langagedespécificationdesinterfacesdeprotectionestdécriteparletableauA.1.

definition–list }�~ definition’ ; ’�definition’ ; ’ definition–list

definition }�~ struct–definition�typedef–definition�proc–definition

struct–definition }�~ ’struct ’ struct–ident’ � ’ arias–declaration–list’ � ’arias–declaration–list }�~ arias–declaration’ ; ’�

arias–declaration’ ; ’ arias–declaration–listtypedef–definition }�~ ’ typedef ’ simple–declarationproc–definition }�~ ’procedure ’ proc–ident’ ( ’ parameter–list ’ ) ’parameter–list }�~ ��

parameter’ , ’ parameter–list )parameter }�~ directionarias–declarationdir ection }�~ ’ in ’

�’out ’

�’ inout ’

arias–declaration }�~ simple–declaration�capa–declaration

simple–declaration }�~ type–identvariable–ident�type–identvariable–ident’ � ’ value’ � ’�type–ident’* ’variable–ident�type–ident’ (* ’ function–ident’ ) ’

capa–declaration }�~ capa–typecopy–righttype–ident’* ’ variable–ident�’CAPA_DOMAIN’ ( � �

copy–right) type–ident’ (* ’ function–ident’ ) ’capa–type }�~ ’CAPA_READ’�

’CAPA_WRITE’�’CAPA_EXECUTE’

copy–right }�~ ’COPY_NO’�’COPY_REDUCE_CAPA_RIGHT’�’COPY_REDUCE_COPY_RIGHT’�’COPY_REDUCE_ALL_RIGHT’�’COPY_ALL’

TAB. A.1: La grammairedu langagededéfinitiondesinterfacesdeprotection

Nousutilisonsle symbole� pourdésignerunechaînedecharactèresvide.

A.3. CHANGEMENTDYNAMIQUE DE DOMAINE 165

A.3 Changementdynamiquededomaine

Le supportpourle changementdynamiquededomainenécessiteunemodificationdansladéfinitiond’uneprocédure,c’est–à–diredansla ’proc–definition’(cf. A.2).

proc–definition }�~ ’procedure ’ proc–ident’ ( ’ domainparameter–list ’ ) ’domain }�~ ��

’domain ’ capa–typeadresse

TAB. A.2: Modificationsnécessairespourle supportduchangementdynamiquededomaine

La modificationdela grammairedécriteci–dessuspermetdespécifieruneseuleadressevirtuelle,cecicorrespondàun identificateurd’objet. Il suffit derépéterla spécificationdel’adressepourpouvoir supporterunelisted’adressesavecdescapacitésassociées.

A.4 Récapitulation

Le langagededéfinitiondesinterfacesdeprotectionprésentéici correspondlargementàceluiproposéparSaunier. En fait, nousutilisonsuneversionmodifiéedugénérateurdetalondeSaunier. Nosmodificationsvisentprincipalementà simplifier la générationdestalonspourlesrendreplusefficaces.LesmodificationsparrapportaulangageproposéparSauniersontlessuivantes:

– changementdela définitiond’uneprocédurepourpermettrel’appeldeprocéduresansparamètres;

– ajoûtdela spécificationdudroit dedélégationpourunecapacité;

– suppressiondela spécificationdela C–listed’origineoudedestinationd’un transfertdecapacités(lesclauses“ install et “ from ”).

166 ANNEXE A. LANGAGEDE DÉFINITION DESINTERFACESDE PROTECTION

AnnexeB

Interface deprogrammation descapacités

Cetteannexedécritl’interface(l’API) qui permetdemanipulerlescapacités.CetteAPI secomposed’un ensembledefonctionspourlesquellesnousavonsidentifiéunbesoin.NousneprétendonspasquecetteAPI soit complète,maisellenoussembleêtrecohérente.Lesfonctionsdel’API sontpréfixéesparl’acronymedumoduleauquelellesappartiennent,c’est–à–dire:

PDM – ProtectionDomain Module. Le moduleresponsabledela gestiondesdomainesdeprotection.

PDD – ProtectionDomain Daemon.Le démonresponsabledela créationdynamiquedesdomainesdeprotection.

CL – Capability List. Le moduleresponsabledela gestiondescapacitésdanslesC–listes.

B.1 Administration du système

La créationd’uneC–listeinsèrelesdroitsdemanipulationdansla C–listepardéfautdudomainecréateur. L’administrateurdusystèmeobtientdoncle droit demanipulertouteslesC–listespartransitivité etdu fait qu’il a crééla premièreC–listedusystème.

B.2 Domainesdeprotection

Lesfonctionsqui permettentdecréeretmanipulerlesdomainesdeprotectionsontdécritesdansla suite.

int PDM_PDCreate(AGt_Addr clist, uid_t uid, gid_t gid)

Créeundomainedeprotectionàpartir d’uneC–liste,unUID etunGID passésenparamètre.L’adressedela C–listedevient l’identificateurdunouveaudomaine.Il fautquel’appelantpossèdetouslesdroitssurla C–listeetquela C–listenesoit pasla C–listedebased’un autredomaine.Enfin, il fautêtreroot pourspécifierunautreUID ouGID queceuxdel’appelant.

167

168 ANNEXE B. INTERFACEDE PROGRAMMATION DESCAPACITÉS

PDMt_Desc PDRead(AGt_Addr pdid)

Retournele descripteurdudomaine(l’UID et le GID dudomainepardéfaut).

int PDDump(AGt_Addr pdid)

Imprimele descripteurdudomaineet l’arborescencedescapacitésdudomainesurle stdout .

int PDDestroy(AGt_Addr pdid)

Supprimeundomainedeprotection.Il fautquele domaineappelantpossèdeunecapacitéquipermetdesupprimerla C–listedebasedudomaine.

B.3 C–listes

Le segmentd’uneC–listecontientunentêtequi identifiela racinedesarborescencesdescapacitésd’accès,dechangementdedomaineetd’indirection.Cettestructureestla mêmequecelled’un domainedeprotection,maisl’UID etGID sontceuxdenobody etnogroup . Lesfonctionsqui permettentdecréeretmanipulerlesC–listessontdécritesdansla suite.

AGt_Addr PDM_CLCreate(AGt_Addr *segment, int size)

CréeuneC–listevideet insèretouslesdroitssurcettelistedansla C–listedebasedudomaineappelant.La fonctionretournel’adressedusegmentcréécommeidentificateurdela C–liste.

int CLAdd(AGt_Addr clist, capa_t capa)

Rajoutela capacitédansla bonnearborscencedecapacitésdansle segmentidentifiéparclist . Il fautquel’appelantpossèdele droit derajouterdescapacitésdansla C–liste.Unevaleurdeclist = 0 signifiequela capacitédoit êtreinséréedansla C–listedebasedudomaine.

int CLDel(AGt_Addr clist, capa_t capa)

Supprimela capacitécapa dansla C–listeclist . Il fautunecorrespondanceexacteentrelesdroitsd’accèset lesdroitsdedélégationspécifiésparcapa et la capacitédansla C–listepoursupprimerla capacité.

int CLDump(AGt_Addr clist)

Imprimel’arborescencedescapacitésdudomainesurle stdout .

int CLDestroy(AGt_Addr clist)

Supprimela C–liste.Il fautquele domaineappelantpossèdeunecapacitéqui permetdesupprimerla C–liste.

AnnexeC

NIS : Network Information Service

Le but decetteannexeestdedécrireengénéralcommentfonctionneNIS etcommentNIS peutêtreutilisépourfaciliter l’administrationdesutilisateursdansunprojettel queSIRAC.

C.1 Description généraledu NIS

NIS estunsystèmedéveloppéparSunMicrosystems,qui facilite la maintenanced’unedescriptiondela configurationd’un réseaudestationsdetravail defaçoncohérente.L’implementationduNIS reposesurunebasedesdonnéesdistribuées,utilisantla technologieclient/serveur.UnebaseNIS contientnormalementlesinformationssuivantes: descriptionsdesutilisateurs(/etc/passwd sans“shadow”, /etc/group et /etc/aliases ), adressesIP(/etc/hosts ), servicesofferts(/etc/services ), descriptiondesserveursdeboot(/etc/ethers , /etc/bootparams , etc.).Il n’estpasnécessairededéfinir touslesservicesetonpeutsansdouteendéfinird’autres.Un systèmeNIS estorganiséselonunehiérarchiedesserveursNIS, avecunseulserveur“master”etunclientsurtouslesmachines.Il estpossiblededefinirplusieursserveursintermédiaires(appeléserveurs“slave”) pouraugmenterlesperformancesoù la disponibilitéduserviceNIS. Le serveurmasterestla seulmachinequi peutchangerlesinformationsdansNIS. Aprèschaquemiseà jour, le “master”diffuselesnouvellesinformationsà tousles“slaves”.

C.2 La mécaniquedu NIS

NIS estnormalementutilisécommeunsupplémentauxconfigurationslocales(certainesutilisateurs(root,daemon,.. . ) sonttoujoursdefinisdansle /etc/passwd localpourassurerle fonctionnementdela machineindépendammentduNIS. L’utilisation duNIS estnormalementlancéeparunelignedansle /etc/passwd qui contientun “ � ”.Pourquelesprogrammesqui utilisentlesroutinespourexaminerle /etc/passwd(getuid , getpwent , . . . ) continuentà marcheril fautinstalleruneversionspecialedelabibliothèqueC qui comprendlesentréesNIS dans/etc/passwd etqui saitinterrogerleserveurNIS pourobtenirl’information demandée.

169

170 ANNEXE C. NIS : NETWORK INFORMATION SERVICE

Certainsprogrammescommelogin , ftp , rsh , . . .doiventêtreliésstatiquement,doncil fautinstallerlesnouvellesversionsdecesprogrammesadaptéesauNIS.

C.3 Avantagesdu NIS

NIS permetdemaintenirunebasededonnéesdesutilisateursetdesmachinescohérentesurunréseau,c’est–à–direqu’uneseuledéfinitionsuffira pourqueunutilisateurpuisseutiliserunensembledemachines— l’ensemblepeutêtredefinipardesgroupesinternesduNIS(“netgroups”)qui peuventrestreindrel’ensembledesutilisateursqui ont le droit d’accéderàunecertainemachine).L’utilisation desnetgroupspermetdedefinir lesresourcesdisponiblespourunutilisateurselonunmodèle(“template”),parexempleunstagiaireAriasaaccèsàchoiseul,apiaet lesmachinesdecrash).Quandl’information duNIS estmiseà jour elleestdisponiblesurtouteslesmachinesinstantanément,sansinterventiondel’administrateurlocal.

C.4 Problèmeslié au NIS

Le “master”NIS estunpoint faibledusystème(onnepeutpasmettreà jour l’informationdansNIS pendantuncrashduserver “master”).LesinformationsdefiniesdansNIS sontgénéralementvisiblespartout.Çaveutdirequ’unutilisateurmalveillant localpeutobtenirunecopiedesmotsdepassedetouslesutilisateursetutiliserunprogrammecommecrack ou john the ripper pourtrouver le motdepassedequelqu’und’autre.Il existedemécanismespourcacherlesmotsdepasse(“shadowpassword”), maisils nesontpasstandardisés.Un dernierproblèmeestle fait qu’il fautêtreroot pourmodifieruneentréedansNIS. Pourchangersonmotdepassel’utilisateurappelleunprogrammeSUID qui lui permetuniquementdechangersonmotdepasse.Il n’a plusla possibilitédechangersonshellou l’entréeditgecos; lesprogrammesSUID sontnormalementtrèscompliquésetSunapréférédegarderlesprogrammessimples(ils onteubeaucoupproblèmesavecla fonctiondechangementdeshellaudébut, alorsils ont renoncéàétendrela fonctionalitédeNIS).

Bibliographie

[Accetta86] M. Accetta,R. Baron,D. Golub,R. Rashid,A. Tevanian,etM. Young,Mach: A New KernelFoundationfor UNIX Development,dansProceedingsof theSummer1986USENIXConference, pages93–112,juillet 1986.

[AVL62] G. M. Adel’son-Velskii etY. M. Landis,An Algorithm for theOrganizationof Information,Dokl. Akad.NaukSSR, 146:263–266,1962,Traduitenanglaisdans“Soviet Math.” (Dokl.) 3 (1962),pp.1259–1263.

[Ames83] S.R. Ames,M. Gasser, etR. R. Schell,SecurityKernelDesignandImplementation: An Introduction,IEEEComputer, 16,no.7 :14–22,juillet 1985.

[Ames78] S.R. AmesetD. R. Oestreicher, Designof amessageprocessingsystemfor amultilevel secureenvironment,dansProceedingsof AFIPSNationalComputerConference, volume47,pages765–771,Arlington, Virginia,États–Unis,1978,AFIPSPress.

[Anderson86] M. Anderson,R. D. Pose,etC. S.Wallace,A PasswordCapabilitySystem,TheComputerJournal, 29,no.1 :1–8,1986.

[Aura99] T. Aura,DistributedAccess–RightsManagementwith DelegationCertificates,dansJ.Vitek etC. Jensen,éditeurs,Secure InternetProgramming, numéro1603dansLectureNotesin ComputerScience,pages211–236,SpringerVerlag,juin 1999.

[AXENT99] I. AXENT Technologies,RaptorFirewall 6.0WhitePaper, Rapporttechnique,AXENT Technologies,Inc.,1999.

[Badham83] J.Badham,Wargames,MetroGoldwynMayer, 1983.

[Balter95] R. BalteretS.Krakowiak, Objectifsetplandetravail duprojetSirac,RapporttechniqueSirac1–95,LaboratoireIMAG–LSR,juin 1995.

[Balter91] R. Balter, J.-P. Banâtre,etS.Krakowiak, Constructiondessystèmesd’exploitationrépartis, InstitutNationaldeRechercheenInformatiqueetAutomatique,1991.

[Bartoli93] A. Bartoli, S.J.Mullender, etM. vanderValk, Wide–AddressSpaces—ExploringtheDesignSpace,OperatingSystemsReview, 27,no.1 :11–17,janvier 1993.

[Bell75] D. E. Bell etL. J.LaPadula,SecureComputerSystem: UnifiedExpositionandMultics Interpretation,Rapporttechnique2997,MITRECorporation,juillet 1975.

171

172 BIBLIOGRAPHIE

[Bell73a] D. E. Bell etL. J.LaPadula,SecureComputerSystems: MathematicalFoundations,Rapporttechnique2547,VolumeI, TheMITRECorporation,mars1973.

[Bell73b] D. E. Bell etL. J.LaPadula,SecureComputerSystems: A MathematicalModel,Rapporttechnique2547,VolumeII, TheMITRE Corporation,mai1973.

[Bellissard97] L. Bellissard,ConstructionetConfigurationd’Applicationsréparties,Ph.D.thesis,InstitutNationalPolytechniquedeGrenoble,1997.

[Biba77] K. J.Biba,Integrity Considerationsfor SecureComputerSystems,Rapporttechnique,USAir ForceElectronicSystemsDivision,1977.

[Birrell84] A. D. Birrell etB. J.Nelson,ImplementingRemoteProcedureCalls,ACM TransactionsonComputerSystems, 2, no.1 :39–59,février1984.

[Boden95] N. J.Boden,D. Cohen,R. E. Felderman,A. E. Kulawik, C. L. Seitz,J.N.Seizovic, etW. Su,Myrinet — A Gigabit–per–SecondLocal–AreaNetwork, IEEEMicro, 15,no.1 :29–36,février1995.

[Boykin93] J.Boykin, D. Kirschen,A. Langerman,etS.LoVerso,ProgrammingunderMach, Addison-Wesley PublishingCompany, 1993.

[Brewer89] D. F. C. BreweretM. J.Nash,TheChineseWall SecurityPolicy, dansProceedingsof theIEEESymposiumonSecurityandPrivacy, pages329–339,mai1989.

[BSI97] IT–Grundschutzhandbuch 1997: Maßnahmenempfehlungenfür denmittlerenSchutzbedarf, numéro7252CD dansBSI, BundesamtfürSicherheitin derInformationstechnik,1997.

[Callas98] J.Callas,L. Donnerhacke,H. Finney, etR. Thayer, OpenPGPMessageFormat,Requestfor Comments(RFC)2440,Network WorkingGroup,1998.

[Cameron91] J.Cameron,Terminator2 : JudgementDay, CarolcoInternationalInc.,juillet 1991.

[Campbell96] R. H. Campbell,T. Qian,W. Liao, etZ. Liu, ActiveCapability: AUnifiedSecurityModel for SupportingMobile, DynamicandApplicationSpecificDelegation,Rapporttechnique,Universityof Illinois,Urbana–Champaign,février1996.

[Carter91] J.Carter, J.Bennet,etW. Zwaenepoel,Implementationandperformanceof Munin, dansProceedingsof the13thACM SymposiumonOperatingSystemsPrinciples, pages152–164,Ashevill, NorthCarolina,États–Unis,octobre1991.

[Cayuela92] J.Cayuela,P. Y. Chevalier, A. Duda,A. Freyssinet,D. Hagimont,S.Lacourte,P. Ledot,M. Riveill, etX. RoussetdePina,La machineGuide2, Bull–IMAG notedetravail interneK16.archi.

[Chang98] C.-C.Chang,G. Czajkowski, C. Hawblitzel, D. Hu, etT. vonEicken,SecurityversusPerformanceTradeoffs in RPCImplementationsfor SafeLanguageSystems,dansProceedings, pages158–162,Sintra,Portugal,septembre1998.

BIBLIOGRAPHIE 173

[Chase99] J.Chase,Communicationprivée,août1999.

[Chase95] J.Chase,AnOperatingSystemStructure for Wide-AddressArchitectures,Ph.D.thesis,Universityof Washington,août1995.

[Chase94] J.Chase,H. M. Levy, M. J.Feeley, etE. D. Lazowska,SharingandProtectionin aSingleAddressSpaceOperatingSystem,ACMTransactionsonComputerSystems, 12,no.4 :271–307,1994.

[Chase93] J.Chase,H. M. Levy, etV. Issarny, SupportingDistribution inSingle-AddressSpaceOperatingSystems,dansProceedingsof the5thACM SIGOPSEuropeanWorkshop, septembre1992,AlsoappearedinOperatingSystemsReview, ACM SIGOPS,April 1993.

[Chase92] J.Chase,H. M. Levy, E. Lazowska,etM. Baker-Harvey, Opal: A SingleAddressSpaceSystemfor 64-Bit Architectures,dansProceedingsofIEEEWorkshoponWorkstationOperatingSystems, avril 1992.

[CheckPoint99] C. Point,CheckPointFireWall–1 : TechnicalOverview, RapporttechniqueP/N31400000010,CheckPoint,avril 1999.

[Clark87] D. D. ClarketD. R. Wilson,A Comparisonof CommercialandMilitaryComputerSecurityPolicies,dansProceedingsof theIEEESymposiumonSecurityandPrivacy, pages184–194,Oakland,California,États–Unis,avril 1987.

[Cortes96a] E. Pérez-Cortés,J.Han,et J.Mossière,Constructiondeprotocolesdecohérencesuruneinterfacegénériquedemémoirerépartiepartagée,dansJournéessur la MémoirePartagéeRépartie(MPR’96), Bordeaux,mai1996.

[Cortes96b] E. Pérez–Cortés,La cohérencesur mesuredansunemémoirevirtuellepartagéerépartie, Ph.D.thesis,InstitutNationalPolytechniquedeGrenoble,1996.

[Cortes95a] E. Pérez-Cortés,P. Dechamboux,et J.Han,GenericSupportforSynchronizationandConsistency in Arias,dans5th.WorkshoponHotTopicsin OperatingSystems, pages113–118,mai1995.

[Cortes95b] E. Pérez–Cortés,Cohérenceetsynchronizationdansunemémoirevirtuellepartagéerépartie,RapporttechniqueSirac3–95,LaboratoireIMAG–LSR,octobre1995.

[Coulouris94a] G. Coulouriset J.Dollimore,Requirementsfor securityin cooperativework : two casestudies,Rapporttechnique671,QueenMary andWestfieldCollege,Universityof London,mai1994.

[Coulouris94b] G. Coulouriset J.Dollimore,A securitymodelfor cooperativework,Rapporttechnique674,QueenMary andWestfieldCollege,UniversityofLondon,août1994.

[CTCPEC93] TheCanadianTrustedComputerProductEvaluationCriteria, V. 3.0e,CanadianSystemSecurityCenter, CommunicationsSecurityEstablishmentof Canada,janvier 1993.

[Dearle94a] A. Dearle,R. di Bona,J.Farrow, F. Henskens,A. Lindström,J.Rosenberg, etF. Vaughan,Grasshopper: An OrthogonallyPersistentOperatingSystem,ComputingSystems, 7, no.3 :289–312,1994.

174 BIBLIOGRAPHIE

[Dearle94b] A. Dearle,R. di Bona,J.Farrow, F. Henskens,D. Hulse,A. Lindström,S.Norris,J.Rosenberg, etF. Vaughan,Protectionin theGrasshopperOperatingSystem,dansProceedingsof the6th InternationalWorkshoponPersistentObjectSystems, Tarascon,France,septembre94.

[Denning76] D. E. Denning,A LatticeModelof SecureInformationFlow,Communicationsof theACM, 19,no.5 :236–243,mai1976.

[Dennis66] J.B. DennisetE. C. VanHorn,ProgrammingSemanticsforMultiprogrammedComputations,Communicationsof theACM, 9,no.3 :143–155,mars1966.

[Dif fie76] W. Diffie etM. E. Hellman,New Directionsin Cryptography, IEEETransactionson InformationTheory, IT–22,no.6 :644–654,novèmbre1976.

[DoD85] TrustedComputerSecurityEvaluationCriteria, numéro5200.28-STDdansDepartmentof DefenceStandard,Departmentof Defence,Décembre1985.

[Douglis91] F. Dougliset J.K. Ousterhout,TransparentProcessMigration : DesignAlternativesandtheSpriteImplementation,Software— PracticeandExperience, 21,no.8 :757–785,août1991.

[Dutton95] H. DuttonetP. Lenhard,AsynchronousTransferMode(ATM) TechnicalOverview, PrenticeHall, 1995.

[Eager88] D. L. Eager, E. D. Lazowska,et J.Zahorjan,TheLimited PerformanceBenefitsof MigratingActiveProcessesfor LoadSharing,dansProceedingsof the1988ACM SIGMETRICSConferenceonMeasurementandModellingof ComputerSystems, pages63–72,SantaFe,NM, EtatsUnis,1988.

[Loepere92a] K. L. (Ed.),OSFMach KernelPrinciples, OpenSoftwareFoundation,Inc. & Carnegie Mellon University, janvier 1992.

[Loepere92b] K. L. (Ed.),OSFMach KernelInterfaces, OpenSoftwareFoundation,Inc. & Carnegie Mellon University, juillet 1992.

[Power99] R. P. (Ed.),1999CSI/FBIComputerCrimeandSecuritySurvey,ComputerSecurity: Issues& TrendsVol. V, No. I, ComputerSecurityInstitute,1999.

[Ellison99] C. M. Ellison,B. Frantz,B. Lampson,R. Rivest,B. M. Thomas,etT. Ylonen,SPKICertificateTheory, INTERNET-DRAFT<draft-ietf-spki-cert-theory-05.txt>,InternetEngineeringTaskForce(IETF), mai1999,Disponiblesurle sitewebdel’IETF,URL="http ://www.ietf.org/internet-draf ts/dr aft- ietf- spki -cert -the ory-0 5.tx t ".

[Ellison98] C. M. Ellison,B. Frantz,B. Lampson,R. Rivest,B. M. Thomas,etT. Ylonen,SimplePublicKey Certificate,INTERNET-DRAFT<draft-ietf-spki-cert-structure-05.txt>,InternetEngineeringTaskForce(IETF), mars1998,Disponiblesurle sitewebdel’IETF,URL="http ://www.ietf.org/internet-draf ts/dr aft- ietf- spki -cert -str uctur e-05 .txt ".

BIBLIOGRAPHIE 175

[Fabry74] R. S.Fabry, Capability–BasedAdressing,Communicationsof theACM,17,no.7 :403–412,juillet 1974.

[Feeley95] M. J.Feeley, W. E. Morgan,F. H. Pighin,A. R. Karlin, H. M. Levy, etC. A. Thekkath,ImplementingGlobalMemoryManagementin aWorkstationCluster, dansProceedingsof the15thACM SymposiumonOperatingSystemPrinciples, pages201–212,CopperMountain,Colorado,États–Unis,Décembre1995.

[Feiertag79] R. J.FeiertagetP. G. Neumann,TheFoundationsof aProvablySecureOperatingSystem(PSOS),dansProceedingsof AFIPSNationalComputerConference, volume48,pages329–334,Arlington, Virginia,États–Unis,1979,AFIPSPress.

[Ferraiolo99] D. F. Ferraiolo,J.F. Barkeley, etD. R. Kuhn,A RoleBasedAccessControlModelandReferenceImplementationwithin aCorporateIntranet,ACM Transactionson InformationandSystemsSecurity, 1999.

[Ferraiolo92] D. F. FerraioloetD. R. Kuhn,Role–BasedAccessControl,dansProceedingsof 15thNationalComputerSecurityConference, 1992.

[Ferrari86] D. FerrarietS.Zhou,A LoadIndex for DynamicLoadBalancing,dansProceedingsog 1986Fall Joint ComputerConference, Dallas,TX, EtatsUnis,1986.

[Fillo97] M. Fillo etR. B. Gillet, Architectureandimplementationof MEMORYCHANNEL, Digital TechnicalJournal, 9, no.1 :27–41,1997.

[Freier96] A. O. Freier, P. Karlton,etP. C. Kocher, TheSSLProtocol: Version3.0,INTERNET-DRAFT <draft-freier-ssl-version3-02.txt>,InternetEngineeringTaskForce(IETF), 1996.

[Gasser88] M. Gasser, Buildinga SecureComputerSystem, VanNostrandReinholdCompany, Inc.,New York, étatsUnis,1988.

[Geib97] J.-M.Geib,C. Gransart,etP. Merle,CORBA : desconceptsà la pratique,Masson,Paris,France,octobre1997.

[Gibson84] W. Gibson,Neuromancer, Victor GollanczLtd., 1984.

[Goldberg96] I. Goldberg, D. Wagner, R. Thomas,etE. A. Brewer, A SecureEnvironmentfor UntrustedHelperApplications,dansProceedingsof the6thUSENIXSecuritySymposium, pages1–13,1996.

[Gong89a] L. Gong,OnSecurityin Capability–BasedSystems,OperatingSystemsReview, 23,no.2, avril 1989.

[Gong89b] L. Gong,A SecureIdentity–BasedCapabilitySystem,dansProceedingsof theIEEESymposiumonSecurityandPrivacy, pages56–63,Oakland,California,États–Unis,mai1989.

[Hagimont97a] D. Hagimont,O. Huet,et J.Mossière,A ProtectionSchemefor aCORBA Environmen,dansECOOPWorkshoponCORBA, juin 1997.

[Hagimont97b] D. HagimontetL. Ismail,A ProtectionSchemefor Mobile AgentsonJava,dans3rd ACM/IEEEInternationalConferenceonMobileComputingandNetworking(MOBICOM), septembre1997.

176 BIBLIOGRAPHIE

[Hagimont96] D. Hagimont,J.Mossière,X. RoussetdePina,etF. Saunier, HiddenSoftwareCapabilities,dans16thInternationalConferenceonDistributedComputingSystems, pages282–289,HongKong,mai1996.

[Hagimont95] D. HagimontetF. Saunier, La protectiondansunservicedegestiondedonnéespersistantespartagées,RapporttechniqueSirac6–95,LaboratoireIMAG–LSR,octobre1995.

[Han96] J.Han,Conceptionet réalisationd’unemémoirepartagéerépartie, Ph.D.thesis,InstitutNationalPolytechniquedeGrenoble,1996.

[Harrison76] M. A. Harrison,W. L. Ruzzo,et J.D. Ullman,Protectionin OperatingSystems,Communicationsof theACM, 19,no.8 :461–471,août1976.

[Heiser98] G. Heiser, K. Elphinstone,J.Vochteloo,S.Russell,et J.Liedtke,ImplementationandPerformanceof theMungi Single-Address-SpaceOperatingSystem,Software : PracticeandExperience, 28,no.9 :901 928,juillet 1998.

[Heiser94] G. Heiser, K. Elphinstone,S.Russell,etJ.Vochteloo,Mungi : ADistributedSingleAddress-SpaceOperatingSystem,dansProceedingsofthe17thAustralasianComputerScienceConf, pages271–280,Christchurch,New Zealand,janvier 1994.

[Heiser93] G. Heiser, K. Elphinstone,S.Russell,etG. R. Hellestrand,A DistributedSingleAddress-SpaceOperatingSystemSupportingPersistence,Rapporttechnique,Universityof New SouthWales,1993.

[IEEE92] IEEE,IEEEStandardfor ScalableCoherentInterface(SCI),Standard1596,TheInstituteof ElectricalandElectronicsEngineering,1992.

[IEEE98] IEEE,IEEESTandardfor GigabitEthernet,Rapporttechnique,TheInstituteof ElectricalandElectronicsEngineering,1998.

[ISO15408] LesCritèresCommunsd’évaluationdela sécuritédestechnologiesdel’information, numéro15408dansNormeinternationaleISO,InternationalStandardsOrganisation(ISO), juin 1999.

[Issarny97] V. Issarny, Configuration-BasedProgrammingSystems,dansF. PlasiletK. G. Jeffery, éditeurs,Proceedingsof SOFSEM’97: TheoryandPracticeof Informatics, volumeLNCS1338,pages183–200,Milovy,CzechRepublic,1997,SpringerVerlag.

[ITSEC91] InformationTechnologySecurityEvaluationCriteria, EuropeanComunities,juin 1991.

[ITU93] T. S.S.of ITU, InformationTechnology— OpensSystemsInterconnection— TheDirectory: AuthenticationFramework, numéroX.509dansITU–T Recomandation,InternationalTelecomunicationUnion,novembre1993,StandardinternationalISO/IEC9594–8: 1995(E).

[JCSEC92] TheJapaneseComputerSecurityEvaluationCriteria, Draft V1.0, Leministèredel’industrieetducommerce,août1992.

[Jensen99] C. JensenetM. Haahr, TowardsaSecurityFramework for Ad HocApplications,SoumisaudeuxièmeworkshopdeDistributedObjectSecurity, OOPSLA’99.

BIBLIOGRAPHIE 177

[Jensen98a] C. JensenetD. Hagimont,ProtectionReconfigurationfor ReusableSoftware,dansSecondEuromicro ConferenceonSoftwareMaintenanceandReengeneering, pages74–81,Florence,Italy, mars1998.

[Jensen98b] C. Jensen,SecureSoftwareArchitectures,dansProceedingsof theEighthNordic WorkshoponProgrammingEnvironmentResearch, pages239–246,Ronneby, Suéde,août1998.

[Jensen98c] C. JensenetD. Hagimont,MutualSuspicionin aGenericObject-SupportSystem,dansJoint Proceedingsof theECOOPWorkshopWorkshoponDistributedObjectSecurityandthe4thWorkshoponMobileObjectSystems(Secure InternetMobileComputations), pages15–20,Brussels,Belgium,juillet 1998.

[Jensen98d] C. JensenetD. Hagimont,ProtectionWrappers: A SimpleandPortableSandboxfor UntrustedApplications,dansProceedingsof the8thACMSIGOPSEuropeanworkshop, pages104–110,Sintra,Portugal,septembre1998.

[Jensen97a] C. JensenetL. Ismail,CapabilityBasedProtectionfor HostingMobileCode,dansProceedingsof the2ndEuropeanResearch SeminaronAdvancesin DistributedSystems, pages234–240,1997.

[Jensen97b] C. Jensen,ReducingComplexity of DistributedApplicationProtection,Presentéau4th CabernetRadicalsWorkshop,Rithmynon,Crete,septembre1997.

[Jospin99] L. Jospin,ConférencedepressedeMonsieurLionel Jospin,Premierministre,à l’issueduComitéinterministérielpourla sociétédel’information, HôteldeMatignon,Conférencedepresse,janvier 1999,Disponiblesurle web,URL="http ://www.premier-ministre.gouv.fr/PM/D 190199 .HTM".

[Kain86] R. Y. Kain etC. E. Landwehr, OnAccessCheckingin Capability–BasedSystems,dansProceedingsof theIEEESymposiumonSecurityandPrivacy, avril 1986.

[Karger84] P. A. KargeretA. J.Herbert,An AugmentedCapabilityArchitecturetoSupportLatticeSecurityandTraceabilityof Access,dansProceedingsoftheIEEESymposiumonSecurityandPrivacy, 1984.

[Keleher96] P. Keleher, CVM: TheCoherentVirtual Machine, UniversityofMaryland,novembre1996.

[Keleher94] P. Keleher, A. L. Cox,S.Dwarkadas,etW. Zwaenepoel,ThreadMarks:Distributedsharedmemoryonstandardworkstationsandoperatingsystems,dansProceedingsof theWinter 1994USENIXConference,pages115–132,SanFrancisco,California,États–Unis,janvier 1994.

[Kirtland98] M. Kirtland, DesigningComponent–BasedApplications, MicrosoftPress,1998.

[Knaff96] A. Knaff, Conceptionet réalisationd’un systèmedestockagefiableextensiblepourunsystèmeà objetspersistantsrépartis, Ph.D.thesis,UniversitéJosephFourier(GrenobleI), 1996.

178 BIBLIOGRAPHIE

[Knuth] D. E. Knuth,TheArt of ComputerProgramming, VolumeIII , chapitreSearching,pages458–478,AddisonWesley, deuxièmeedition,1998.

[Koch98] P. Koch,E. Cecchet,etX. RoussetdePina,GlobalManagementofCoherentSharedMemoryonaSCICluster, dansProc.SCIEurope’98,aConferenceStreamof EMMSEC’98,, Bordeaux,France,septembre1998.

[Kohl93] J.Kohl etC. Neuman,TheKerberosNetwork AuthenticationService(V5), Requestfor Comments(RFC)1510,Network WorkingGroup,septembre1993.

[Koldinger92] E. Koldinger, J.Chase,etS.Eggers,ArchitecturalSupportfor SingleAddressSpaceOperatingSystems,dansProceedingsof the5thInternationalConferenceonArchitectural Supportfor ProgrammingLanguagesandOperatingSystems(ASPLOS), octobre1992.

[Kotz94] D. KotzetP. Crow, TheExpectedLifetime of “Single–Address–Space”OperatingSystems,dansProceedingsof SIGMETRICS’94, pages161–170,SantaClara,California,EtatsUnis,mai1994.

[Kunz91] T. Kunz,Theinfluenceof DifferentWorkloadDescriptionsonaHeuristicLoadBalancingScheme,IEEETransactionsonSoftwareEngineering,17,no.7, juillet 1991.

[Lai92] X. Lai, OntheDesignandSecurityof Block Ciphers, Hartung–Gorre,1992.

[Lampson92] B. Lampson,M. Abadi,M. Burrows,etE. Wobber, AuthenticationinDistributedSystems: TheoryandPractice,ACM TransactionsonComputerSystems, 10,no.4, novembre1992.

[Lampson81] B. W. Lampson,DistributedSystems—architectureandImplementation,chapitreAtomic Transactions,pages246–265,numéro105dansLectureNotesin ComputerScience,SpringerVerlag,1981.

[Lampson73] B. W. Lampson,A Noteon theConfinementProblem,Communicationsof theACM, 16,no.10 :613–615,octobre1973.

[Lampson71] B. W. Lampson,Protection,dansProceedingsof the5thPrincetonSymposiumonInformationSciencesandSystems, pages437–443,mars1971,réimprimédansOperatingSystemsReview, 8, 1 janvier 1974pages18–24.

[Landwehr81] C. E. Landwehr, FormalMethodsfor ComputerSecurity, ACMComputingSurveys, 13,no.3 :247–278,septembre1981.

[Levy84] H. M. Levy, Capability–BasedComputerSystems, Digital Press,1984.

[Li89] K. Li etP. Hudak,Memorycoherencein sharedvirtual memorysystems,ACM TransactionsonComputerSystems, 7, no.4 :321–359,novembre1989.

[Litzkow87] M. J.Litzkow, M. Livny, etM. W. Mutka,Condor: A Hunterof IdleWorkstations,ComputerScienceTechnicalReport730,ComputerScienceDepartment,Universityof Wisconsin-Madison,1987.

[Lomet77] D. B. Lomet,ProcessStructuring,Synchronization,andRecoveryUsingAtomic Actions,SIGPLANNotices, 12,no.3 :128–137,1977.

BIBLIOGRAPHIE 179

[Mazieres98] D. MazièresetM. F. Kaashoek,EscapingtheEvils of CentralizedControlwith self–certifyingpathnames,dansProceedingsof the8thACMSIGOPSEuropeanworkshop, pages118–125,Sintra,Portugal,septembre1998.

[McCauley79] E. J.McCauley etP. J.Drongowski, KSOS: TheDesignof aSecureOperatingSystem,dansProceedingsof AFIPSNationalComputerConference, volume48,pages345–353,Arlington, Virginia,États–Unis,1979,AFIPSPress.

[McGraw99] G. McGraw etE. W. Felten,SecuringJava: GettingDownto BusinessWith MobileCode, chapitre2, JohnWiley & Sons,1999.

[McKusick96] M. K. McKusick,K. Bostic,M. J.Karels,et J.S.Quarterman,TheDesignandImplementationof the4.4BSDOperatingSystem,Addison–Wesley PublishingCompany, Inc.,1996.

[Meeks99a] B. MeeksetA. Boyle, WhiteHouseWebsiteshutdown, MSNBC,12mai1999,Disponiblesurle web,URL="http ://www.zdnet.com/zdnn/stories /0,45 86,2 25778 4,00 .html ".

[Meeks99b] B. Meeks,A. Boyle, etB. Sullivan,Hackattackknocksout FBI site,MSNBC,26mai1999,Disponiblesurle web,URL="http ://www.zdnet.com/zdnn/stories/0,4586 ,22666 48,00 .html ".

[Monson-Haefel99]R. Monson-Haefel,EnterpriseJavabeans, O’Reilly & Associates,juin1999.

[Murray93a] K. Murray, T. Stiermerling,T. Wilkinson,etP. Kelly, Angel : ResourceUnificationin a64–bitMicro–Kernel,dansProceedingsof th 27thHawaii InternationalConferenceonSystemScience, septembre1993.

[Murray93b] K. Murray, T. Wilkinson,P. Osmon,A. Saulsbury, T. Stiermerling,etP. Kelly, DesignandImplementationof anObject–Orientated64–bitSingleAddressSpaceMicrokernel,dans2ndUSENIXSymposiumonMicrokernelsandotherKernelArchitectures, 1993.

[Needham78] R. M. NeedhametM. D. Schroeder, UsingEncryptionfor Authenticationin LargeNetworksof Computers,Communicationsof theACM, 21,no.12 :993–999,Décembre1978.

[Needham77] R. M. NeeedhametR. D. H. Walker, TheCambridgeCAPComputerandits protectionsystem,dansProceedingsof the6thACM SymposiumonOperatingSystemsPrinciples(SOSP), pages1–10,novembre1977.

[Neumann77] P. G. Neumann,R. S.Boyer, R. J.Feiertag,K. N. Levitt, et L. Robinson,A ProvablySecureOperatingSystem: TheSystem,its Applications,andProofs,Rapporttechnique,SRI International,février1977.

[Nicomette96] V. Nicomette,La protectiondanslessystèmesà objetsrépartis, Ph.D.thesis,InstitutNationalPolytechniquedeToulouse,1996.

[Omang98] K. Omang,Performanceof aClusterof PCIbasedUltraSparcWorkstationsInterconnectedwith SCI,dansSpringerVerlag,éditeur,Proceedingsof Network–BasedParallel Computing, Communication,Architecture, andApplications(CANPC’98), volume1362deLectureNotesin ComputerScience, pages232–246,janvier 1998.

180 BIBLIOGRAPHIE

[OMG98] CORBAservices: CommonObjectSercicesSpecification, chapitreSecurityServiceSpecification,ObjectManagementGroup,décembre1998,Disponiblesurle web:URL="http ://www.omg.org/homepages/secs ig/se crtf .html ".

[Rivest98] R. L. Rivest,ChaffingandWinnowing: ConfidentialitywithoutEncryption, MIT Lab for ComputerScience,avril 1998,PubliésurleWeb,URL="http ://theory.lcs.mit.edu/ rivest/chaffing.txt ".

[Rivest78] R. L. Rivest,A. Shamir, etL. Adleman,OnaMethodfor ObtainingDigital SignaturesandPublicKey Cryptosystems,CommunicationsoftheACM, 21,no.2 :120–126,fevrier 1978.

[Sandberg85] R. Sandberg, D. Goldberg, K. S,D. Walsh,etB. Lyon,DesignandImplementationof theSunNetwork File System,dansProceedingsof theSummer1985USENIXConference, pages119–130,Portland,Oregon,États–Unis,juin 1985.

[Sandhu96] R. Sandhu,AccessControl: TheNeglectedFrontier, dansProceedingsoftheFirstAustralasianConferenceon InformationSecurityandPrivacy,Wollongong,Australia,juin 1996.

[Sandhu93] R. S.Sandhu,Lattice–BasedAccessControlModels,IEEEComputer,26,no.11 :9–19,novembre1993.

[Satyanarayanan85]M. Satyanarayanan,J.H. Howard,D. A. Nicols,R. N. Sidebotham,A. Z.Spector, etM. J.West,TheITC DistributedFile System: PrinciplesandDesign,dansProceedingsof the10thACM SymposiumonOperatingSystemsPrinciples, pages35–50,1985.

[Saunier96] F. Saunier, Protectiond’unemémoirevirtuelle répartiepar capacitésimplicites, Ph.D.thesis,InstitutNationalPolytechniquedeGrenoble,1996.

[Saunier95] F. Saunier, ServicedeProtectiond’uneMémoireVirtuelleRépartie,dansJournéedesJeunesChercheurs,RéseauDoctoral enArchitecturedesSystèmesetdesMachinesInformatiques, Rennes,octobre1995,IRISA.

[Schneier96] B. Schneier, AppliedCryptography, JohnWiley & Sons,Inc.,deuxièmeedition,1996.

[Schnorr91] C. P. Schnorr, EfficientSignatureGenerationfor SmartCards,JournalofCryptology, 4, no.3 :161–174,1991.

[SCSSI94] S.C. dela Sécuritédessystèmesd’Information(S.C.S.S.I.),La ménaceet lesattaquesinformatiques, numéro650dansDISSI/SCSSI,RépubliqueFrançaise,premierministre,mars1994.

[SCSSI93] S.C. dela Sécuritédessystèmesd’Information(S.C.S.S.I.),Protectiondesinformationssensiblesnerelevantpasdusecretdedéfense.Recommandationspour lespostesdetravail informatiques, numéro600dansDISSI/SCSSI,RépubliqueFrançaise,premierministre,Secrétariatgénéraldela défensenationale,1993.

BIBLIOGRAPHIE 181

[SCSSI91a] S.C. dela Sécuritédessystèmesd’Information(S.C.S.S.I.),Fiched’expressionrationelledesobjectifsdesécuritédessystèmesd’information, numéro150dansDISSI/SCSSI,RépubliqueFrançaise,premierministre,février1991.

[SCSSI91b] S.C. dela Sécuritédessystèmesd’Information(S.C.S.S.I.),Recommandationsd’installationdessitesetsystèmesdesinformationssensiblesnerelevantpasdusecretdedéfenseprotectiondesinformationssensiblescontre lessignauxcompromettants, numéro400dansDISSI/SCSSI,RépubliqueFrançaise,premierministre,octobre1991.

[Shapiro99] J.S.Shapiro,EROS: A CapabilitySystem, Ph.D.thesis,UniversitédePennsylvanie,1999.

[Shapiro86] M. Shapiro,StructureandEncapsulationin DistributedSystems: TheProxyPrinciple,dansProceedingsof the6th InternationalConferenceonDistributedComputingSystems, pages198–204,Cambridge,Massachusetts,États–Unis,juin 1986.

[Snyder81] L. Snyder, FormalModelsof Capability–BasedProtectionSystems,IEEETransactionsonComputers, C–30,no.3 :172–181,mars1981.

[Soinne98] F. Soinne,SecurWareNetwall Version3.3,Rapporttechnique,Bull, juin1998,Disponiblesurle web,URL="http ://www-frec.bull.fr/OSBU2_0/w p_net wall .htm ".

[Spector89] A. Z. SpectoretM. L. Kazar, WideAreaFile ServicesandtheAFSExperimentalSystem,Unix Review, 7, no.3, 1989.

[NBS94] N. B. of Standards,Digital SignatureStandard, numéro186dansNBSFIPSPUB,U. S.Departmentof Commerce,mai1994.

[NBS77] N. B. of Standards,DataEncryptionStandard, numéro46dansNBSFIPSPUB,U. S.Departmentof Commerce,janvier 1977.

[Steiner88] J.G. Steiner, B. C. Neuman,et J. I. Schiller, Kerberos: AnAuthenticationServicefor OpenNetwork Systems,dansUSENIXConferenceProceedings, pages191–202,février1988.

[Stoll89] C. Stoll, Lenid ducoucou, Albin–Michel, 1989,Titre original : “TheCuckoo’sEgg”.

[Sun89] SunMicrosystemsInc.,NFS: Network File SystemProtocolSpecification,Requestfor Comments(RFC)1094,Network WorkingGroup,mars1989.

[Tanenbaum90] A. S.Tanenbaum,R. vanRenesse,H. vanStaveren,G. J.Sharp,S.J.Mullender, A. J.Jansen,etG. vanRossum,Experienceswith theAmoebaDistributedOperatingSystem,Communicationsof theACM, 33,no.12 :46–63,décembre1990.

[Tanenbaum86] A. S.Tanenbaum,S.J.Mullender, etR. vanRenesse,UsingSparseCapabilitiesin aDistributedOperatingSystem,dansProceedingsof the6th InternationalConferencein ComputingSystems, pages558–563,juin1986.

182 BIBLIOGRAPHIE

[Thomas94] R. K. ThomasetR. S.Sandhu,ConceptualFoundationfor aModelofTask-basedAuthorisations,dansProceedingsof the7th IEEEComputerSecurityFoundationsWorkshop, pages66–79,Franconia,New Hampshire,États–Unis,juin 1994.

[Thompson74] K. ThompsonetD. M. Richie,TheUNIX TimesharingSystem,Communicationsof theACM, 17,no.7 :365–375,juillet 1974.

[Tock94] T. D. Tock,AnExtensibleFrameworkfor AuthenticationandDelegation,Master’s thesis,Universityof Illinois atUrbana–Champaign,1994.

[Tullman98] P. TullmanetJ.Lepreau,NestedJavaProcesses: OSStructurefor Mobilecode,dansProceedingsof the8thACM SIGOPSEuropeanworkshop,pages111–117,Sintra,Portugal,septembre1998.

[STREAMS90] UNIX SoftwareOperation,UNIX SYSTEMV RELEASE4 ProgrammersGuide: STREAMS, Prentice-Hall,Inc.,1990.

[Vochteloo98] J.Vochteloo,Design,ImplementationandPerformanceof ProtectionintheMungiSingleAddressSpaceOperatingSystem, Ph.D.thesis,Universityof New SouthWales,juin 1998.

[Vochteloo96] J.Vochteloo,K. Elphinstone,S.Russel,etG. Heiser, ProtectionDomainExtensionsin Mungi, dansProceedingsof the5th IWOOS, pages161–165,Seattle,WA, USA, octobre1996.

[Vochteloo93] J.Vochteloo,S.Russel,etG. Heiser, Capability–BasedProtectionin theMungi OperatingSystem,dansProceedingsof the3rd IWOOS, pages108–115,Asheville, NC, USA, Décembre1993,A versionof thisarticleis availableasTechnicalReportnumberSCS&E9309fromtheUniversityof New SouthWales,March, 1993.

[vonEicken99] T. vonEicken,C.-C.Chang,G. Czajkowski, C. Hawblitzel, D. Hu, etD. Spoonhower, J–Kernel: A Capability–BasedOperatingSystemforJava,dansJ.Vitek etC. Jensen,éditeurs,Secure InternetProgramming,numéro1603dansLectureNotesin ComputerScience,pages369–394,SpringerVerlag,juin 1999.

[Wahbe93] R. Wahbe,S.Lucco,T. E. Anderson,etS.L. Graham,EfficientSoftware–BasedFault Isolation,dansProceedingsof the14thACMSymposiumonOperatingSystemPrinciples(SOSP’93), pages203–216,Décembre1993.

[Wassenaar95] TheWassenaarArrangementonExportControls for ConventionalArmsandDual–UseGoodsandTechnologies, Secretariatof TheWassenaarArrangement,Vienna,Austria,décembre1995.

[Weissman69] C. Weissman,SecurityControlsin theADEPT–50TimeSharingSystem,dansProceedingsof AFIPSFall Joint ComputerConference, volume35,pages119–135,Arlington, Virginia,États–Unis,1969,AFIPSPress.

[Wilkinson95] T. WilkinsonetK. Murray, Extensible,flexible andsecureservicesinAngel,asingleaddressspaceoperatingsystem,dansProceedingsof the1stInternationalConferenceonParallel ArchitecturesandAlgorithms,avril 1995.

BIBLIOGRAPHIE 183

[Wobber94] E. Wobber, M. Abadi,M. Burrows,etB. Lampson,Authenticationin theTaosOperatingSystem,ACM TransactionsonComputerSystems, 12,no.1 :3–32,février1994.

[Wulf81] W. Wulf, R. Levin, etS.P. Harbinson,HYDRA/C.mmp: AnExperimentalComputerSystem, McGraw–Hill, 1981.

[Zhou91] S.Zhou,X. Zheng,J.Wang,etP. Delisle,Utopia: A loadsharingsystemfor large,heterogeneousdistributedcomputersystems,CSRITechnicalReport257,Universityof Toronto,1991.

[Zimmermann95] P. R. Zimmermann,TheOfficial PGPUser’sGuide, MIT Press,1995.

184 BIBLIOGRAPHIE

Résumé

Un systèmeàmémoirevirtuelle répartieuniquepermetl’utilisation desadressesvirtuellescommeidentificateursglobauxuniques.Il fautdoncséparerla résolutiondesadresseset lecontrôled’accès,parcequ’uneadressevirtuelleestpotentiellementvisiblepartouteapplicationdansle système.

Nousproposonsunmodèledecontrôled’accèspourunemémoirevirtuelle répartieuniquequi sebasesurle modèleàcapacitéscachées.Le modèlesebasesurlesnotionssuivantes: lacapacité(undroit d’accèssimple),le domainedeprotection(définit le contextedeprotectionparl’ensembledescapacitésdisponiblesdansle domaine)et l’appeldechangementdedomaine(qui permetd’appeleruneprocéduredésignéedansunautredomainedeprotection).Deuxprincipesdebasesonttrèsimportantspourle modèle: l’utilisation descapacitésconfinéeset la délégationcontrôléeà traversdesinterfacesdeprotection.Lesinterfacesdeprotectionpermettentuneséparationentrela spécificationdela protectionet le codedel’application.L’évaluationdenotremodèleindiquequ’il permetderéaliserla plupartdesmodèlesdecontrôled’accèsexistantsy comprisle modèlemandatairedeBell & LaPadula.

Le modèleà capacitéscachéesaétéréalisédansArias,unemémoirevirtuelle répartieuniqueconçueetdéveloppéeauseinduprojetSIRAC. Lesexpériencesaveccetteréalisationmontrentquela séparationentrela spécificationdela protectionet le codedel’applicationfacilite la réutilisationlogicielleet l’évolutiondel’application.L’efficacitéd’un appeldechangementdedomainecorrespondà celuid’un appelRPCstandard.

Abstract

SingleAddressSpaceOperatingSystemsallow virtual addressesto beusedby applicationsasgloballyuniquereferences.Thismeansthataddressresolutionandaccesscontrolhave to beseparatedbecausevirtual addressescanbereferencedby all applicationsonall nodesin thesystem.

Weproposeanaccesscontrolmodelfor aSingleAddressSpaceOperatingSystembasedonHiddenSoftwareCapabilities.Themodelis basedon thenotionsof capabilities(elementalaccessrights),protectiondomains(containersfor accessrights)andcrossdomaincalls(allowtheflow of controlto changefrom oneprotectiondomainto another).Themodelbuildson twoimportantprinciples: segregatedcapabilitiesandthecontroleddelegationof capabilitiesthroughprotectioninterfaces.Applicationcodeandprotectioninterfacesaredefinedseparately. Theevaluationof thismodelindicatesthatthemajorityof existingaccesscontrolmodels,includingthemandatorymodelproposedby Bell & LaPadula,canbebasedonHiddenSoftwareCapabilities.

TheHiddenSoftwareCapabilitymodelhasbeenimplementedin theAriasSingleAddressSpaceOperatingSystem.Experiencewith this implementation,shows thatseparationofprotectiondefinitionandapplicationcodefacilitatessoftwarereuseandevolutionofapplications.Theperformanceof theimplementedcrossdomaincall is roughlyequivalentto astandardRPC.

un modèle de contrôle d'accès générique et sa réalisation

Documents