Thèse BOURICHE Khalid

______________________________________________________________________________
Gestion de l'incertitude et
codage des politiques de scurit
dans les systmes decontrle
daccs
THSE
Doctorat
de lUniversit dArtois
et
de lUniversit Sidi Mohammed Ben Abdellah
Spcialit Informatique
par
Khalid BOURICHE
Composition du jury
Directeurs de thse :
Rapporteurs :
Examinateurs :
Invit :
Salem Benferhat, Professeur, Universit dArtois, France

Mohamed Ouzaref, Professeur, FST de Fs - Universit USMBA,
Maroc
Zied Elouedi, Professeur, ISG Tunis - Universit de Tunis, Tunisie
Stphane Loiseau, Professeur, Universit dAngers, France
Mohammed Meknassi, Professeur, Facult des sciences Dhar El
Mahraz de Fs - Universit USMBA, Maroc
Hussain Benazza, Professeur, ENSAM de Mekns -Universit
Moulay Ismail, Maroc
Mohammed Boulmalf, Professeur, UIR de Rabat, Maroc
________________________________________________________
Centre de Recherche en Informatique de Lens CNRS UMR 8188

Universit dArtois, rue Jean Souvraz, S.P. 18 F-62307, Lens Cedex France
Secrtariat : Tel.: +33 (0)3 21 79 17 23 Fax : +33 (0)3 21 79 17 70
http://www.cril.fr
*-*-*-*
Facult des Sciences et Techniques Fs
B.P. 2202, Route dImouzzer FES
_ 212 (35) 60 80 14 212 (35) 60 96 35 _ 212 (35) 60 82 14
www.fst-usmba.ac.ma
Rsum de la thse
Le travail de cette thse se situe lintersection du domaine de lintelligence

artificielle et du domaine de la scurit informatique. Cette thse a deux
objectifs principaux : le premier est de confirmer la puissance expressive du modle
OrBAC, en particulier par rapport aux politiques de scurit par dfaut utilises dans
SELinux. Le deuxime objectif est dtendre ce modle OrBAC, en intgrant le concept
de priorit qui sera reprsent dans le cadre de la thorie des possibilits.
Dans la premire partie de la thse, nous passons en revue et analysons les
diffrents modles du contrle daccs existants, y compris ceux utiliss dans les
systmes SELinux. En particulier, nous prsentons le modle OrBAC qui offre une
reprsentation compacte et flexible des politiques de scurit.
Dans la deuxime partie de la thse, nous proposons une modlisation des
politiques de scurit par dfaut, utilises par SELinux, dans le modle OrBAC. Nous
montrons que chaque concept utilis dans la politique de scurit SELinux (type, rle,
etc.) possde une contrepartie naturelle dans le modle OrBAC. Cette modlisation,
illustr sur la distribution Selinux Fedora 14, confirme la puissance expressive du modle
de contrle daccs OrBAC. Nous proposons galement la reprsentation et la gestion des
rgles de transition des politiques de scurit SELinux dans le modle OrBAC.
Dans la troisime et dernire partie de la thse, nous nous intressons la gestion
de lincertitude dans les modles de contrle daccs. Nous avons utilis la thorie des
possibilits qui offre un cadre naturel, qualitatif et ordinal pour reprsenter et raisonner
avec les rgles incertaines. Nous proposons une extension du modle OrBAC en y
introduisant une entit appele priorit au niveau de chaque relation. Lentit priorit
quantifie la certitude quune relation, entre une entit concrte et une entit abstraite, soit
ralise. Plusieurs modes de combinaison (pessimiste, optimiste et avanc) sont proposs
pour dterminer la valeur de la priorit de chaque relation concrte partir des priorits
des relations abstraites correspondantes.
Remerciements
Ce travail de recherche sinscrit dans le cadre dune thse en cotutelle entre luniversit
dArtois (Lens/France) et luniversit Sidi Mohammed Ben Abdellah (Fs/Maroc).
En prambule cette thse, je tiens tout dabord exprimer ma vive reconnaissance
envers Monsieur Salem BENFERHAT, mon codirecteur de thse ct franais, qui ma
accompagn tout au long de la ralisation de ce travail. Il a consacr de son prcieux temps en
maccueillant en France et en se dplaant au Maroc et en me prodiguant dutiles conseils qui
mont normment aid bien raliser et structurer mon travail. Au cours de mes moments
difficiles, il a fait preuve dune grande disponibilit ainsi quune haute qualit de ses
interventions et secours, et sans qui cette thse ne serait pas ce quelle est. Merci infiniment
Monsieur Salem BENFERHAT, votre rigueur au travail serait un exemple pour moi. Toute ma
reconnaissance et ma gratitude pour laboutissement de plus de trois ans de travail sous votre
direction clairvoyante. Je te souhaite une trs bonne sant.
Je tiens remercier sincrement Monsieur Mohamed OUZARF, qui, en tant que
codirecteur de thse ct marocain, s'est toujours montr l'coute et trs collaboratif tout au
long de la ralisation de cette thse, ainsi pour l'aide et le temps qu'il a bien voulu me consacrer
notamment sur le plan administratif. Monsieur Mohamed OUZARF ma encadr au cours des
travaux de mmoire du DESA-ATNASI, cest un grand honneur pour moi que j'aie eu loccasion
de le voir en tant que codirecteur de mes travaux de recherche.
Jexprime toute ma gratitude Monsieur, Professeur , pour mavoir fait le privilge de
prsider le jury lors de ma soutenance de thse.
Que Monsieur Zied Elouedi Professeur lISG Universit de Tunis, et Monsieur Stphane
Loiseau Professeur l'Universit dAngers, trouvent ici lexpression de mes sincres
remerciements davoir accept dvaluer ce travail.
Jadresse mes vifs remerciements Monsieur Mohammed MEKNASSI professeur la
facult des sciences Dhar El Mahraz de Fs et Monsieur Hussain BENAZZA professeur
lENSAM de Mekns et lun de mes anciens professeurs la FST de Fs. Je suis trs
reconnaissant quils aient accept (respectivement) de rapporter et dexaminer ma thse.
Mes remerciements vont encore Mohammed BOULMALEF professeur lUniversit
Internationale de Rabat qui a rapidement accept dtre parmi le jury, sa prsence entre nous
honorera sans doute la sance. Un grand merci Monsieur Mohammed BOULMALEF.
4
Puis un grand merci M'hammed BOULAGOUAZ, Professeur de l'Enseignement

Suprieur des Mathmatiques la Facult des Sciences et Techniques de Fs, qui, non seulement
a t lun de mes premiers professeurs la FST de Fs et responsable du DESA-ATNASI, mais
encore a t la personne qui ma bien orient et ma aid inconditionnellement et qui, grce lui
que le contrat de cotutelle ait tabli. Merci Monsieur M'hammed BOULAGOUAZ, cest un
honneur que vous soyez parmi le jury.
Je tiens mentionner le plaisir immense que j'ai eu tudier, dans le cadre du diplme de
DESA la FST de Fs et puis loccasion inespre qui ma t offerte pour prparer ma prsente
thse de doctorat dans le cadre dun contrat de cotutelle.
Je remercie particulirement le doyen de la facult de Fs, ses collaborateurs directs, ainsi
que tout le personnel administratif.
Je souhaite adresser mes remerciements les plus sincres tous ceux qui m'ont apport
leur aide et qui ont contribu de prs ou de loin l'laboration de ce travail.
Il y a des personnes de trs grande importance dans ma vie, il sagit de ma femme
Rachida, mon fils Achraf Ali et mes merveilleuses et jolies fillettes Oumama et Wissal. Ils mont
accompagn et mont donn la force, lnergie et lespoir pour accomplir ce travail. Sans oublier
mes parents Lahcen et Fatima pour leurs encouragements continus.
Mes remerciements vont aussi tous mes amis, quils soient au Maroc, en France ou
Qubec, et je sais quils sont nombreux. Vous mavez solidement tous soutenu par votre
encouragement, Je cite au passage : Saidi Rachid, BENNANI Mohamed Ali, Said Zahnoune,
Stitou Mohamed, Rachid Chaib, Zeglama Said, EL Gaouzi Khalid, Youssef Selmouni Zerhouni
et Chafik Hadigui. Tous ceux qui restent dont les noms ne figurent pas sur cette liste et qui mont
soutenu dune manire ou dune autre sachent que leur apport moral na pas t sous-estim. Je
vous adresse tous mes sentiments de reconnaissance renouvele. Je dirais donc tout le monde
que mes amis constituent ma grande force de russite.
Enfin et surtout, un grand merci ALLAH qui m'a toujours aid.
Table des matires

INTRODUCTION .......................................................................................................................... 9
PLAN DU MEMOIRE ................................................................................................................. 13
CHAPITRE 1 ................................................................................................................................ 15
MODELES ET POLITIQUES DE CONTROLE D'ACCES................................................... 15
1.1.
1.2.
1.3.
1.3.1.
1.3.2.
1.3.3.
1.4.
INTRODUCTION ................................................................................................................. 15
POLITIQUE DE SECURITE ................................................................................................... 16
LES POLITIQUES ET LES MODELES DE CONTROLE DACCES ................................................ 17
CONTROLE DACCES DISCRETIONNAIRE (DAC) ............................................................ 17
CONTROLE DACCES MANDATAIRE (MAC) ................................................................... 21
LE CONTROLE D'ACCES BASE SUR LES ROLES (RBAC) .................................................. 31
CONCLUSION .................................................................................................................... 39
CHAPITRE 2 ................................................................................................................................ 41
LA SOLUTION DE SECURITE SELINUX ............................................................................. 41
2.1. INTRODUCTION ................................................................................................................. 41
2.2. SELINUX ........................................................................................................................... 41
2.2.1. HISTORIQUE DE SELINUX ............................................................................................. 41
2.2.2. ARCHITECTURE DE SELINUX ........................................................................................ 42
2.2.3. LES AUTRES SOLUTIONS DE SECURITE ........................................................................... 45
2.3. LE MODELE DE SECURITE DE SELINUX .............................................................................. 45
2.3.1. LE MODELE TYPE ENFORCEMENT (TE) ......................................................................... 46
2.3.2. LE MODLE ROLE-BASED ACCESS CONTROL (RBAC) ................................................. 49
2.3.3. LES MODELES MCS ET MLS DE BELL-LAPADULA ........................................................ 49
2.4. LA POLITIQUE DE SECURITE SELINUX ............................................................................... 50
2.4.1. CONTEXTE DE SECURITE ............................................................................................... 50
2.4.2. FICHIERS ET REPERTOIRES LIES A LA POLITIQUE DE SECURITE ....................................... 53
2.4.3. TIQUETAGE DU SYSTEME AU DEMARRAGE .................................................................. 54
2.4.4. SYSTEMES DE FICHIERS ET ATTRIBUTS ETENDUS. .......................................................... 55
2.4.5. REGLES DU MODELE TE ............................................................................................... 56
2.5. MISE AU POINT SUR LES TRAVAUX DE RECHERCHE UTILISANT LES MODELES DE CONTROLE
D'ACCES DANS SELINUX ............................................................................................................... 61
2.5.1. LE MODELE RBAC DANS SELINUX. ............................................................................. 61
2.5.2. LE MODELE TYPE ENFORCEMENT ................................................................................. 62
2.5.3. LE MODELE RSBAC DANS LINUX ................................................................................. 64
2.5.4. LE MODLE MLS (MULTI-LEVEL SECURITY) ............................................................... 64
2.5.5. LE MODLE MCS (MULTICATEGORY SECURITY) ....................................................... 64
2.6. CONCLUSION ..................................................................................................................... 64
CHAPITRE 3 ................................................................................................................................ 66
LES MODELES DE CONTROLE D'ACCES BASES SUR

L'ORGANISATION
(ORBAC)........................................................................................................................................ 66
3.1.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.3.
3.3.1.
3.3.2.
3.3.3.
3.4.
3.5.
3.5.1.
3.5.2.
3.5.3.
3.5.4.
3.6.
3.7.
3.7.1.
3.7.2.
3.8.
INTRODUCTION ................................................................................................................. 66
LEMENTS D'ORBAC ........................................................................................................ 66
NIVEAU ABSTRAIT......................................................................................................... 67
ROLE ............................................................................................................................. 68
VUE .............................................................................................................................. 68
ACTIVITE ...................................................................................................................... 68
CONTEXTE .................................................................................................................... 69
NIVEAU CONCRET ......................................................................................................... 71
RELATIONS ENTRE LES ENTITES ABSTRAITES ET LES ENTITES CONCRETES ........................ 73
RELATION EMPOWER .................................................................................................... 73
RELATION USE .............................................................................................................. 74
RELATION CONSIDER .................................................................................................... 74
LANGAGE DE FORMALISME DU MODELE ORBAC .............................................................. 75
HIERARCHIES DANS ORBAC ............................................................................................. 75
HIERARCHIE DES ROLES ................................................................................................ 75
HIERARCHIE DES ACTIVITES .......................................................................................... 76
HIERARCHIE DES VUES .................................................................................................. 76
HIERARCHIE DES ORGANISATIONS................................................................................. 77
CONTRAINTES ................................................................................................................... 78
MOTORBAC ...................................................................................................................... 79
HISTORIQUE ET ARCHITECTURE DE MOTORBAC .......................................................... 79
MODULES DE MOTORBAC ........................................................................................... 80
CONCLUSION .................................................................................................................... 85
CHAPITRE 4 ................................................................................................................................ 86
CODAGE EN MODELE ORBAC DE LA POLITIQUE DE SECURITE PAR DEFAUT DE
SELINUX....................................................................................................................................... 86
4.1.
4.2.
4.2.1.
4.2.2.
4.2.3.
4.3.
4.4.
4.4.1.
4.4.2.
4.4.3.
4.4.4.
4.4.5.
4.5.
4.6.
INTRODUCTION ................................................................................................................. 86
FICHIERS ET REPERTOIRES LIES A LA POLITIQUE DE SECURITE DEFAUT ............................. 87
LE FICHIER DE CONFIGURATION DE LA POLITIQUE DE SECURITE PAR DEFAUT ................ 87
CONTEXTE DE CONNEXION PAR DEFAUT ASSOCIES AUX UTILISATEURS ......................... 88
CONTEXTE PAR DEFAUT ASSOCIE AUX FICHIERS ET REPERTOIRES ................................. 88
PARAMETRES DE LA POLITIQUE DE SECURITE SELINUX ..................................................... 90
ENCODAGE EN MODELE ORBAC DE LA POLITIQUE DE SECURITE DEFAUT SELINUX .......... 91
LES ENTITES DE LA RELATION EMPLOY ......................................................................... 91
LA RELATION CONSIDER ............................................................................................... 93
LA RELATION USES ....................................................................................................... 93
LA RELATION ABSTRAITE : PERMISSION ........................................................................ 94
LA RELATION CONCRETE IS_PERMITTED ....................................................................... 96
EXEMPLE DILLUSTRATION............................................................................................... 97
CONCLUSION .................................................................................................................. 101
7
CHAPITRE 5 .............................................................................................................................. 102

CODAGE DES REGLES DE TRANSITION SELINUX
EN MODELE ORBAC
...................................................................................................................................................... 102
5.1. INTRODUCTION ............................................................................................................... 102
5.2. TRANSITION DE TYPES EN SELINUX ................................................................................ 102
5.2.1. SPECIFICATION DUN TYPE PAR DEFAUT POUR UN NOUVEL OBJET ............................... 103
5.2.2. SPECIFICATION DUN DOMAINE PAR DEFAUT POUR UN NOUVEAU PROCESSUS ............. 105
5.3. CONCLUSION .................................................................................................................. 111
CHAPITRE 6 .............................................................................................................................. 112
GESTION POSSIBILISTE DES PRIORITES DANS LES MODELES DE CONTROLE
D'ACCES. ................................................................................................................................... 112
6.1.
6.2.
6.2.1.
6.2.2.
6.3.
6.3.1.
6.3.2.
6.3.3.
6.3.4.
6.3.5.
6.4.
6.4.1.
6.4.2.
6.4.3.
6.5.
6.6.
INTRODUCTION ............................................................................................................... 112

LA LOGIQUE POSSIBILISTE .............................................................................................. 113
DISTRIBUTIONS DE POSSIBILITES ................................................................................. 113
BASES POSSIBILISTES .................................................................................................. 114
AJOUT DES PRIORITES AU MODELE ORBAC .................................................................... 118
ORGANISATION ........................................................................................................... 118
SUJETS ET ROLES ......................................................................................................... 118
OBJETS ET VUES .......................................................................................................... 119
LES ACTIONS ET ACTIVITES ......................................................................................... 119
CONTEXTES................................................................................................................. 120
PRIORISER LES AUTORISATIONS ABSTRAITES ET CONCRETES. ......................................... 120
MODE DE COMBINAISON PESSIMISTE: .......................................................................... 122
MODE DE COMBINAISON OPTIMISTE: ........................................................................... 122
MODE DE COMBINAISON ACTUALISE .......................................................................... 122
EXEMPLE DILLUSTRATION ............................................................................................. 123
CONCLUSION .................................................................................................................. 126
CHAPITRE 7 .............................................................................................................................. 127

IMPLEMENTATION ................................................................................................................ 127
7.1. INTRODUCTION ............................................................................................................... 127
7.2. LE MCD DES ELEMENTS SELINUX .................................................................................. 128
7.3. PRESENTATION DE LAPPLICATION ................................................................................. 134
7.3.1. LA PAGE D'ACCUEIL .................................................................................................... 134
CONCLUSION ET PERSPECTIVES .................................................................................... 147
BIBLIOGRAPHIE ..................................................................................................................... 153
INTRODUCTION
Le systme dinformation (SI) et les donnes sensibles dune organisation, reprsentent son
capital essentiel, quil convient de protger contre les accs non autoriss. Les spcialistes de
scurit des systmes dinformation (SSI) sont confronts des enjeux de scurit. Ils doivent,
la fois, avoir une approche globale du SI et une connaissance approfondie du systme
dexploitation ainsi que les applications installes.
En effet, plusieurs possibilits de technique sont offertes aujourdhui laide de la
gnralisation de la connexion Internet, lutilisation intensive des systmes et applicatifs
communicants et la complexit des architectures. Ces possibilits introduisent aussi des risques
comme le cas o des utilisateurs portent atteinte lintgrit du systme en se comportant dune
manire insouciante suite des manipulations gnralement involontaires, risque et qui peuvent
favoriser le danger, cette catgorie des utilisateurs est lorigine de la majorit des problmes lis
la scurit d'un systme d'information (SSI), en plus on trouve le cas des personnes
malintentionnes qui arrivent sinfiltrer en exploitant une vulnrabilit du systme pour
semparer dinformations sensibles aux quelles elle ne sont pas censes avoir accs. Un autre cas
frquent concerne les programmes malveillants (les virus, chevaux de Troie, etc.) qui sont
dvelopps pour nuire un systme, voire mme modifier ou collecter ses donnes pour les
rutiliser des fins malveillantes.
Dune manire gnrale, La SSI consiste assurer lunique utilisation des ressources
systmes d'une organisation dans le cadre prvu. Elle est value par plusieurs proprits et
exigences de scurit, ce sont des caractristiques critiques des ressources, savoir :
la disponibilit : L'objectif de la disponibilit est de garantir l'accs un service ou des

ressources au moment voulu par les personnes autorises. Elle permet de maintenir le bon
fonctionnement du systme d'information ;
Lintgrit : Lintgrit est la prvention dune modification non autorise de

linformation norme ISO 7498-2 (ISO90).
La confidentialit : La confidentialit est la proprit quune information nest ni

disponible ni divulgue aux personnes, composantes ou processus non autoriss norme
ISO 7498-2 (ISO90).
9
La non rpudiation : permet dassurer qu'une personne ne puisse nier avoir effectu une
transaction;
L'authentification : consiste assurer l'identification de l'origine de l'information et que

seules les personnes autorises aient accs aux ressources;
D'autres caractristiques sont galement utilises peuvent sajouter celles prcites, tels
que :
Lautorisation : concerne le type d'activits ou d'informations qu'une personne est

autorise effectuer ou y accder;
La traabilit : garantit que les accs et tentatives d'accs aux lments considrs sont
audits et que ces traces sont conserves dans des journaux exploitables.
Ces critres sont gnralement assurs par des techniques et mcanismes qui portent
essentiellement sur divers aspects tels que :
La scurit des rseaux : utilise principalement les pare-feu[1]qui permettent de surveiller et

de restreindre les accs entre deux rseaux (LAN1, WAN2, etc.), les pare-feu comportent des
fonctions de filtrage qui ne laissent passer que les paquets en provenance des adresses
(IP+numro de port) autorises, et se proccupent le plus souvent de la rsolution des
problmes de confidentialit et d'intgrit des donnes qui transitent. Dans ce contexte, le
rseau est considr comme un mdium non sr dans lequel des personnes malveillantes sont
susceptibles de lire, modifier et supprimer les donnes qu'il achemine.
La dtection dintrusions : utilise des outils qui compltent les fonctions du pare-feu en
reprant, dune part les intrus sur les ports laisss ouverts et dautre part les requtes
malintentionnes. il existe deux types de systme de dtections dintrusions (ou IDS pour
Intrusion Dtection System) : les IDS bass rseau et les IDS bass hte. Ces deux catgories
d'IDS emploient gnralement deux principes de dtection savoir l'approche
comportementale (ou dtection d'anomalies) et l'approche base sur la connaissance (ou la
dtection de scnarios d'attaque).
La cryptographie, considre comme la science du secret puisquelle permet l'anonymisation

des informations. Selon la nature de linformation protger, le recours la cryptographie a
donn lieu de multiples usages et applications. Les concepts de la cryptographie ont t
labors pour permettre la mise au point, puis la mise en uvre dun certain nombre de
(Local Area Networden anglais) : Rseau local.

(Wide Area Networden anglais) : Rseau tendu.
10
mcanismes spcialiss. do la prsence de la cryptographie cl secrte, standard de

chiffrement AES, systmes cryptographiques cl publique (RSA, El Gamal, ECC, etc.), des
codes dauthentification, des systmes de partage de secret, des procds didentification, des
signatures numriques et de cryptographie dynamique et autant de domaines, de spcialistes
et dusages.
Le contrle daccs : consiste vrifier si un sujet (utilisateur, processus, etc.) demandant

d'accder une ressource (fichier, mmoire, etc.) possde suffisamment le droit pour le faire.
Le contrle daccs est bas sur une politique de contrle daccs qui est spcialise pour la
gestion des permissions [2].La politique de contrle daccs est structure selon un modle
qui est responsable de la prise de dcision (accord ou refus) dune demande daccs. Les
modles traditionnels de contrle daccs sont : le contrle daccs par mandat (Mandatory
Access Control - MAC)[3], le contrle daccs discrtionnaire (Discretionary Access Control
- DAC) [4]. MAC est un mcanisme de contrle daccs bas sur ltiquetage (exemple : Top
Secret, Secret, Unclassified) des diffrentes entits (sujets et objets) du systme. DAC est un
mcanisme dcentralis bas sur lutilisateur dans lequel le crateur dune donne possde la
pleine discrtion de dfinir les autorisations. En 2003, Ferraiolo et al. ont propos le modle
de contrle daccs bass sur les rles (Rle-Based Access Control - RBAC)[5][6][7], une
politique RBAC est, dune part un ensemble daffectation des utilisateurs des rles et
dautre part un ensemble dattributions des permissions ces des rles et par la suite, une
demande daccs dun sujet une ressource est accorde sil joue un rle auquel est associ
ce privilge. Plusieurs modles se sont inspirs de RBAC pour, soit organiser des politiques
au moyen de concepts supplmentaires (par exemple, quipe, tche, organisation) pour
amliorer leur pouvoir expressif et leur flexibilit: le contrle daccs bas sur lquipe
(Team-Based Access Control - TMAC)[8], contrle d'accs bas sur des tches (Task-based
Authorization Controls - TBAC)[9] et le contrle daccs bas sur lorganisation
(Organisation-Based Access Control - OrBAC)[10]. Soit de ltendre en ajoutant par exemple,
des contraintes temporelles, spatiales ou gographiques).
La prsente thse sintresse essentiellement aux techniques de contrle daccs, et plus
prcisment au modle OrBAC[10], qui permet dabstraire les entits : sujet, action et objet
respectivement enrle, activit et vue et ce dans le cadre dune mme organisation. Ce concept
permet de rduire le nombre de rgles de scurit et de simplifier galement la tche de
ladministrateur.
11
Le premier objectif de cette thse est de confirmer la puissance expressive de ce modle

OrBAC, et de montrer quil est possible de lutiliser pour coder une politique de scurit qui nest
pas ncessairement en relation avec le domaine de la sant car lorigine OrBAC a t propos
pour rpondre aux exigences des politiques de scurit dans les domaines de soins de sant. Nous
avons choisi SELinux (Security Enhanced Linux) puisquil reprsente une des solutions de
scurit les plus utilis, en plus il utilise plus quun modle de contrle d'accs (RBAC, MLS,
DTE, etc.) dans les systmes d'exploitation Linux.
Le deuxime objectif est de proposer une extension du modle OrBAC en intgrant le
concept de priorit qui peut tre associ avec les rgles de la politique de scurit. Ces priorits
sont reprsentes dans le cadre de la thorie des possibilits[7][10][11]. Nous avons propos
diffrentes rgles d'agrgation pour driver les priorits associes aux permissions concrtes
partir des rgles prioritaires des permissions abstraites.
12
Plan du mmoire
Ce document comporte sept chapitres :
Le chapitre 1prsente dune manire gnrale la scurit des systmes d'informations. Il
rappelle les notions gnrales et les proprits de scurit. Ensuite il dfinit les divers modles de
contrle d'accs dans les systmes d'information. Il fait le point sur les diffrentes politiques de
contrle d'accs ainsi que sur leurs modles proposs dans la littrature. Nous dcrivons les
limites de chaque modle de contrle d'accs.
Le chapitre 2intitul La solution de scurit SELinux, est une prsentation de SELinux
(Security-Enhanced Linux) comme solution de scurit des systmes Linux. Il constitue travers
ces paragraphes une dmystification de plusieurs concepts SELinux et met en relief les divers
aspects en relations avec lobjet de la prsente thse. Enfin, ce chapitre liste, pour chaque modle
de contrle daccs (DAC, TE, RBAC, MCS, et MLS) utilis dans SELinux, les plus importants
des travaux de recherches qui ont t proposs.
Le chapitre 3 prsente le modle de contrle d'accs OrBAC, ce modle est centr sur la
notion d'organisation, ce qui permet de reprsenter une politique de scurit qui diffre d'une
organisation une autre. Nous avons utilis un langage issu de la logique du premier ordre pour
reprsenter les diffrentes entits et relations du modle OrBAC. Ainsi que le codage des
hirarchies et des contraintes. Les exemples dillustration sont gnralement fournis en relation
avec SELinux.La fin de ce chapitre prsente les fonctionnalits de base de loutil dadministration
[12] interface graphique bas sur le modle OrBAC :MotOrBAC (acronyme qui dsigne Moteur
OrBAC) qui permet dexprimer une politique de scurit au niveau organisationnel.
Le chapitre 4 intitul Codage en modle OrBAC de la politique de scurit par dfaut de
SELinux commence par donner quelques brves descriptions de concepts principaux utiliss par
une politique de scurit SELinux par dfaut tels que: le contexte, le rle, de type, etc. Nous
montrons ensuite que chaque concept dans la politique de scurit SELinux possde son
correspondant naturel dans le modle OrBAC ce qui confirme la puissance expressive du systme
OrBAC. Nous avons utilis la distribution Fedora 14et Red Hat 4, pour illustrer notre encodage.
Le Chapitre 5est consacr la prsentation des transitions de types en SELinux et
lattribution dun type (resp. domaine) par dfaut un objet (resp. processus). Il traite en outre le
cas dune transition de domaine partir dune rgle de scurit, ce cas est illustr travers
13
lexemple de changement de mot de passe dans le systme Linux. Le but de ce chapitre est de
montrer comment on peut coder les transitions de domaines en OrBAC.
Le chapitre 6propose une extension du modle OrBAC en intgrant le concept de priorit
qui peut tre associs aux rgles de la politique de scurit. Ces priorits sont reprsentes dans le
cadre de la thorie des possibilits, nous abordons la faon dont laquelle les priorits sont
ajoutes aux diffrentes entits abstraites du modle OrBAC. Nous avons galement proposdes
rgles d'agrgation pour driver les priorits associes aux permissions concrtes partir des
rgles prioritaires des permissions abstraites.
Le chapitre 7propose une implmentation de nos contributions sous forme dun
programme dvelopp en Delphi 7 grant une base de donnes cre en Paradox, plusieurs
images cran sont captures lors de limplmentation de lexemple dillustration.
Enfin, la conclusion rsume les diffrents chapitres ainsi que les contributions et donne
quelques perspectives pour les futurs travaux lis au sujet de cette thse.
14
Chapitre 1
Modles et politiques de contrle d'accs
1.1. Introduction
La scurit des systmes informatiques est un vritable travail, qui consiste sassurer
que les ressources matrielles ou logicielles d'une organisation ne peuvent tre, en aucun cas,
employes en dehors dun cadre prvu et dfini lavance. Elle vise gnralement trois
principaux objectifs :
L'intgrit : Concerne la protection des donnes contre toute altration durant un

traitement ou une communication (de manire accidentelle ou intentionnelle).
La confidentialit : consiste assurer la protection de l'information change contre les
divulgations non autorises.
La disponibilit : permet de maintenir le bon fonctionnement du systme en fournissant
de linformation aux utilisateurs autoriss aux moments o ils en ont besoin.
Les autres proprits peuvent tre vues comme des cas particuliers de ces trois classes, par
exemple
L'authentification : qui peut tre exprime comme lintgrit de la source, elle consiste
sassurer que seules les personnes autorises aient accs aux ressources. Plusieurs
systmes de contrles daccs utilisent des techniques (Exemple : lidentifiant et le mot de
passe dun utilisateur, carte biomtrique) qui permettent d'accder des ressources
uniquement aux personnes autorises.
Le non rpudiation : exprime comme tant lintgrit de la source et de la destination,

elle assure qu'une personne ne puisse nier avoir effectu une transaction et que chaque
transaction est imputable un acteur.
Tout dpond donc, du systme dinformation scuriser, pour choisir telle ou telle
technique de scurit. La cryptographie est gnralement utilise pour assurer lintgrit, la
confidentialit et la non-rpudiation. Avec le contrle daccs, on sintresse plutt garantir
deux proprits fondamentales : la confidentialit et lintgrit des informations contenues dans
un systme dinformation. Ceci ncessite que chaque accs une ressource soit contrl et
autoris. Le systme dont on veut protger les ressources doit disposer de plusieurs mcanismes
de contrle daccs et ce afin de permettre dy implanter des politiques de scurit (concernant la
confidentialit et lintgrit). Le contrle daccs fonctionne sur les modles utilisant les entits
de modlisation suivantes :
Sujet : est une entit active, elle inclut toujours les utilisateurs du systme et souvent les
processus en cours d'excution pour le compte des utilisateurs. Dans ce contexte, un
utilisateur est soit une personne physique connue par le systme informatique et
enregistre comme utilisateur, soit un serveur, soit une sorte de personne morale
reprsentant des fonctions de service automatique telles que le serveur dimpression, le
serveur de base de donnes, le serveur de messagerie, etc.
Objet : est une entit passive, un conteneur dinformation, sur lequel un sujet peut
effectuer une action (les fichiers, sockets de communication, priphriques matriels,
etc.);
15
Action : elle reprsente les moyens permettant aux sujets de manipuler les objets du
systme.
Le prsent Chapitre se prsente sous forme de plusieurs sections : dans la premire section
nous prsentons dune manire gnrale la scurit des systmes d'information. La section qui
suit rappelle les notions gnrales et les proprits de scurit ainsi que les diffrents modles de
contrle d'accs proposs dans la littrature.
1.2. Politique de scurit
Dfinition : Une politique de scurit est lensemble des lois, rgles et pratiques qui
rgissent la faon dont linformation sensible et les autres ressources sont gres, protges et
distribues lintrieur dun systme spcifique3.
Une politique de scurit se construit en dfinissant les proprits satisfaire par le
systme, et en tablissant un schma dautorisation qui doit avoir, en principe, une politique
cohrente. La politique de scurit prend en compte les aspects organisationnels et techniques qui
dfinissent comment les utilisateurs peuvent manipuler l'information. Les proprits de scurit
peuvent tre dfinies en fonction de la confidentialit, lintgrit et la disponibilit (Cf. 1.1).
Le dveloppement dune politique de scurit peut tre ralis dans trois directions
distinctes, savoir : physique, administrative et logique[13].
Physique : Cette politique prcise un ensemble de procdures et de moyens qui protgent

les locaux et les biens contre des risques majeurs (incendie, inondation, etc.) et contrlent
les accs physiques aux matriels informatiques et de communication (gardiens, codes,
badges, ...).
Administrative : cette politique dfinit un ensemble de procdures et moyens qui traite
tout ce qui ressort de la scurit dun point de vue organisationnel au sein de lentreprise.
La structure de lorganigramme ainsi que la rpartition des tches (sparation des
environnements de dveloppement, dindustrialisation et de production des applicatifs) en
font partie. Les proprits de scurit recherches visent, par exemple, limiter les
cumuls ou les dlgations abusives de pouvoir, ou garantir une sparation des pouvoirs.
Logique : Cest la politique de scurit qui fait rfrence la gestion du contrle daccs
logique, lequel repose sur un triple service :
a. Service Identification : Identifier de faon unique un sujet grce un identifiant.
b. Service dauthentification : Sassurer que lidentit du sujet est bien celle quil
prtend tre.
c. Service dautorisation : Dterminer si le sujet authentifi peut effectuer laction
dsire sur lobjet spcifi.
Le contrle daccs spcifie qui peut accder quoi et dans quelle circonstance,
lautorisation consiste administrer et examiner les droits daccs, en fonction des
spcifications de la politique de scurit, ces spcifications sont gnralement des :
Permission : Sujet a le droit de lire Objet.
Interdiction : Sujet na pas le droit dcrire dans Objet.
Obligation : Sujet doit conserver Objet.
Dfinition dITSE : Information Technology Security Evaluation riteria, standard pour la scurit des systmes d'information.
16
1.3. Les politiques et les modles de contrle daccs

Le modle de contrle d'accs [14] est matrialis par un ensemble de mcanismes. Il peut
tre dfini comme un formalisme, souvent mathmatique, qui consiste vrifier si un sujet
(utilisateur, processus ) demandant d'accder un objet (ressource, autre sujet...) possde les
droits ncessaires pour le faire. Le contrle d'accs permet donc de limiter l'accs des sujets aux
objets, il a pour but principal de protger les donnes et les ressources du systme contre la
rvlation et la modification non autorises tout en assurant leur disponibilit aux utilisateurs
lgitimes. Le systme de contrle daccs doit tre capable de contrler tout accs au systme et
ses ressources en assurant les accs autoriss et seulement ceux-ci.
Les schmas dautorisation des politiques de scurit sont classs en trois grandes
familles:
Les politiques discrtionnaires (Discretionary Access Control - DAC)
Les politiques obligatoires (Mandatory Acces control-MAC)
Les politiques bases sur les rles (Role-Based Access Control - RBAC)
Gnralement, on adapte des organisations particulires dautres politiques comme:
TBAC (Team-based Access Control Model) [8],TMAC (Task-Based Access Control)[9],
HRU (Harrison, Ruzzo and Ullmann) [15], BLP (Bell et Lapadula)[16]etOrBAC (Organizationbased access control) [10]. Normalement, il faut construire une politique de scurit de telle sorte
quaucune squence valide dapplications des rgles (du schma dautorisation) ne puisse amener
le systme dans un tat tel quun objectif de scurit soit viol, en partant dun tat initial sr (on
parle de politique de scurit cohrente).
Ceci suppose lutilisation dune mthode formelle de construction des rgles du schma
dautorisation, partir dune spcification formelle des objectifs de scurit.
1.3.1. Contrle daccs discrtionnaire (DAC)
Le contrle daccs discrtionnaire (Discretionary Access Control - DAC)[14] permet
un sujet dattribuer des permissions dautres sujets. Ce contrle daccs est flexible mais il peut
gnrer des erreurs.
Les manipulations des droits daccs chaque objet restent lentire discrtion du sujet
qui en est le responsable. Dans un tel modle tout sujet ayant cr un objet en est le propritaire.
Ce type de mcanisme est utilis dans les systmes dexploitation traditionnels : Unix, Linux,
Windows et Macintosh, il est implment gnralement avec des listes de contrle daccs
(Access Control Lists - ACL) (Cf.Tableau 1).
Les modles DAC que nous prsentons dans cette section sont ceux qui se basent sur la
matrice de contrle daccs: le modle de Lampson et le modle de Harrison Ruzzo Ullman.
1.3.1.1.
Modle de Lampson
Matrice de contrle daccs : La matrice de contrle daccs (introduite par Butler

Lampson en 1971 [4]) est une matrice deux dimensions reprsentant, pour chaque sujet, les
actions quil peut effectuer sur chaque objet. Il sagit donc dune reprsentation naturelle des
relations entre les sujets et les objets. Les sujets sont les lignes et les objets (ou les sujets) sont les
colonnes de la matrice et chaque cellule (se trouvant sur la ligne i et sur la colonne j) correspond
17
un ensemble de droits d'accs qui constituent l'ensemble des oprations que le sujet (i) peut
raliser sur l'objet (j).
La construction dune telle matrice ncessite l'identification et le contrle des objets
protger, des sujets qui demandent accs aux objets, et des actions qui peuvent tre excutes sur
les objets. Elle est structure sous forme dune machine tats, o le triplet (S, O, M) reprsente
chaque tat, avec :
S est un ensemble des sujets (dans notre cas S= {s1,..,sM})
O est un ensemble dobjets (dans notre cas O= {o1,..,oN})
M une matrice de contrle daccs (dans notre cas M (si, oj)=Lecture)
Le modle de Lampson associ aux DAC, ne permet pas dexprimer directement des interdictions
ou des obligations, aussi sajoute-t-il la complexit de la mise jour de la matrice daccs.
Sujet/Objet
s1
s2
si
o1
Lecture
criture
Excution
Lecture
sM
Pas
daccs
oj
oN
Pas daccs
Lecture
Lecture
criture
Tableau 1- Matrice de contrle daccs

Thoriquement, il y a autant de colonnes que de nombre dobjets (et de sujets) du systme
et autant de lignes que de nombre de sujets du systme, cela rend notre matrice impraticable, car
chaque fois qu'un sujet est introduit (ou un objet est cr) dans le systme, tous les droits
d'accs accords devront tre enregistrs. Par consquent, la mise jour d'une politique de
scurit exprime par ce modle est fastidieuse, do lutilisation de deux vecteurs:
s2
o1 : Lecture
o2 : Pas daccs
oN : Lecture
Tableau 2-Exemple de table de possibilits
18
o2
s1 : Lecture
s2 : Pas daccs
sM : criture
Tableau 3-Exemple d'ACL
Table de possibilits (capability table) : Cest un vecteur de la matrice de contrle daccs

faisant ressortir les droits dun sujet donn sur tous les objets (Cf. Tableau 2), cette technique
est utilise par le protocole d'authentification rseau Kerberos4 .
Liste de contrle daccs (ACL) : Une ACL est un vecteur de la matrice de contrle daccs,
il reprsente l'ensemble des sujets ayant des droits d'accs sur l'objet considr avec pour
chaque sujet l'ensemble des actions que ce sujet peut raliser sur l'objet, cest une technique
utilis pour les routeurs. (Cf. Tableau 3).
A noter que le modle de Lampson associ aux DAC, ne permet pas dexprimer
directement des obligations ou des interdictions qui peuvent tre parfois dune grande utilit pour
exprimer des exceptions. Encore plus, la mise jour de la matrice daccs est trs fastidieuse. En
effet, lajout dun nouvel utilisateur passe par lajout dune ligne de la matrice ce qui correspond
remplir toute les cellules des objets se trouvant la mme ligne que le sujet. Le modle de
Lampson a t progressivement amlior pour donner naissance dautres modles tels que le
modle de (Harrison Ruzzo Ullman - HRU)[15].
1.3.1.2.
Le modle HRU
Le modle HRU, formalis par Harrison, Ruzzo et Ullmann[15], propose de modliser la

protection des systmes dexploitation comme suit :
Lensemble des sujets S et lensemble des objets O ;

Une matrice de contrle daccs Pso avec s S, o O et Pso A (ensemble de droits
daccs).
Lensemble des droits gnriques R = (possession, lecture, criture,
excution)
Ensemble fini C de commandes c1, . . . ,cn reprsente lensemble des oprations fournies par
le systme dexploitation (cration de fichier, modification des droits,...).
Un ensemble dactions lmentaires E : enter et delete pour lajout et la suppression de
droits, create subject et create object pour la cration de nouveaux sujets et
objets et enfin destroy subject et destroy object pour la destruction de sujets et
objets (Cf. Tableau 4).
En ce qui concerne la protection, les commandes de lensemble C ont tous la mme
forme, elles sont construites partir des oprations primitives ci-dessus et prennent comme
argument des sujets et des objets. Elles prennent en paramtres une liste de sujets et objets, et
suivant la prsence de certains droits dans la matrice P, elles effectuent des actions lmentaires
sur le systme. La configuration du systme de protection est reprsente par le triplet (S, O, P).
4
Kerberos est un protocole d'authentification rseau qui repose sur un mcanisme de cls secrtes (chiffrement symtrique) et
l'utilisation de tickets.
19
Significations
Enter r into M(s,o) Donner un droit r un sujet s sur un objet o

Delete r from
M(s,o)
Create subject s
Enlever un droit r un sujet s sur un objet o
Destory subject s
Dtruire un sujet s
Crer un sujet s : Ajoute une ligne et une colonne

la matrice M car le sujet s est aussi un objet
Create object o
Gestion
des objets
Gestion
des sujets
Gestion
de la
matrice
Primitives utilises
par les rgles
Ajoute une colonne la matrice M

Dtruire un objet o (possible si ce nest pas un sujet)
Destory object o
Tableau 4-Actions lmentaires de la matrice dfinie par le modle HRU

Exemple 1 :
Prenons le cas o le modle HRU est implant sous Unix, les objets sont des fichiers, les
actions sont reprsentes par lensemble {r,w,x}, les Permissions reprsentes sous forme
dACL: <o1,( s1 ,(r,w,x)),(s2,(r,x))> et <o2,(s1,(r,w)),(s2,(r))>.
Pour ce qui est de lensemble C, on y trouve la commande chmod qui sert manipuler les
droits daccs des fichiers.
La matrice P se prsente comme indiqu dans le Tableau 5 :
s1
s2
o1
o2
s1
rwx rw-
s2
r-x r--
Tableau 5-Exemple de matrice HRU

Exemple 2 :
La commande suivante permet le transfert de droit dcriture sur lobjet o1 du sujet s1vers
le sujet s2:
Commande Transfert-criture (s1, s2)
Si write P (s1, o1): vrification de la prsence du droit w
dans la cellule P (s1, o1) dans notre exemple (1er exemple) ce
droit existe bien, puisque P(s1,o1)=rwx.
Alors Mettre write dans P (s2, o1) (c'est--dire que P(s2, o1)
passera de la valeur r-x la valeur rwx).
Outres les insuffisances du modle de Lampson, le modle HRU prsente les limites
suivantes :
Il ne permet pas de reprsenter les rgles de dpendance du contexte.
20
Il ne permet pas de prendre en compte la notion du moindre privilge.
La gestion et la maintenance de la matrice daccs revt un caractre fastidieux et

cote beaucoup en mmoire.
La rduction de la taille de la matrice en constituant des groupes d'utilisateurs
nest toujours pas une bonne solution, puisquun sujet peut appartenir plusieurs
groupes.
Complexit du problme de protection du modle HRU :
Le problme de protection est indcidable (dans le cas gnral) : Si nous appliquons une
squence de commande la matrice daccs, nous ne sommes pas srs quun droit
particulier soit mis dans une cellule o il ne se trouvait pas auparavant.
Le problme de protection est dcidable dans le cas dexcution dune commande ne

contenant quune seule opration lmentaire.
1.3.1.3.
Les insuffisances du modle DAC
Les modles discrtionnaires DAC posent quelques problmes comme la vulnrabilit aux
chevaux de Troie5[16]. En effet la politique discrtionnaire se base sur la confiance totale
attribue aux sujets qui sexcutent aux comptes des utilisateurs et aux utilisateurs eux-mmes.
Des manipulations maladroites ou malveillantes provoquent des abus de pouvoir rendant la
politique vulnrable. En effet, il suffit quun seul utilisateur commette une erreur pour que la
politique globale de scurit soit compromise. De plus, il se peut quun utilisateur non autoris,
reoive une copie dun objet transmis par un utilisateur autoris le lire, cette situation est une
consquence immdiate du fait que ce dernier ne possde pas une vision globale du systme. On
parle donc de lincontrlabilit du flux dinformation.
1.3.2. Contrle daccs mandataire (MAC)
Le contrle d'accs obligatoire (MAC) [14] est gnralement dfini par opposition au
contrle d'accs discrtionnaire (DAC), son objectif est dimposer une politique non modifiable
par les utilisateurs finaux dans le but de garantir la sret du systme afin de pallier aux divers
problmes dus aux fuites d'informations et la vulnrabilit aux chevaux de Troie [16].
Anderson [17] propose dutiliser un Moniteur de Rfrence (Reference Monitor) pour
contrler les accs entre sujets et objets. La matrice correspondante tant fixe, il devient alors
possible de garantir que des droits daccs considrs critiques ou dangereux ne pourront tre
donns ou obtenus par erreur. Ce concept de Moniteur de Rfrence est au cur de la dfinition
du contrle daccs mandataire qui est plus rigide et plus sr que le contrle daccs
discrtionnaire.
Les fuites dinformations et le transfert illgal sont contrs par les rgles des politiques
MAC, qui contrlent les flots dinformations. Ces politiques sont gnralement des politiques
multi-niveaux bases sur la notion de treillis6 et qui consiste en une classification des sujets et des
objets impose par une autorit centrale.
Un cheval de Troie est un programme se prsentant comme un programme normal destin remplir une tche donne, et qui, une fois install
exerce une action nuisible diffrente de sa fonction "officielle".
6
Un treillis est un ensemble E muni dune loi (partiellement ordonn) tel que : x, y E, inf{x,y} et sup{x,y} existent.
21
1.3.2.1.
Les politiques multi-niveaux
Dans un environnement multiutilisateur, les donnes et les informations qui circulent dans
le systme dinformation peuvent tre ranges dans diffrents niveaux de sensibilit. En effet,
certaines informations pourront tre qualifies de trs importantes que d'autres.
Une information sensible est une information qui, si elle est rvle des personnes mal
intentionnes, peut entraner la perte d'un privilge ou dun droit. Do la ncessit de mettre en
place des solutions (de contrle daccs) de sorte que seuls certains sujets peuvent tre filtrs
pour accder ces informations.
Exemple: dans une entreprise, les salaires et les primes des employs peuvent tre
qualifis dinformations sensibles et par consquent, seul un nombre restreint de fonctionnaires
(habilits) peuvent avoir accs cette information. ien que dautres informations comme le nom
de lemploy, son adresse etc. ne le sont pas. ette qualification varie dune entreprise une
autre et peut dpendre aussi des lois de chaque pays. En effet, en France par exemple, il n'est pas
illgal de demander l'ge d'un candidat l'embauche, alors quaux tats-Unis cela est interdit et
peut faire l'objet d'un procs en suspicion de discrimination d'ge.
Les modles de scurit multi-niveaux [18] permettent d'viter la divulgation non
autorise de certaines informations aux utilisateurs non fiables. Cette politique est mise en uvre
par un mcanisme qui consiste attribuer des niveaux de scurit aux objets et aux sujets.
Les politiques multi-niveaux classent les sujets et les objets avec diffrents degrs de
sensibilit ou niveau de scurit lesquels constituent un ensemble partiellement ordonn par une
relation de dominance, note:
Un niveau de scurit est form de deux composants : un niveau classification et un

ensemble de catgories. Cest--dire :
Niveau de scurit = (niveau classification, ensemble de catgories) :
Le niveau de classification : il sagit dun ensemble totalement ordonn, Supposons que

nous avons quatre niveaux :
Trs-secret (TS);
Secret (S);
Confidentiel (C);
et Public (P)
Ainsi le niveau TS est plus sensible que le niveau S, qui est plus sensible que le niveau C
et ainsi de suite : TS S CP.
Lensemble de catgories : Lensemble des catgories dcrit les divers domaines de

linformation. Par exemple dans les systmes militaires cet ensemble peut contenir les
catgories : nuclaire et arme, dans les systmes commerciaux les catgories sont plutt
financier, administratif, etc. La relation entre les ensembles de catgories est l'inclusion
ensembliste :
tant donne deux niveaux de scurit (n1) et (n2) tels que (n1) (respectivement (n2)) est
dfini par sa classification (c1) (respectivement (c2)) et son ensemble de catgories (C1)
(respectivement (C2))
La relation de dominance est dfinie comme suit :
22
n1 domine n2 (ou n1 n2)

si et seulement si :
le niveau de classification c1 den1 est plus sensible que le niveau de classification c2 de n2
(c1 >c2)
L'ensemble de catgories C2 de n2 est inclus dans C1 de n1 (C2 C1).
Lensemble des niveaux de scurit muni de la relation dordre partiel () possde une
borne infrieure et une borne suprieure. La structure de cet ensemble forme un treillis.
Lutilisation ainsi que la smantique de la classification dpendent de lobjectif vis, c'est--dire :
veut-on prserver la confidentialit ou lintgrit des donnes?
Nous allons prsenter des politiques multi-niveaux bases sur la confidentialit (BellLaPadula) ainsi que celles bases lintgrit (Biba) des objets du systme. Pour ces deux modles
nous dfinissons les entits suivantes:
L : un ensemble de niveaux de scurit avec un ordre partiel .

hab : S L, une fonction qui associe chaque sujet son niveau dhabilitation.
cla : O L, une fonction qui associe chaque objet son niveau de classification.
Mso, la matrice de contrle daccs qui associe un ensemble de droits daccs chaque
couple (s, o) S O.
a. Le modle Bell et LaPadula (BLP)
Le modle Bell et La Padula (BLP) a t dvelopp par David Bell et Leonard

LaPadula[16] pour le Dpartement de la Dfense Amricain (Departement of Defense - DoD), il
utilise des concepts mathmatiques fonds sur la notion de treillis afin de dfinir l'tat de la
scurit d'un systme.
Comme pour les politiques multi-niveaux, le modle Bell et La Padula (BLP) est un
modle canonique de scurit multi-niveau, il dfinit un niveau de scurit compos de couple
(L, C), avec la smantique suivante:
L : tant le niveau de confiance accorde un sujet s pour ne pas divulguer une information
un utilisateur non habilit la connatre. Ce niveau reprsente donc une classification des
sujets dans un ensemble totalement ordonn, exemple :
{non-classifi, confidentiel, secret, Top-secret}
C : dsigne une classification lintrieur de laquelle lobjet se trouve, elle indique la

sensibilit de l'information contenue dans l'objet, c'est--dire les risques potentiels qui
pourraient rsulter de la rvlation non autorise de cette information.
Pour viter toute ambigit, nous ne tenons pas en considration l'ensemble des
catgories, nous ne considrons dans ce qui suit que le niveau de classification.
Les politiques bases sur le modle BLP visent prserver la confidentialit des donnes,
c'est--dire que celles-ci ne sont accessibles que pour les utilisateurs autoriss.
Pour maintenir la confidentialit, des restrictions sont imposer sur les oprations de
lecture et dcriture, qui permettent de transfrer des informations. Ces restrictions se traduisent
par les deux principes suivants :
la proprit simpleNo Read Up : Cest une interdiction explicite de toute lecture en haut.
Cette proprit assure quun sujet s ne peut lire un objet o que si le niveau de scurit de s
domine celui de o (un sujet ne doit pas semparer des informations qui ne lui sont pas
autorises). La figure 1. ci-dessous indique les niveaux de scurit attribus aux objets et aux
sujets, par consquent, les rgles suivantes sont suscites :
23
un sujet qui a lhabilitation Confidentiel na pas le droit daccder en lecture un objet

qui a la classification Top-Secret, car le niveau de scurit confidentiel est infrieur au
niveau de scurit Top-Secret.
un sujet qui a lhabilitation Top-Secret a le droit daccder en lecture un objet qui a la
classification Confidentiel parce que le niveau de scurit Confidentiel est infrieur au
un sujet qui a lhabilitation Secret a le droit daccder en lecture un objet qui a la
classification Secret car le mme niveau de scurit est attribu au sujet et lobjet.
Figure 1-La proprit simple de BLP
la proprit toileNo Write Down : cest une interdiction de toute criture en bas, cette
proprit assure quil ny aurait pas de fuite dinformation dun objet vers un autre objet de
classification infrieure. pour cela un sujet s ne peut modifier un objet o que si le niveau
courant de scurit de s est domin par celui de o (un sujet ne doit pas rvler des secrets).
De la mme manire que la proprit simple de BPL, la Figure 2ci-dessous indique les
niveaux de scurit attribus aux objets et aux sujets. Les des rgles suivantes sont respecter :
Un sujet qui a lhabilitation Confidentiel a le droit daccder en criture un objet qui a la

classification Top-Secret car le niveau de scurit Confidentiel est infrieur au niveau de
scurit Top-Secret.
Un sujet qui a lhabilitation Top-Secret na pas le droit daccder en criture un objet
qui a la classification Confidentiel car le niveau de scurit Confidentiel est infrieur au
Un sujet qui a lhabilitation Secret a le droit daccder en criture un objet qui a la
classification Secret car le mme niveau de scurit est attribu au sujet et lobjet.
24
Figure 2-La proprit toile de BLP

Plus formellement : La proprit simple se traduit par :
(s, o, read) hab(s)>cla(o)
avec
(s, o, read) readMso.
Ce deuxime principe empche, comme illustr dans la Figure 3, de lire un fichier puis de
le copier sur un autre fichier de classification infrieure et qui pourrait tre lu par un utilisateur
non habilit.
Figure 3-Exemple de cheval de Troie

Limites du modle BLP :
Une sur-classification des informations : Aprs modification des objets non classifis par un
sujet ayant une habilitation h ces objets se voient attribuer une classification gale
lhabilitation h, do une croissance automatique des classifications. Les objets en question
doivent tre dclassifies aprs un certain temps par des sujets de confiance.
La classification dune copie dun objet quelconque peut diffrer de celle du fichier originale:
cest la proprit No Write Down qui lexige.
Le non traitement de la gestion de lintgrit des donnes.
25
b. Le modle de la muraille de Chine

Le modle de la muraille de Chine (the Chinese Wall- CW) a t propos dans [19] par
Brewer and Nash. Il suit les mmes principes que le modle Bell et LaPadula (destin la
proprit de confidentialit) sauf quil est dfini pour le domaine commercial. Son but est de
rsoudre le problme de conflits dintrts relis aux activits de consultation lintrieur des
institutions (banques, tablissements financires) et par consquent de prvenir les flux
d'informations qui mnent des conflits. Par exemple, il y aurait un conflit dintrt si un
consultant ait accs aux informations confidentielles de deux entreprises concurrentes (Cf. Figure
4).
Dans ce modle, les informations dune socit sont organises de manire hirarchique et
sont disposes en trois niveaux dimportance :
1. Le bas niveau : Ce niveau comprend les lments individuels dinformation, chacun
concernant une simple socit. Les informations auxquelles on demande accs sont
stockes dans des fichiers, appels aussi objets.
2. Le niveau intermdiaire : tous les objets concernant les donnes d'une mme compagnie
sont groups dans un ensemble de donnes de compagnie (en anglais company
dataset).
3. Le haut niveau : les ensembles de donnes des compagnies en conflit (exemple, les
donnes concernant deux compagnies en comptition ou en concurrence) sont groups
ensembles. Chaque groupe est appel une classe de conflit dintrt (en anglais conflict
of interest class).
Figure 4-Le modle de la muraille de chine

Dans la politique de la muraille de chine, l'accs aux donnes est contraint par lhistorique
des accs que les sujets ont dj tablis sur les donnes suite par exemple des consultations.
Pour cela, on procde lintroduction dune matrice N qui contient lhistorique des accs
prcdemment effectus, il sagit en fait de placer les sujets et les objets respectivement en ligne
et en colonne de la matrice N. pour chaque case de N on trouve un boolen qui indique si un
accs a dj eu lieu pour le couple (sujet, objet) correspondant. Ce modle impose une rgle
simple et une proprit toile[19]pour interdire l'accs aux objets appartenant des ensembles
conflictuels. La permission daccs un objet O est accorde pour un sujet7S seulement si :
7
Dans la proprit simpleSdsigne seulement un utilisateur (pas un processus).
26
La proprit simple :
La proprit toile :
l'objet O appartient la mme classe de donnes dj

accde par le sujet S( l'intrieur de la muraille)
ou, si l'objet O appartient une autre classe de conflits

dintrt compltement diffrent laquelle S na jamais
accd.
si S peut lire O
et, si S na jamais crit dans un autre dataset que celui o

il essaie dcrire.
Le terme information aseptise ou information assainie dsigne une information

dissimule de manire ce quil soit impossible de dcouvrir ou de reprer la compagnie
laquelle cette information appartient.
La rgle proprit toile prvient principalement quun utilisateur lise des donnes dune
compagnie et les crive dans un fichier dune autre compagnie, ce qui provoquerait une fuite
dinformation.
Limites du modle de la muraille de Chine:
Bien que le modle rsolve le problme de conflit dintrt, il souffre dune limite concernant le
blocage du systme lors de lapplication des deux proprits simple et toile. En effet, on doit
tenir en considration les contraintes imposant au systme d'avoir un nombre d'utilisateurs
suprieur ou gal au nombre maximal des ensembles des donnes conflictuels[19].
c. Le modle Biba
Les faiblesses du modle de Bell-LaPadula qui ne s'intresse que de la confidentialit et
ne prend pas en compte l'intgrit des donnes, ont pouss Biba [20]de proposer (en 1977) une
politique duale celle de Bell et Lapadula, appel le modle d'intgrit de Biba, qui permet de
garantir quaucun sujet de niveau infrieur ne puisse modifier indirectement des objets
appartenant un niveau suprieur.
Tout comme le modle BLP, le modle de Biba est dfini par deux proprits : la
proprit simple et la proprit toile. Ces deux proprits doivent tre satisfaites pour assurer
lintgrit des donnes :
la proprit simpleNo Read down : Un sujet ne peut accder en lecture un objet que si le
niveau de classification de l'objet domine celui du sujet. D'une faon similaire que pour le
modle de BLP, lattribution de niveaux de scurit aux objets et aux sujets comme indiqu
dans laFigure 5 ci-dessous donne lieu aux rgles suivantes:
Un sujet qui a lhabilitation Confidentiel a le droit daccder en lecture un objet qui

a la classification Top-Secret parce que le niveau de scurit Confidentiel est infrieur
au niveau de scurit Top-Secret.
Un sujet qui a lhabilitation Top-Secret na pas le droit daccder en lecture un objet
qui a la classification Confidentiel parce que le niveau de scurit Confidentiel est
infrieur au niveau de scurit Top-Secret.
Un sujet qui a lhabilitation Secret a le droit daccder en lecture un objet qui a la
classification Secret parce que le mme niveau de scurit est attribu au sujet et
lobjet.
27
Figure 5- La proprit simple de Biba

La proprit toileNo Write up : Un sujet ne peut accder en criture un objet que si le
niveau de classification courant du sujet domine celui de l'objet.
Plus formellement :
La proprit simple se traduit par :
(s, o, read) hab(s)<cla(o)
avec
(s, o, read) readMso.
De la mme manire que la proprit simple ci-dessus, l'attribution des niveaux de

scurit aux sujets et aux objets (Cf. Figure 6) gnre les rgles suivantes:
Un sujet qui a lhabilitation Confidentiel na pas le droit daccder en criture un objet

qui a la classification Top-Secret parce que le niveau de scurit Confidentiel est infrieur
au niveau de scurit Top-Secret.
Un sujet qui a lhabilitation Top-Secret a le droit daccder en criture un objet qui a la
classification Confidentiel parce que le niveau de scurit Confidentiel est infrieur au
Un sujet qui a lhabilitation Secret a le droit daccder en criture un objet qui a la
classification Secret parce que le mme niveau de scurit est attribu au sujet et lobjet.
Figure 7- La proprit toile de Biba
28
1.3.2.2.
Modle de Clark et Wilson
Le modle de Clark-Wilson [21] a t dvelopp pour rsoudre les problmes de scurit

dans les environnements commerciaux et est principalement li l'intgrit des donnes. Quatre
critres pour assurer l'intgrit des donnes sont dfinis par ce modle :
L'authentification de tous les utilisateurs accdant au systme par leurs identits.
Laudit et la traabilit de chaque programme excut ainsi que lutilisateur qui l'a
excut.
Les manipulations des utilisateurs ne peuvent tre faites qu travers des procdures qui
prservent l'intgrit des donnes (transaction bien formes).
La sparation des pouvoirs : La sparation des pouvoirs se rsume par la dcomposition

des oprations en plusieurs parties, chacune excute par une personne diffrente.
Ce modle, dissocie lespace des donnes D, en deux parties disjointes :

Les donnes des contrles d'intgrit (Constrained Data Items- CDI) et
Les donnes non soumises des contrles d'intgrit (Unconstrained Data Items- UDI).
Ceci peut tre formul comme suit :
D = CDI UDI
CDI UDI =
Deux classes de procdures sont dfinies :
Les procdures de validations dintgrit (Integrity Validation Procedure - IVP):

Procdures qui vrifient que les CDI sont conformes l'intgrit.
Les procdures de transformation (Transformation Procedure - TP) : Les IVP sont
utilises pour trier les lments de D, qui sont placs dans les CDI si leur intgrit est
valide, et dans UDI dans le cas contraire. Les TP sont les transactions valides du
systme, cest--dire quelles ne perturbent pas lintgrit des donnes auxquelles elles
sont appliques. Lintgrit des donnes est ensuite assure par un ensemble de rgles
parmi lesquelles :
Si une transaction (de TP) sapplique un lment de CDI, le rsultat reste dans le
CDI.
Pour des transactions particulires, si elles sont appliques un lment de UDI,
elles peuvent gnrer un lment de CDI.
Ce modle concerne majoritairement le monde du commerce et plus prcisment les

donnes non informatises. Ce qui rend impossible sa mise en uvre dans les systmes
dexploitation. En effet, il faudrait dfinir les entits CDI, UDI, IVP et TP pour la totalit du
systme, ce qui savre trs complexe.
1.3.2.3.
Le modle DTE
Le modle DTE (Domain and Type Enforcement) [22] est une extension8 du modle Type
Enforcement (TE) qui a t mis en uvre pour la premire fois dans le systme Lock, TE est n
8
Dans ce modle les matrices d'expression de la politique de scurit ont disparu au profit de l'utilisation d'un langage intuitif de politique de
scurit, possibilit de transition automatique entre domaines...
29
suite une implantation flexible du modle de Non-Interfrence au moyen d'un mcanisme de

typage. DTE est un modle d'intgrit et de confidentialit, cependant il ne cherche pas garantir
la sret de la protection quil procure ce qui lui dmarque des autres modles. Le modle DTE
fournit un cadre gnrique permettant dimplmenter diverses politiques de scurit dans un
systme dexploitation. Il est essentiellement fort en matire de confinement de processus [23].
Ce qui limite les risques de compromission dans les deux aspects escompts, savoir : la
confidentialit et lintgrit.
Dans les systmes dexploitation, les principaux objectifs viss par les politiques de
scurit dfinies partir du modle DTE sont :
Restreindre les ressources accessibles par un programme, notamment les programmes peu
srs et les programmes privilgis (sexcutant sous le compte root), suivant le principe
de moindre privilge lequel interdit tout ce qui n'est pas explicitement autoris et autorise
uniquement ce qui est utile.
Contrler quel programme a accs aux ressources (sensibles) et empcher laccs par tout
autre programme.
Pour voir l'intrt du modle DTE, nous allons supposer quune personne vient de pirater
apache (qui fonctionne sous root), et qu'il peut lancer des commandes arbitraires via ce
processus. En tant que root, le pirate peut modifier le fichier /etc/shadow pour s'ajouter un
compte sur le serveur. Cependant, DTE peut tre utilis pour contrler et contrer ce
comportement malveillant en restreignant au serveur apache laccs sauf ses fichiers de
configuration, ses librairies et aux pages web. Et en garantissant galement que seul apache
pourrait accder ses ressources (fichiers de configuration,).
Le modle DTE opre travers les lois daccs sur les domaines (respectivement les
types) sous lesquelles les sujets sont confins (respectivement les objets sont mis).
Tout simplement :
Un sujet s na le droit daccder un objet o que si Ds a le droit daccder To.
Avec:
Ds est le domaine o le sujet s est confin
et
To est le type o lobjeto est mis (ou englob)
Le modle DTE assigne les types aux objets du systme au niveau dune table appele la
table de typage. Une deuxime table : table de dfinition des domaines, note DDTspcifie les
droits daccs (lecture, criture, excution, ajout, suppression) de chaque domaine sur les
diffrents types. La DDT dfinit galement les points dentre (entrypoint) des domaines, c'est-dire quels sont les fichiers binaires qui, une fois excuts, vont crer un processus dans tel ou tel
domaine (Cf. lexemple de mot de passe au b : Transition de domaine lors de lexcution dune
application ).
Finalement les droits daccs entre domaines (cration, destruction, envoi de signal) sont
dfini au niveau de la table dinteraction des domaines, note DIT.
Le modle DTE fait bien partie de la catgorie des contrles daccs obligatoires(MAC),
car la manipulation des tables sus-indiques est effectu par un administrateur et ne relve pas de
la discrtion des utilisateurs finaux.
30
1.3.3. Le contrle d'accs bas sur les rles (RBAC)

RBAC (Role Based Access Control) ou le contrle d'accs bas sur les rles [6][8] peut
tre considr comme une approche alternative au contrle d'accs obligatoire (MAC) et le
contrle d'accs discrtionnaire (DAC). En effet, les modles DAC prsentent beaucoup de
faiblesses comme la vulnrabilit aux chevaux de Troie, aussi sajoute-t-il la difficult
dappliquer des modles assez rigides comme MAC dans des systmes dexploitation nonmilitaires.
RBAC a t conu suite au rsultat dun article de [24] lequel a mis laccent sur le fait
que, souvent, les permissions daccs sont attribues en fonction du rle (est--dire le type
dactivit) quoccupe un utilisateur dans une organisation et non en fonction de lidentit de
lutilisateurs.
Une organisation est gnralement forme dun ensemble de rles auxquels peuvent tre
attribus des sujets. En fait, un rle nest autre quun regroupement de sujet exerant des
fonctions similaires. Habituellement (c'est--dire dans les autres modles), les permissions sont
attribues directement un sujet, alors que dans RBAC, elles sont attribues au rle abritant le
sujet. Ce sont les rles qui reoivent donc des autorisations de raliser des actions sur des objets.
Le modle RBAC introduit le concept de session9 et suppose que la politique est ferme,
c'est--dire que tout accs est refus sil nest pas possible de driver que l'accs est explicitement
permis.
Les manipulations sur les sujets, telles que lajout ou la suppression, sont simplifies :
Ajout : une fois un sujet est cr, et avant de lui attribuer des permissions, il doit avoir un
rle dans lequel on doit le mettre et par la suite on attribue lesdites permissions ce rle,
de cette faon tous les sujets jouant le mme rle se voient hriter les mmes permissions.
Suppression : le fait de retirer un sujet dun rle lui supprime automatiquement toutes les
permissions de ce rle.
Il est remarquer quun sujet ne dtient pas le pouvoir dappartenir un tel ou tel rle,
ceci est dtermin par une autorit centralisant la gestion des rles, gnralement un
administrateur de la politique de scurit.
Le modle RBAC convient parfaitement aux entreprises dont la frquence de changement
du personnel est leve.
La famille RBAC[25] est forme des quatre modles RBAC0, RBAC1, RBAC2, et RBAC3
(Cf. Figure 8).
Chaque session est associe un utilisateur pour une priode de temps limite.
31
Figure 8-La famille des modles de RBAC

a. Le modle RBAC0
RBAC0 est le modle de base de RBAC, la Figure 9 montre que:
plusieurs sujets peuvent tre attribus plusieurs rles comme ils peuvent navoir aucun
rle.
plusieurs rles peuvent dtenir plusieurs permissions comme ils peuvent ne dtenir
aucune permission.
un sujet une permission p si et seulement si ce sujet est attribu un rle qui dtient
cette permission p.
Figure 9-Modle de base : RBAC0

Une prsentation sous format dun diagramme UML (Cf.Figure 10) fait ressortir les
cardinalits entre les entits: Sujets, Rles et Permissions:
Figure 10-Prsentation d'attribution des permissions

32
Les permissions peuvent tre reprsentes comme un couple (objet, opration), o objet
est une ressource qui peut tre un fichier, une mmoire, etc. et opration est un droit daccs
comme lecture, criture.
Le concept de session est introduit au modle RBAC0en vue de lpurer. Une session
reprsente une priode dlimite pendant laquelle un utilisateur accde aux ressources de
systme. Elle ne peut tre active que par un seul utilisateur, qui peut activer une ou plusieurs
sessions. Dans une mme session, un utilisateur a la possibilit de ne pas activer tous ses rles,
mais au besoin il activera, parmi ces rles, ceux indispensables pour laccomplissement des
tches satisfaire.
Dans une session, un utilisateur se voit attribuer toutes les permissions associes aux rles
que lutilisateur a activs, les autres permissions accordes aux rles qui ne sont pas encore
activs ne sont pas attribues lutilisateur. Par consquent, le principe du moindre privilge est
fortement prsent puisque lutilisateur ne possde que les permissions ncessaires pour accder
aux ressources systme, et rien de plus. Ainsi en cas de dfaillance grave du systme, les
dommages ne peuvent pas dpasser ce qui est autoris par les permissions attribues.
b. Le modle RBAC1
Le modle RBAC1 (Cf. Figure 11) est une extension du modle RBAC0. Les rles
peuvent tre structurs de manire hirarchique ce qui permet dpurer progressivement les
diffrentes permissions attribues chaque rle.
Figure 11-Le modle RBAC1

Il existe deux types de hirarchie entre les rles :
Le premier type concerne le rle qui retrace la spcification/gnralisation. Prenons par

exemple le cas du systme Linux, pour considrer les deux rles suivant:
Dmon : rle des processus systme qui s'excutent en arrire-plan, et qui n'ont
pas d'interaction avec les utilisateurs.
Processus : rle des programmes chargs en mmoire centrale et qui sont en cours
d'excution.
Nous remarquons que tous les dmons sont forcment des processus, le rle Dmon est
donc une spcification du rle Processus (Cf. Figure 12) :
33
Figure 12- Hirarchie dans le modle RBAC1

Un lment de rle Dmon hritera du rle Processus toutes les permissions qui lui sont
attribues.
Le deuxime type de hirarchie est li la structure organisationnelle. Prenons l'exemple

de la hirarchie entre les deux rles directeur d'hpital et mdecin, dans ce cas un
utilisateur jouant le rle directeur d'hpital n'hritera pas forcment du rle mdecin. En
effet, directeur d'hpital est une fonction administrative qui nest pas forcment ralise
par un mdecin.
Lhritage des permissions suite lorganisation hirarchique (lien de parent), permet de
simplifier ladministration des politiques de scurit. En effet, cette hirarchie dirige les
permissions accordes du rle gnral (le rle parent) vers le rle spcial (le rle enfant), on
remarque aussi que tous les privilges du rle hritant (spcial) sont aussi des privilges du rle
hrit (gnral), cest ainsi que Wilikens et al.[26], ont dfini la hirarchie entre les rles et par la
suite ils ont conclu que ces hirarchies sont de deux types :
Le modle hirarchique gnrale : Il sagit dune relation multiple tablie entre plusieurs
rles parents et Enfant, l'hritage se fait de plusieurs rles parents. Par exemple, dans la
Figure 13, le rle r5 hrite les permissions des deux rles r2 et r3.
Figure 13-Exemple de hirarchie gnrale
Le modle hirarchique limit : dans une telle hirarchie l'hritage se rduit une simple
structure darborescence ce qui veut dire qu'un rle ne peut avoir quun seul parent.
Exemple r2 hrite ses permissions du seul rle R1 (Cf. Figure 14). Ce type de hirarchie
est ncessaire dans le cas o l'hritage de plusieurs rles entraine des conflits.
34
Figure 14-Exemple de hirarchie limite

c. Le modle RBAC2
Le modle RBAC2 est une autre extension de RBAC0, il introduit la notion de contraintes
sur les rles permettant dimposer un certain nombre de proprits ncessaires la ralisation des
objectifs de scurit (Cf. Figure 15).

Ces contraintes prcisent le nombre maximal d'instances actives d'un rle (politiques de
cardinalit), et permettent ventuellement la sparation des politiques d'affectation qui spcifient
les (deux ou plusieurs) rles qu'un utilisateur ne peut pas avoir actif dans la mme session (la
politique daffectation), il sagit dune exclusion mutuelle statique. Il existe une deuxime sorte
d'exclusion mutuelle [26] : exclusion dynamique qui concerne des contraintes sur l'activation des
rles par les utilisateurs et ce en indiquant qu'un utilisateur n'est pas autoris activer
simultanment certains rles.
d. Le modle RBAC3
Le modle RBAC3 incorpore RBAC0, RBAC1 et RBAC2. Il contient donc les deux notions
de hirarchie de rles et de contraintes (Cf. Figure 16). Cest lun des modles les plus
fonctionnels de RBAC. Le modle RBAC3 est principalement quivalent au modle propos en
1992 par D. Ferraiolo et R. Kuhn[24], sauf que dans le modle RBAC3 on dfinit une hirarchie
d'ordre partiel tandis que le modle [24] dfinit la hirarchie comme tant un arbre enracin.
35

e. Inconvnients du modle RBAC
Le principal inconvnient de RBAC rside dans la difficult de garantir la proprit de
confidentialit. En effet, nimporte quelle utilisateur jouant le rle mdecin puisse accder aux
dossiers de tous les patients, y compris ceux qu'il ne les traite pas. RBAC ne sait donc pas
implmenter des rgles indiquant, par exemple que : les informations mdicales du dossier dun
patient ne peuvent tre lu que par son mdecin traitant. Ceci est d au fait que le modle RBAC
ne prend pas en compte la notion du contexte (comme celle de mdecin traitant par exemple pour
avoir la permission d'accder au dossier mdical du patient). La rsolution de ce problme
ncessite la mise en uvre de rgles de contrle places en dehors du modle RBAC ou la
cration dun rle mdecin_traitant pour chaque patient.
Un deuxime inconvnient est prsent au modle RBAC, plus prcisment en ce qui
concerne la hirarchie des rles qui ne correspond gnralement pas la hirarchie
organisationnelle. Prenons lexemple cit au paragraphe ci-dessus ( b- Le modle RBAC1) :
Directeur dhpital (fonction administrative) est une fonction hirarchiquement suprieure celle
dun simple mdecin. Cependant, un directeur dhpital qui nest pas mdecin na pas les
permissions associes au rle mdecin.
Un autre inconvnient du modle RBAC est qu'il permet de dfinir uniquement des
privilges positifs (i.e., permissions). Il n'est donc pas possible de dfinir des interdictions ni des
obligations. De mme, il n'est pas possible de dfinir la dlgation des permissions entre les
utilisateurs pour une action donne.
1.3.3.1.
Modle bas sur la notion d'quipe
Le modle de contrle daccs bas sur la notion dquipe (Team-Based Access ControlTMAC) formul pour la premire fois en 1997 par Thomas[8]. Son but tait de fournir un
contrle daccs pour les systmes dinformation ayant des activits de collaboration, do
lintroduction dune nouvelle entit quipe qui abstrait les sujets (de diffrents rles) qui
collaborent pour accomplir des tches prcises. Les autorisations que possde un sujet rsultent
de la combinaison des autorisations associes aux rles exercs par le sujet et des autorisations
associes l'quipe laquelle est affect le sujet. Ainsi, les autorisations que possde un sujet
partir dun rle donn changent suivant lappartenance de ce rle une telle ou telle quipe.
36
Dans le modle TMAC les permissions sont ou bien attribues (il sagit du cas o un
utilisateur choisit un rle au moment de sa connexion), ou bien actives (selon le contexte :
spatial, temporel, etc.). Cest donc le pouvoir dexprimer des contextes qui permet au modle
TMAC dtre flexible et dexprimer des politiques daccs pouvant fournir des permissions plus
fines que celles de RBAC.
Dans TMAC, le contexte de collaboration d'une quipe donne contient :
le contexte d'utilisateur : reprsente les utilisateurs qui forment l'quipe un moment
donn.
le contexte d'objet : reprsente les instances d'objets ncessaires pour que l'quipe
puisse accomplir sa tche.
Figure 17-Le modle T-MAC

Plusieurs entits contribuent pour la dfinition dune quipe TMAC [8] telles que : Les
membres de lquipe, lensemble des rles que les membres de lquipe peuvent jouer, un
ensemble dobjets associs lquipe, etc.
1.3.3.2.
Modle bas sur la notion de tche
Le modle TBAC (Task-Based Access control) a t dfini dans [9]comme tant le

modle de contrle daccs bas sur la notion de tche, il diffre des contrles d'accs
traditionnels et des autres modles de scurit par le fait quil fait partie des modles actifs de
scurit, car il approche la modlisation et l'application de scurit des perspectives des activits
et tches au lieu d'avoir une vue centre sur le systme de scurit.
Les modles actifs de scurit fournissent les abstractions et les mcanismes pour la
gestion d'excution de scurit pendant l'achvement ou la ralisation des tches. Dans une
approche active, les permissions sont constamment contrles, actives et dsactives selon le
contexte associ aux tches qu'ils doivent raliser.
Dans le modle TBAC, les permissions issues des autorisations sont limites par des
contraintes qui prcisent leur utilisation, leur validit et leur expiration. De plus, il permet de
mmoriser lutilisation des permissions, ce qui permet de prvenir tout abus de permission par
des oprations inutiles et/ou malveillantes.
37
Lapproche de scurit base sur la notion des tches prsente une rupture radicale avec
les modles classiques (ou modles passifs) de scurit, car ces derniers ne prcisent pas la faon
d'utiliser une permission entre un sujet et un objet.
Dans le modle TBAC, les permissions sont contrles et gres de manire ce qu'elles
soient actives et synchronises pendant l'excution des autorisations. Une tape d'autorisation est
une abstraction fondamentale dans TBAC et est utilise pour grouper et grer un ensemble de
permissions relatives une tche.
Le modle TBAC gre et contrle les permissions dune faon dynamique, elles sont
actives et synchronises pendant l'excution des autorisations. Les permissions relatives une
tche donne sont groupes et abstraites dans des autorisations qui reprsentent les abstractions
fondamentales du modle. Dans TBAC, chaque autorisation possde une dure de vie et donc un
cycle de vie (Cf. ).
Figure 18-Le cycle de vie d'une autorisation.

Les cinq tats par lesquels passe chaque instance d'tape d'autorisation sont, comme le
montre la Figure 18: dormante, invoque, valide, invalide, et suspendue.
Dormante : Une autorisation est dormante lorsquelle n'est pas invoque (demande) par
des tches.
Invoque : Une fois une autorisation est invoque, son tape sera cre et prte tre
excute. Si l'excution russit, alors elle entre dans l'tat valide. Dans le cas contraire,
elle sera invalide.
Valide : Dans cet tat, toutes les permissions associes l'autorisation sont actives. Ainsi
une tape de cette autorisation sera excute et par la suite atteindra la fin de sa vie et
entrera par la suite dans l'tat invalide.
Invalide : quand une autorisation devient invalide, elle sera supprime du systme.
Suspendue : toutes les permissions associes ltape d'autorisation suspendue seront

inactives et ne peuvent pas tre utilises pour accder aux objets jusqu' l'arrt de la
suspension et le rtablissement de la validit.
Il existe plusieurs modles qui constituent la famille de modle TBAC(Figure 19) :

TBAC0, TBAC1, TBAC2 et TBAC3 :
38
Figure 19- La famille des modles de TBAC
TBAC0 : est le modle de base de TBAC, il offre quelques facilits de base aux tches du
modle, des tapes d'autorisation et des dpendances reliant plusieurs tapes
d'autorisation. TBAC0 est un modle trs gnral et flexible, il sagit du minimum requis
pour tout systme incorporant les autorisations bases sur les tches.
TBAC1 : est une extension du modle de base TBAC0, il incorpore la notion d'autorisations
composites qui reprsente une abstraction encapsulant deux ou plusieurs tapes
d'autorisation. Ces tapes d'autorisation sont lies entre elles. Cependant, elles ne sont pas
visibles d'autres tapes d'autorisation n'appartenant pas la mme autorisation
composite. Une autorisation composite est valide si toutes ses tapes d'autorisation sont
dans leur tat valide. D'autre part, elle est considre comme invalide ds qu'une de ses
tapes d'autorisation atteint l'tat invalide.
TBAC2 : est lui aussi une extension du modle TBAC0, il supporte les notions plus
avances de contraintes. Ainsi TBAC2 serait plus appropri pour une organisation qui
trouve TBAC0 assez souple et ouvert.
TBAC3 : combine les deux modles TBAC1 et TBAC2, et donc contient les notions
d'autorisations composites et de contraintes.
1.4. Conclusion
Dans ce chapitre, nous avons prsent diverses politiques de contrle d'accs proposes
dans la littrature. Ces modles ont t classs en trois grandes familles:
Les politiques discrtionnaires (DAC) : Dans ce modle le contrle d'accs est la
discrtion du propritaire de l'objet ou de tout sujet qui est autoris contrler l'accs
l'objet. Des droits peuvent tre passs d'un sujet un autre.
Les politiques obligatoires (MAC) : Dans le cas d'une politique obligatoire, les droits
d'accs sont imposs par l'administrateur du systme et ne doivent pas tre pris par le
propritaire de lobjet concerns.
Les politiques bases sur les rles (RBAC) : Dans ce modle, les droits d'accs sont
accords aux utilisateurs selon ou le(s) rle(s) qu'il(s) joue(nt) dans le systme.
Lutilisation de rle a permis de simplifier considrablement la gestion de la scurit.
RBAC a permis aussi dorganiser les privilges daccs en utilisant la notion de
hirarchie et de contrainte.
39
Nous avons prsent dans ce chapitre, les limites de chacun de ces modles. En effet, la
politique discrtionnaire DAC se base sur la confiance totale attribue aux sujets (utilisateurs),
par consquent ils sont vulnrables aux chevaux de Troie [16]. Aussi sajoute-t-il que la politique
globale de scurit puisse tre compromise suite des manipulations maladroites ou
malveillantes provoques par des utilisateurs. Les politiques RBAC prsentent galement
linconvnient de garantir la proprit de confidentialit puisque deux sujets jouant un mme rle
se voient possder les mmes droits daccs sur les objets du systme. La hirarchie des rles
constitue un autre inconvnient, car elle est gnralement diffrente de la hirarchie
organisationnelle.
Enfin, bien que les politiques MAC garantissent facilement la confidentialit des donnes,
elles peuvent dans certains cas se rvler inappropries. En effet, par exemple dans le cas o des
utilisateurs sont amens utiliser frquemment de nombreuses donnes, Ils peuvent avoir besoin
de grer eux-mmes les droits daccs.
Outre ces limites, les modles DAC, RBAC et MAC ne permettent ni reprsenter des
politiques spcifiant des interdictions ou des obligations, ni exprimer des rgles contextuelles
relatives aux permissions, interdictions et obligations.
Le chapitre suivant propose une solution de scurit dite SELinux (Security Enhanced
Linux) qui sintgre au noyau Linux et qui repose sur les modles : TE, RBAC, MCS, et MLS.
40
Chapitre 2
La solution de scurit SELinux
2.1. Introduction
SELinux(Security-Enhanced Linux) est une solution de scurit des systmes Linux, la
fois complexe et complte. Il offre une grande flexibilit mais sa mise en application est
relativement plus difficile. Sa complexit vient du trs grand nombre de rgles qu'il faut mettre en
place. Ce chapitre essaiera de dmystifier la plus part des concepts SELinux et mettra en relief les
divers aspects en relations avec lobjet de la prsente thse, dont notamment les politiques de
contrle daccs utilises : TE, RBAC, MCS, et MLS de Bell-Lapadula.
Dans la premire section nous prsentons lhistorique de SELinux, son architecture ainsi
que les autres solutions de scurit, la deuxime section dcrit les diffrents modles de scurit
utiliss par SELinux, la troisime section traite la politique de scurit SELinux, la quatrime
section sintresse aux diffrents types de transition de domaine et enfin la dernire section
recense les principaux travaux de recherches utilisant les modles de scurit en relation avec
SELinux.
2.2. SELinux
2.2.1. Historique de SELinux
Initi par lagence de scurit nationale des tats-Unis (National Security Agency- NSA),
SELinux [27]est une solution de scurit qui sintgre au noyau, elle lui apporte plusieurs
fonctionnalits de protection avances comme le MAC (Mandatory Access Control), qui
sajoutent celles existantes telles que le DAC (Discretionnary Access Control).
Cette intgration de mcanismes MAC dans un systme d'exploitation grand public a
permis la NSA de transfrer les concepts de scurit a une large communaut et de dmontrer
leur viabilit. Elle a permis d'amliorer considrablement la scurit du systme en activant la
protection contre les vulnrabilits [28]. Elle a pu limiter strictement les dommages causs par
des applications malveillantes ou dfectueuses.
Le projet SELinux a connu, ensuite lappui des organismes industriels suivants:
Les laboratoires NAI Labs(Network Associates Laboratories) ont contribu au projet
SELinux par le biais du groupe SEE (Secure Execution Environments) comme suit :
Ils ont implment plusieurs contrles (MAC) dans le noyau Linux.

Ils ont dvelopp lexemple de la configuration de la politique de la scurit porte
sur le noyau Linux 2.4.
Ils ont contribu l'laboration dun patch pour le noyau Linux, puis avec le
dveloppement de LSM (Linux Security Modules), ils ont adapt le prototype
SELinux pour le LSM.
MITRE corporation a labor des politiques de scurit pour les applications ainsi
que la documentation pour le serveur web Apache, Sendmail et crond. Ils ont aussi
dvelopp des outils d'analyse des politiques comme loutil Polgen[29].
41
CSC (Secure Computing Corporation), tait une entreprise publique (rachete en 2008
par la compagnie McAfee), elle a dvelopp des services pour la protection des
utilisateurs et des donnes. elle a dvelopp galement beaucoup dutilitaires ainsi
quune configuration prliminaire de la politique de scurit pour le systme. Cette
configuration a t utilise comme point de dpart pour la configuration des
laboratoires NAI Labs.
La premire version publique de SELinux a t donne la communaut du logiciel libre
(licence GPL) vers la fin de lanne 2000 par lInformation Assurance Research Office qui pilote
le projet. Cette version de SELinux prsente sous forme dun patch du noyau Linux a lanc une
impulsion significative et supplmentaire en ce qui concerne la scurit bas niveau du fameux
noyau (kernel). La communaut Linux en particulier (Linus Torvalds10) dcida alors de crer une
architecture modulaire, Crispin Cowan11proposa alors LSM (Linux Security Module)comme
interface fournissant suffisamment de crochets ( hooks en anglais) dans le noyau Linux pour
crer des modules permettant de renforcer le contrle d'accs obligatoire.
2.2.2. Architecture de SELinux
SELinux utilise une architecture globale appele Flask (FLux Advanced Security Kernel)
qui sintgre au Noyau Linux existant travers le framework LSM afin dassurer une grande
souplesse de branchement des divers types de contrle daccs, et de dfinir des politiques de
scurit granulaires et adaptes.
SELinux est utilis dans de nombreuses grandes distributions, telles que:
Fedora depuis la version Core 2 (en 2004) : il est install et activ par dfaut
RedHat depuis la version 4 (en 2005) : il est install et activ par dfaut
Debian depuis la version Eatch (en 2007)
Ubuntu depuis la version Hardy Heron 8.04 (en 2008) comme alternative AppArmor.
2.2.2.1.
Le Framework LSM
Le rle du Framework LSM est de permettre aux modules de scurit (diffrents type de
contrles daccs) de se brancher, travers une srie de points de contrle (hooks ou ancres) sur
le noyau Linux. Ces crochets sont gnralement placs aprs les contrles standard d'accs
(DAC) Linux, mais avant que la ressource relle est accessible par le noyau au nom du processus
appelant.
On y trouve actuellement une implmentation de divers types de contrles daccs
comme : SELinux, LIDS, DTE et mme les capabilities12 ont t sorties du noyau pour sappuyer
sur le projet LSM. La Figure 20 illustre le framework LSM de base.
10 Crateur du noyau Linux

11 Fondateur du logiciel de scurit AppArmor (de la socit Immunix ):
12
En anglais Capability List : liste reprsentant les lignes de la matrice de contrle daccs. Pour chaque sujet on
associe les objets auxquels il peut accder, avec les oprations autorises.
42
Figure 20- Le Framework LSM de base

2.2.2.2.
Le module LSM
SELinux est bas sur le modle de larchitecture Flask (hrite de GFAC[30]) qui,
dploye dans le noyau, permet dimplmenter diffrents modles de scurit autres que RBAC et
TE, ce qui assurent la puissance[31] et la finesse du langage de configuration utilis. Ce langage
est jug relativement simple puisquil dispose dun nombre rduit de mot-cl.
La principale caractristique de Flask est la sparation du code dcision et lecode
application de la politique de scurit.
Le code dcision (policy decision-making code) est contenu dans un composant particulier
du noyau, il permet dtablir les lois appliquer sur le systme, il sappelle rfrentiel de
scurit.
La partie concernant le code dapplication (policy enforcement code) est directement
intgre dans le composant du noyau grant les processus, les systmes de fichier, les IPC (InterProcess Communication) et le rseau, il se charge donc dexcuter et dappliquer les lois dictes
par le rfrentiel de scurit.
Entre ces deux parties, SELinux fournit un systme de cache appel AVC (Acces Vector
cache) pour un accs rapide aux dcisions daccs qui sont dj calcules par le rfrentiel de
scurit.
Flask prsente une architecture indpendante de la politique de scurit mettre en place.
En effet, les interactions entre les entits (Sujets ou objets) suivent un modle bien dtermin:
Chaque entit du systme reoit un label (une tiquette) qui reprsente un contexte de scurit
(Cf. Figure 21) contenant des informations sur lentit elle-mme ainsi que sur les autres entits
avec lesquelles elle va interagir et comment les interactions peuvent se produire.
SELinux attribue chaque contexte un numro identificateur de scurit appel SID
(Security IDentifier), cest la partie Policy enforcement qui se charge de cette attribution. Le SID
avec le contexte correspondant sont enregistrs au niveau du rfrentiel de scurit (Security
server) qui est le seul connaitre leurs significations.
43
Figure 21- Interaction entre sujet et objet

Les objets du systme possdent galement des classes. SELinux dfinit plusieurs classes
dobjets, incluant les:
Dossiers
Descripteurs de dossier
Fichiers Systme
Liens
Processus
Fichiers spciaux de divers types (Block Device, Sockets, FIFO etc.)
Socket
Etc.
Les classes servent identifier la cible des permissions, ainsi chaque classe dobjet sont
associes des permissions, comme openet link pour un fichier, ou listen et accept pour un socket,
le tableau ci-dessous dcrit quelques classes d'objet dfinies par SELinux :
Classe d'objet
Opration
Processus
execute, transition, entrypoint, signaux, fork, ...
Fichiers
read, write, append, execute, open, link, rmdir,

...
Systmes de fichiers
mount, remount, unmount, ...
Descripteurs de fichiers
create, inherit, receive
Sockets(TCP, UDP, raw)
bind, connect, listen, send, accept, ...
Tableau 6-Quelques classes d'objet dfinies par SELinux

44
Lorsquun sujet (un processus) entre en interaction avec un objet (un fichier), le
rfrentiel de scurit prend sa dcision en se basant sur le contexte de scurit du couple (sujet,
objet) en plus de la classe de l'objet. Il existe deux types de dcision :les dcisions daccs et les
dcisions de transition.(Cf. 2.4.5.3 et 2.4.5.4).
2.2.3. Les autres solutions de scurit
Le Framework LSM avait donc lavantage de ne porter que des changements mineurs au
niveau du noyau lors de la mise en place de nimporte quelle solution de scurit, il a cherch
tre indpendant de limplmentation de la politique de scurit. Il existe plusieurs modules de
scurit qui sont maintenus indpendamment du dveloppement du noyau Linux, cest la raison
pour laquelle le tenu de linterface LSM est argument par le fait qu'il peut y avoir plus quun
seul modle de scurit. Parmi ces modules de scurit, il y a :
AppArmor (Application Armor) : qui permet l'administrateur systme d'associer chaque

programme un profil de scurit qui restreint ses accs au systme dexploitation. Il fournit un
contrle d'accs obligatoire en se basant sur les chemins de fichiers, et non sur leurs inodes13.
AppArmor est principalement maintenu par Novell de 2005 Septembre 2007 dans le cadre
de leurs distributions SUSE, mais il est aussi disponible sous la licence GPL dans d'autres
distributions.
LIDS (Systme de dtection d'intrusions Linux) est un patch du noyau Linux, sa premire
version a t conue pour la version du noyau Linux 2.2 et plus tard pour la version 2.4. La
version 2 de LIDS sera transforme en un module pour le framework LSM, il est actuellement
en volution. LIDS comprend plusieurs mesures visant minimiser les dommages en cas de
compromission du systme. Les fichiers peuvent tre marqus comme immuables, et des
modifications aux configurations vitales du systme peuvent tre vites. Mme l'utilisateur
root ne peut pas contourner la protection sans avoir d'abord arrt le systme LIDS, ce qui
ncessite davoir un mot de passe (dfinie au moment de la compilation).
RSBAC (Rule Set Based Access Control) est utilis en production depuis 2000, il constitue
une architecture trs flexible qui reprend les principes de GFAC (Generalized Framework for
Access Control) [30]. Comme SELinux, la modularit de RSBAC a fait de lui un outil facile
dployer sur des environnements dj configurs. Il nemploie pas le mcanisme dattributs
tendus fournis par le systme de fichier comme le fait SELinux (Cf. 2.4.4) pour stocker les
informations de contrle daccs (ACI), mais il utilise simplement un rpertoire appel :
rsbac.dat la racine de chaque partition. Toute configuration de RSBAC se fait
principalement travers des outils en ligne de commande sous le nom dun utilisateur secoff
(officier de scurit). Contrairement la politique de scurit de SELinux, celle de RSBAC,
possde lavantage de ne contenir quun nombre trs rduit de rgle de scurit, bien que le
manque de la documentation et labsence dune politique de scurit standard pour les
services usuels en font un outil complexe utiliser.
2.3. Le modle de scurit de SELinux
En plus de lutilisation du modle DAC (Discretionnary Access Control), SELinux
introduit le modle MAC (Mandatory Access Control) qui intgre les modles reconnus suivants :
13Les inodes contiennent les mtadonnes des systmes de fichiers, et en particulier celles concernant les droits d'accs.
45
Domain and Type Enforcement (DTE) et plus prcisment le modle : Type

Enforcement (TE)
Role-Based Access Control (RBAC)
Multi-Catgorie (MCS)
Multi-Niveaux (MLS) de Bell-Lapadula

Ces modles garantissent :
Lapplication des principes de privilges minimaux et la sparation des pouvoirs.
Le confinement de processus, ce qui permet disoler les codes non fiables et de se

protger contre linjection de code.
La protection des flux dinformation contre les fuites, et ce en mettant en place des
politiques multi-catgories et multi-niveaux.
Lintgrit des applications et de tout le systme notamment les fichiers de

configuration, des excutables et du noyau ainsi que lintgrit des
communications entre processus.
Remarque : le modle DAC et SELinux fonctionnent ensemble. En effet, si le DAC de Linux
classique interdit une action, cette dcision sera respecte sans intervention de SELinux. Par
contre si laction est autorise par le modle DA, SELinux rentrera en jeu et utilisera son
propre mcanisme pour finalement autoriser ou refuser laction.
2.3.1. Le modle Type Enforcement (TE)
Le modle TE, reprend du modle MAC lide de ltiquetage des diffrentes entits du
systme par des labels, cest la manire opte par SELinux pour accorder laccs dun sujet un
objet. Cela consiste lier un attribut de scurit appel type chaque sujet et chaque objet. Le
modle TE traite donc de la mme faon les entits dun mme types au lieu de traiter chaque
entit (sujet ou objet) part. Larchitecture Flask de SELinux donne la possibilit de classifier les
objets du systme afin dassurer une large granularit offrant ainsi au modle TE la possibilit de
diffrentier entre les objets de mme type en ce qui concerne lautorisation laccs.
Figure 22-La couche d'abstraction RBAC
46
Contrairement au modle DTE, le modle TE de SELinux nassocie pas directement les

utilisateurs aux domaines, mais il utilise le modle RBAC (dcrit dans la section2.3.2) pour
fournir une couche d'abstraction supplmentaire entre les utilisateurs et les domaines(Cf. Figure
22ci-dessus).
Les dcisions de scurit caractrisant le modle TE sont de deux catgories : savoir
lesdcisions daccs et les dcisions de transition.
2.3.1.1.
Les dcisions daccs (Access Decisions)
La dcision d'accs permet simplement de savoir si un sujet (application, processus) peut

avoir accs un objet (fichier), il y a donc deux contextes impliqus dans la prise de cette
dcision : le contexte du sujet, le contexte de l'objet en plus de la classe de lobjet. La dcision
daccs et recherche dans un premier temps dans lAVC pour vrifier si une opration similaire
a t calcule et mise en cache par le rfrentiel de scurit. Si une telle dcision ne peut tre
fonde sur des donnes dans l'AVC, la demande continue au serveur de scurit, qui examine le
contexte de scurit du sujet et de lobjet pour rechercher dans une grande matrice (au niveau de
la politique de scurit binaire) qui a t construite partir des rgles de la politique de scurit.
Le rsultat de cette recherche se traduit par la gnration dune liste (contenant des bits 1 pour
Oui et 0 pour Non) appele vecteur d'accs (Access vector) qui prcise toutes les actions
autorises ou refuses avec cet objet. Le Tableau 7ci-dessous montre les actions possibles sur un
vecteur d'accs simplifi pour la classe file :
Tableau 7-Extrait du vecteur d'accs de la classe file

Ce tableau est enregistr dans l'AVC, puis la dcision d'accs est transmise par l'AVC la
partie Policy enforcement pour tre applique.
SELinux dispose de plusieurs formes de rgles de politiques de scurit (exemple :
allow, auditallow, dontaudit), il renvoie alors les trois vecteurs d'accs comme
reprsents sur le Tableau 8ci-dessous:
Tableau 8-Extrait des vecteurs d'accs de la classe file

Les fonctions de ces trois vecteurs d'accs sont les suivantes :
47
allow : permet didentifier les oprations que le sujet est autoris excuter sur l'objet.
Par dfaut, cette opration nest pas journalise (audite).
Exemple:
allow auth_t shadow_t : file {getattr read};
Cette rgle signifie qu'un processus avec le domaine auth_t est autoris (allow) lire
les attributs ({getattr}) et crire ({read}) dans un fichier (file) possdant le type
shadow_t.
auditallow : permet de forcer la journalisation (audit) quand une opration est

effectue aprs avoir t autoris par allow.
Exemple:
auditallow unconfined_t security_t : security { load_policy
setenforce setbool};
Cette rgle stipule que lorsque les processus unconfined_t possdent les permissions
load_policy, setenforce et setbool sur les objets de type security_t, alors
ces oprations doivent tre journalises.
dontaudit : permet arrter l'audit des oprations quun sujet n'est pasautoris
effectuer sur un objet.
Exemple:
dontaudit named_t root_t : file {getattr read};
Cette rgle stipule que lorsque les processus named_t ne sont pas autoriss lister les
attributs {getattr} ni lire {read} le contenu des fichiers (file) de type
(root_t), alors ces oprations ne doivent pas tre journalises.
Exemple de message de refus daccs :
Il sagit dun extrait de fichier de journalisation /var/log/messages, dans lequel on
peut
remarquer que cest le couple de contextes source (tcontext) et cible
(scontext) qui dtermine le sort de lopration daccs (dans notre cas utilisation de
lditeur vi). Le message derreur audit lors dune tentative dutilisation de lditeur vi
est:
textbf{avc: denied { write } for pid=4025 comm="vi"

name="messages"
dev=sda1ino=54
scontext=unconfined_u:system_r:hotplug_t:s0tcontext=sy
stem_u:object_r:nfs_t:s0 tclass=file }
Extrait 1- Extrait du fichier /var/log/messages

48
2.3.1.2.
Les dcisions de transition
Les dcisions de transition se traduisent par le passage dun type un autre pour chaque
objet cre sollicitant un contexte par dfaut autoris par la politique de scurit. Ainsi le type
dun fichier nouvellement cr dpondra du contexte de son rpertoire parent et surtout du
contexte (spcialement le type) du processus qui la cr. En effet, un fichier cre par un
utilisateur normal naura pas le mme type sil a t cr par un processus spcial. Il en est de
mme pour le changement de contexte (spcialement le domaine) dun processus en vue
deffectuer une tche bien prcise qui ncessite des privilges autres que ceux lis son contexte
source.
Lutilit des rgles de transition est de limiter le comportement anormal des processus. En
effet, sans SELinux, on remarque quil y a une vulnrabilit lors de la procdure de changement
du mot de passe par un utilisateur sur lancien systme Linux (Cf. 2.4.5.3).
2.3.2. Le modle Role-Based Access Control (RBAC)
Le modle original de RBAC assigne des rles aux utilisateurs, et associe des permissions
ces rles. Le rle dans SELinux est un groupe qui possde lautorisation daccs un ensemble
de domaines TE.
Le fonctionnement de RBAC dans SElinux est compos de deux parties, la premire
consiste assigner des rles aux utilisateurs et la seconde associe un domaine TE au shell de
lutilisateur :
Assignation de rle : Lorsquun utilisateur se connecte partir des programmes de

connexion (login, sshd, gdm), ceux-ci lui attribue un rle. Cest la politique de
scurit qui contient la rgle stipulant quun tel utilisateur est autoris jouer ce genre de
rle (voir lutilisation du vecteur d'accs allow ci-dessus).
Affectation de domaine : Le rle prsente une manire de confiner le comportement dun

utilisateur, ainsi le shell utilisateur se voit obligatoirement attribuer un domaine TE en
fonction de son rle.
2.3.3. Les modles MCS et MLS de Bell-Lapadula
Dans SELinux, le modle MLS (Multi-Niveau) prsente une extension optionnelle du
modle TE. Quand il est activ, le contexte de scurit est tendu en deux champs additionnels :
Le champ Low Security Level etle champ Hight Security Level, qui dsignent respectivement le
niveau bas et le niveau haut de scurit.
Le niveau de scurit est compos, lui aussi, de deux champs : le premier dsigne la
sensibilit (sensitivity) et le second dsigne un ensemble de catgorie. Les valeurs du champ
sensitivity constituent un ensemble ordonne par la relation (<, =, >).
Exemple:Top Secret > Secret >Unclassified.
Les valeurs du champ categories constituent un ensemble dlments non ordonns.
Ce champ possde le rle de cloisonner les entits dans des compartiments spcifiques.
Le principal apport de scurit de MCS et de MLS est quon ne peut avoir accs un objet
que si on dispose suffisamment de sensibilit et quon est autoris accder au compartiment
dmarqu par la catgorie de lobjet.
49
La combinaison entre une sensibilit avec un ensemble de catgories constitue le niveau

de scurit dune entit objet ou sujet. SELinux propose 16 niveaux de scurit (s0,...,s15) et 1024
catgories (c0,...,c1023).
Notons que le format de contexte (Cf. 1) de scurit SELinux se prsente comme suit :
Identit:Rle:Type/domaine [: niveau(MLS): Catgorie(MCS)]
Exemple:
user_u:system_r:system_t[:s0:c0.c16]
Ce contexte signifie que lidentit SELinux user_uest mis dans le rle system_rqui
est confin dans le type system_t. user_u possde le niveau de scurit s0:c0.c16
cest--dire de sensibilit s0 et est cloisonner dans le compartiment c0.c16.
Il est possible dexprimer les contraintes sur les niveaux de scurit dun contexte pour
lesquelles MLS et MCS sont activs. Pour cela, SELinux utilise les mots cls mlsconstrain et
mlsvalidatetrans pour dfinir deux types de contraintes, en voici deux exemples :
Exemple 1:
mlsconstrain file write ( l1 domby l2 );
Cette contrainte, oblige que tout processus qui tente dcrire dans un fichier de niveau
l1doit davoir un niveau l2 infrieur l1. Cela revient limiter les permissions d'criture pour
la classe file ayant le niveau de scurit source l1 domin par le niveau de scurit des objets
l2. (no write down).
Exemple 2:
mlsvalidatetrans file (( l1 eq l2 ) or ( l2domby l1));
La contrainte mlsvalidatetrans peut tre utilise lorsquun objet sollicite un
changement de son niveau de scurit, lExemple2 montre que notre contrainte exige quun
fichier ne peut changer son niveau de scurit que si les deux niveaux source et cibles sont gaux,
ou si le niveau de scurit cible est domin par le niveau de scurit source.
Il est noter que chaque utilisateur doit avoir un niveau d'habilitation de scurit dfinie,
qui reprsente le plus haut niveau du processus qui sexcute en son nom.
2.4. La politique de scurit SELinux
2.4.1. Contexte de scurit
SELinux reprsente le contexte de scurit par une chane constitue de trois (ou quatre)
champs spars par le caractre : (deux points). Chaque champ spcifie un composant du
contexte de scurit, savoir : l'utilisateur, le rle, le type et le niveau de ce fichier ou ce
processus:
Identit : Rle: Type/domaine [: niveau(MLS): Catgorie(MCS)]
Le contexte de scurit dun fichier est stock sous forme d'un attribut tendu : extended
attributes (en abrg xattr). Ce contexte peut tre visualis en utilisant la commande ls avec
loption -Z. On peut utiliser Aussi la commande chcon pour changer le contexte dun fichier.
50
SELinux garantit que le contexte de scurit dun fichier restera toujours le mme, mme aprs
lavoir renomm ou dplac nimporte o dans larborescence. Il est donc associ directement
l'inode du fichier.
2.4.1.1.
Identit de lutilisateur
L'identit de lutilisateur est la premire composante du contexte de scurit, elle indique

le compte SELinux de l'utilisateur li un sujet ou un objet. Dans le cas d'un objet, l'identit de
l'utilisateur est celui qui possde l'objet. Dans le cas d'un sujet, son identit SELinux est celui sous
lequel le processus est excut, un sujet conserve son identit tout au long de sa session ce qui
permet limputabilit (la traabilit) des actions sur le systme mme aprs lexcution de la
commande su (ou sudo). Toutefois, il peut y avoir des exceptions la rgle de persistance des
identits SELinux, et ce dans les deux cas suivantes :
Laffectation de lidentit initiale dun utilisateur : authentification par des processus
comme : login, ssh, gdm.
Lexcution dun processus sous une autre identit: utilisation de la commande cron.
Pour contrler lidentit des utilisateurs, SELinux utilise sa propre base de donnes et
tabli un mappage qui lie les identits des utilisateurs Linux UID (User IDentifier) avec celles de
SELinux (ID), le fichier /etc/passwd de linux nest donc pas employ pour mettre en place ce
contrle. Cela confirme lide que le modle DAC de Linux et le modle MAC de SELinux sont
indpendant et distincts.
Dans la majorit des distributions Linux, SElinux attribue chaque utilisateur (ou
processus) une des identits prdfinies dans la politique de scurit (Cf. 1), ces identits sont
fourni comme suit :
root : est lidentit SELinux quon obtient quand on se connecte sur la console en tant
quutilisateur Linux : root.
system_u : est lidentit SELinux par dfaut des processus excuts durant la phase de
dmarrage.
user_u : est lidentit SELinux obtenue par dfaut pour un utilisateur connect sur le
systme.
Remarque : chaque distribution peut ajouter des identits spcifiques, En effet, par exemple la
distribution Gentoo ajoute deux autres identits : staff_u et sysadm_u.
2.4.1.2.
Rle
Le rle de lutilisateur est la seconde composante du contexte de scurit, il est li au

modle RBAC. La politique de scurit SELinux dfinit un ensemble de rles ainsi que les
utilisateurs qui ont accs ces rles, chaque rle reprsente un ensemble de types grer.
Quand un utilisateur se connecte et s'authentifie auprs du systme il se trouve, un
instant donn, dans un rle parmi un ensemble de ceux qui lui sont autoriss. Il peut galement
effectuer une transition pour passer dun rle un autre dans une mme session (voir utilisation
de la commande newrole -r).
Le rle dfinit les autorisations SElinux dont dispose un utilisateur (ou un processus) sur
des objets, en gnral, il existe cinq rles dont quatre sont explicitement prdfinis :
system_r, user_r, staff_r et sysadm_r.
51
Le rle object_r est assign tous les fichiers, il ne se trouve pas explicitement dans la
politique de scurit SElinux, car la notion de rle pour les fichiers nest pas obligatoire et que si
un fichier requiert un niveau de scurit, alors un type TE spcifique lui sera assign. Le tableau
suivant montre comment les identits SElinux sont combines avec les rles lors de la connexion
dun utilisateur:
Identits SELinux
Rles
system_u
system_r
user_u
user_r
staff_u
staff_r, sysadm_r
sysadm_u
sysadm_r
root
staff_r, sysadm_r
Description
Pour les processus systmes (noninteractifs). Ne devrait pas tre attribue
un utilisateur.
Pour les utilisateurs sans privilge. La
correspondance par dfaut.
Pour les administrateurs systmes qui se
connectent galement pour excuter des
tches d'utilisateur normal.
Pour les administrateurs systmes qui ne
font que se connecter pour excuter des
tches administratives. Il est suggr de
ne pas utiliser cette identit.
Identit spciale pour root. Les autres
utilisateurs devraient plutt utiliser
staff_u la place.
Tableau 9- Description des identits et rles des utilisateurs SELinux.
La transition entre les rles : Role1 et Role2 se fait en utilisant la rgle suivante :
allow Role1 Role2
Un rle Role1 peut tre assign un type Type1 par la commande suivante:
role Role1 type Type1
Remarque : Par convention on utilise le suffixe _r pour identifier les noms des rles.
2.4.1.3.
Type
Llment : type (pour un objet) qui est galement connus sous le nom : domaine (pour un
sujet) utilis dans le modle DTE, est un identifiant dfini par lauteur de la politique de scurit
qui dtermine sa signification selon son utilisation dans ladite politique. Par exemple, un script de
/etc/rc.d est un programme de type initrc_t.
Un type SELinux mlange des sujets et des objets ayant les mmes autorisations. Les
processus dun mme domaine et les objets dun mme type sont traits de faon identiques.
SELinux se base essentiellement pour la prise de dcision daccs sur llment type (ou
domaine) qui confine les processus dans des sandboxes lesquels empchent l'escalade des
privilges en offrant un environnement contrl.
Une politique de scurit SELinux peut tre dfinie seulement avec quelques utilisateurs et
rles, mais des dizaines voire mme des centaines de types, ce qui justifie leurs importances.
Pour des raisons de simplicit on utilise la notion dattribut pour construire des ensembles de
types afin doctroyer, par exemple des autorisations groupes ou de diffrencier entre les types
et/ou les domaines. Les attributs sont donc utiliss pour mieux grer les politiques complexes.
52
Laccs dun processus un fichier se fait seulement lorsque le serveur de scurit trouve
une rgle de type allow (ou dontaudit ou auditallow) qui donne la permission au
domaine source davoir accs au type selon lopration dsire. Il en est de mme lorsquun
processus veut excuter une opration impliquant un autre processus, ou le processus lui-mme.
La politique de scurit reprsente le cur de SELinux, elle spcifie les rgles dans un
environnement dimplmentation des modles TE et RBAC, et elle est crite par un langage conu
spcialement pour crire les politiques de scurit.
La politique de scurit SELinux dfinit les diverses rgles qui noncent comment les
domaines peuvent accder aux types. Par dfaut, et hormis celles qui sont explicitement permises
par une rgle de scurit approprie, toutes les oprations sont refuses puis audites dans le
rpertoire /var/log/messages (cas des distributions : RedHat et Fedora) ou
/var/log/audit, gnralement la valeur de la variable denvironnement: $AUDIT_LOG
indique lemplacement des fichiers de journalisation des dcision de refus daccs.
Ladministrateur de la politique de scurit peut la dfinir en modifiant les fichiers de
scurit existant, tel est le cas des distributions Fedora et RedHat qui proposent des politiques
toutes faites pour les cas courants, ou en ajoutant dans larborescence des fichiers de contextes de
scurit. Il est noter quune politique de scurit peut tre installe chaud dans le noyau.
Dans les paragraphes suivants nous allons expliquer comment la politique est charge
durant la phase de dmarrage du systme par le processus init.
Avant quelle soit charge dans le serveur de scurit du noyau, la politique est compile
dans un format binaire. De cette manire SELinux dfinit dune part, toutes les composantes des
contextes de scurit (identit:rle:type) pour chaque objet et chaque sujet et dautre part les
autorisations daccs et de transition des domaines aux types. SELinux permet travers sa
politique de scurit, de restreindre la visibilit dun processus sur lensemble du systme et de
ses objets.
2.4.2. Fichiers et rpertoires lis la politique de scurit
Avant dnumrer les diffrents fichiers et rpertoires qui constituent la politique de
scurit dploye par des distributions de Linux, il est rappeler que SELinux est install et
activ par dfaut sous les distributions : Fedora, CentOS et RedHat. Cependant le package de
SELinux nest pas install sur dautres distributions comme Gentoo. Le tableau suivant montre
lemplacement des rpertoires source de SELinux pour quelques distributions :
Distribution
Debian
Fedora
RedHat
Rpertoire source (directory-policy)

/etc/selinux
/etc/security/selinux/src/policy
/etc/selinux
Tableau 10-Rpertoires source de quelques distributions

Le rpertoire directory-policy de chaque distribution contient le fichier config et les
sous-rpertoires : strict et targeted.
directory-policy /config : dsigne le fichier de configuration par dfaut de

la politique de scurit. Il contient deux variables d'environnement: SELINUX et
SELINUXTYPE qui dterminent le type de la politique de scurit appliquer. La
premire variable ( savoir SELINUX) peut avoir les valeurs suivantes : Enforcing,
permissive ou disabled :
53
enforcing La politique de scurit de SELinux est applique.

Permissive Le systme SELinux met des messages d'avertissements mais
n'applique pas la politique (utile pour le dbogage) ou la rsolution de problmes.
En mode permissif, tous les refus seront journaliss ainsi les sujets seront en
mesure de poursuivre des actions qui, en mode enforcing, seraient par contre
refuses.
disabled SELinux est dsactive.
L'autre paramtre ( savoir SELINUXTYPE) admet galement deux valeurs: targeted

et strict:
targeted Seuls les dmons rseau cibls sont protgs.

StrictLa protection SELinux est totale et ce, pour tous les dmons. Les
contextes de scurit sont dfinis pour tous les sujets et objets et toute action est
traite par le serveur d'application des politiques.
Par exemple, RedHat 4(RHL4) utilise une scurit par dfaut qui est telle que :
SELINUX=enforcing et SELINUXTYPE=targeted.
En fait, enforcing est le mode de politique de scurit utilis par dfaut dans la
plupart des distributions de SELinux.
directory-policy /targeted : dsigne le rpertoire de la politique dite

cible, on y trouve la politique source et la politique binaire :
directory-policy /targeted/policy/ce
sous-rpertoire
contient le fichier binaire de la politique de scurit : policy.NO (cas de RHL4).
directory-policy /targeted/src/policy/
ce
sousrpertoire contient les fichiers sources de la politique de scurit.
directory-policy /targeted/contexts/ce
sous-rpertoire
contient les fichiers de configuration et dinformation sur les contextes de scurit.
directory-policy /strict/ dsigne le rpertoire de la politique cible.
/selinux : est un pseudo systme de fichiers similaire au procfs, sysfs, /proc

ou /sys, il est utilis pour la communication entre le noyau et les utilisateurs
(processus), ou pour changer les flags tels que la politiques boolennes ou pour basculer
entre les modes permissive et enforcing, il peut enfin servir pour trouver l'tat
actuel des diffrentes parties du systme SELinux.
Libselinux: bibliothque de fonctions utilisables par les applications/programmeurs.
2.4.3. tiquetage du systme au dmarrage
SELinux joue un grand rle au cours des premires tapes du dmarrage du systme. En
effet, tous les processus doivent porter une tiquette avec leurs domaines appropris, le processus
init excute certaines oprations essentielles dans le processus de dmarrage pour maintenir la
synchronisation entre l'tiquetage et lapplication de la politique.
Aprs le chargement du noyau durant le processus de dmarrage, un SID initial : kernel,

prdfinie est assign au processus initial. Les SID Initiaux sont utiliss pour l'amorage
avant que la politique soit charge.
54
Le processus/sbin/init monte la partition /proc/, et cherche ensuite le type

selinuxfs du systme de fichiers. S'il est prsent, cela signifie que SELinux est activ
dans le noyau.
Si le processus init ne trouve pas SELinux dans le noyau, ou si SELinux est dsactive
via le paramtre de dmarrage selinux=0, ou si le fichier directorypolicy /config spcifie que le paramtre SELINUX=disabled, le systme est
donc dmarr par le processus du boot sans SELinux.
Au mme temps, init dfinit ltat enforcing si cette valeur est diffrente de celle du
paramtre SELINUX du fichier directory-policy /config. Cela survient
lorsquun paramtre est pass au cours du processus de dmarrage, telles que
enforcing=0 ou enforcing=1. Le noyau napplique aucune politique jusqu' ce
que la politique initiale soit charge.
Si SELinux est prsent, la partition /selinux/ est monte.
Le noyau cherche dans le rpertoire /selinux/policyvers la version de la politique

supporte, init consulte ensuite le fichier directory-policy/config pour
voir quelle politique est actuellement applique par SELinux (exemple : targeted), puis
recharge le fichier associ:
directory-policy /targeted/policy/policy.<version>.Si
la
politique binaire nest pas supporte par le noyau, init va tenter de charger la version
prcdente toute en assurant la compatibilit des versions.
La politique est maintenant entirement charge dans le noyau. Les SID initiaux sont
ensuite mapps des contextes de scurit dans la politique telle quelle est dfinie dans
le
fichier: directorypolicy/targeted/src/policy/initial_sid_contexts. Dans le cas
dune
politique
cible
targeted,
le
nouveau
domaine
est:
user_u:system_r:unconfined_t. par la suite le noyau peut commencer
rcuprer dynamiquement des contextes de scurit partir du serveur de scurit dans le
noyau.
init sauto-excute afin qu'il puisse tablir une transition vers un autre domaine,
videment si une rgle de la politique lautorise. Pour la politique cible targeted, le
processus init reste dans le domaine unconfined_t puisquil ny a aucune
transition dfinie dans la politique.
init poursuit normalement le processus de dmarrage.
2.4.4. Systmes de fichiers et attributs tendus.
SELinux utilise les attributs tendus xattr: extended attributes pour stocker des
tiquettes de scurit sur chaque fichier. Ces attributs tendus ncessitent l'utilisation de systmes
de fichiers ext2, ext3 et JFS. Le systme de fichiers XFS est galement support mais
prsente des limites comme loccupation d'espace disque qui ralentit par la suite le systme
cause des oprations supplmentaires pour chaque fichier. Le systme de fichier ReiserFS n'est
pas compatible avec ces attributs tendus.
Le tableau suivant dcrit brivement les systmes de fichiers qui sont disponibles dans le
noyau Linux :
55
Systmes de fichiers
ext2
ext3
JFS
ReiserFS
Description
est un systme de fichiers qui ne journalise pas les mtadonnes,
c'est--dire que le systme prend un temps considrable pour la
vrification du systme de fichier lors de la phase de dmarrage.
Est un systme de fichier trs fiable, stable et performant, cest
la version journalise du systme de fichiers ext2, il minimise le
temps dattente lors dun dmarrage du systme.
Est le systme de fichiers journalis hautes performances
d'IBM. C'est un systme rapide et sr avec de bonnes
performances dans diverses configurations.
Tout comme le JFS, ReiserFS est un systme de fichiers
journalis qui prsente de trs bonnes performances, il est
apparemment moins maintenu que les autres systmes de
fichiers.
Tableau 11- Les systmes de fichiers les plus utiliss sur les systmes Linux
SELinux peut galement monter les systmes de fichiers annexes, tels que vfat14(Virtual
FAT) etiso966015, mais avec une grande restriction : tous les fichiers du montage auront le
mme type SELinux, puisque le systme de fichiers ne supporte pas les attributs tendus. Tmpfs
est le seul systme de fichiers annexe supporter les attributs tendus.
2.4.5. Rgles du modle TE
Les dclarations TE (Type Enforcement) sont les principales composantes de la politique
de scurit. On trouve les dclarations dattributs et les dclarations de types :
2.4.5.1.
Dclarations dattributs
Un attribut est un nom qui identifie un ensemble de types qui ont une proprit similaire.
Les attributs peuvent tre utiliss lors de la dclaration d'un type et peuvent tre associs un
nombre quelconque de types. Les attributs peuvent tre utiliss lors de la spcification des
permissions sur les types, on dclare les attributs dans le fichier de dclaration directorypolicy/targeted/src/policy/attrib.te de la faon suivante :
attribute Nom_Attribut;
Exemple :
attribute domain1 ;
Cet exemple reprsente la dclaration dun attribut qui peut tre utilis pour dsigner un
ensemble de types regroups sous le nom domain1.
2.4.5.2.
Dclarations de types
Le langage de configuration TE exige que chaque type soit dclar. Chaque dclaration de
type spcifie un nom principal pour le type, un ensemble facultatif d'alias pour le type, et un
14
vfat est u e e te sio des s st es de fichie s de t pe FAT de Mic osoft ui pe et lutilisatio de noms de fichiers longs
ISO 9660 est une norme de l'Organisation Internationale de Normalisation, qui dfinit le systme de fichiers utilis sur les
CDROM.
15
56
ensemble facultatif d'attributs pour le type. La syntaxe d'une dclaration de type est la
suivante:type Nom_type Alias Atributs;
Exemple :
type LeType_t, domain1;
Danscet exemple, il sagit de la dclaration de type LeType_t ayant lattribut domain1.
2.4.5.3.
Transition de type
Une transition de type dfinit le rsultat de la dcision de ltiquetage (labeling decisions)

en spcifiant un nouveau domaine pour un processus nouvellement cr ou un nouveau type pour
un nouvel objet.
Pour les processus, le type source est process et le type cible est le type de
l'excutable. Si la transition est sur des objets, le type source est le domaine du processus de
cration et le type cible est le type de l'objet.
Sil n'existe aucune rgle de transition entre le type source et le type cible, l'tiquette des
nouveaux fichiers et des processus est calcule en fonction des contextes de leurs parents. Pour
les fichiers, cela signifie qu'ils recevront le type du rpertoire parent. Pour les nouveaux
processus, cela signifie qu'ils seront excuts dans le mme domaine que celui du processus de
cration.
2.4.5.4.
Transition de domaine
Dans tout ce qui suit, la notion de transition de domaine est illustre travers deux
exemples, Lun concerne la transition de domaine au dmarrage tandis que lautre traite la
transition de domaine lors de lexcution dune application, elle sera illustre par le programme
de changement de mot de passe:
a. Transitions des domaines au dmarrage
Au dmarrage dune machine Linux dont SELinux est install et est activ, chaque
processus nouvellement cre se voit attribuer un domaine appropri, commenant par le
domaine de lancement kernel_t du processus 1jusquaux domaines des processus du
login.
La Figure 23[32] prsente un diagramme qui montre les transitions de domaine au
dmarrage du systme. Il fait ressortir les noms des types/domaines et des macros utiliss
pour mettre en uvre les transitions.
SELinux utilise le langage des macros appel m4 pour l'criture des rgles de politique
rutilisables. Cela facilite la rdaction et par la suite la gestion de la politique de scurit.
Deux macros : domain_auto_trans() et domain_trans() assurent les transitions des domaines
des processus de dmarrage. Ils sont paramtrs et contiennent des rgles telles que : allow,
type_transition, etc.
Au dmarrage du systme, les transitions suivantes entre les domaines seffectuent :
Le processus 1 est lanc avec le domainekernel_t.

57
kernel_t lance init, en le mettant en init_t (le type du fichier dans lequel on
trouve le code dinit est init_exec_t).
init_t lance le script dinitialisation initrc dans le domaine initrc_t, ainsi que
la console dans getty_t.
La console lance le processus de saisie de login/(mot de passe) dans le domaine
local_login_t (ou login_t)
Lorsquun utilisateur se connecte, son shell sera plac dans user_t (ou
unconfined_t) la suite dune transition de domaine enclenche par
local_login_t (ou login_t).
Tous les dmons lancs par initrc sont placs dans leur domaine par des rgles de
transition de type appropries.
Figure 23-Transition de type au dmarrage[32]

b. Transition de domaine lors de lexcution dune application
La transition de domaine pendant lexcution dune application est illustre par la
procdure de changement, par un utilisateur du systme, de son mot de passe. Ladite transition
est gre par un mcanisme de scurit qui sajoute au mcanisme classique de Linux qui emploi
le bit SetUID. Dans ce qui suit nous allons montrer les mcanismes utiliss par Linux classique
et par SELinux pour effectuer le changement du mot de passe dune faon scuritaire.
La solution classique de Linux : Un processus tourne gnralement avec les mmes

permissions que celles de l'utilisateur qui la lanc. Toutefois, les processus des commandes (ou
des programmes) ayant le bit SetUID (parfois appel SUID, abrviation de Set User IDentifier)
ne se conforment pas cette rgle et sont excuts avec les permissions du propritaire de la
commande.
58
Un utilisateur ordinaire ne peut pas changer son mot de passe en ditant directement le
fichier /etc/shadow(/etc/passwd pour les systmes Unix classiques), il n'a donc pas les
permissions suffisantes pour crire dans ce fichier. Par contre la commande usr/bin/passwd
peut le faire sa place puisquelle possde lautorisation spciale SUID qui lui permet d'accder
au fichier shadow sur lequel Il n'y a que le root qui possde les permissions de lecture et
d'criture.
Bien que cette technique ait rsolu beaucoup de problme, elle possde le risque de
compromettre la scurit de tout le systme puisque le processus qui excute la commande
passwd dispose automatiquement de tous les droits que lutilisateur root possde tout au long
de lexcution de cette commande. En effet, puisque la commande /usr/bin/passwdest la
proprit de lutilisateur root et non pas de lutilisateur qui la lanc, le fichier /etc/shadow
qui est lui aussi la proprit du root (Cf. Listing 1), peut tre modifi par nimporte
quelle processus ayant lutilisateur root comme propritaire :
# ls -la /etc/shadow
-rw-r----- 1 root root 1543 Feb 10 11:43 shadow
Listing 1- Le propritaire du fichier /etc/shadow
La solution SELinux : La solution apporte par SELinux pour rsoudre le problme de

changement de mot de passe consiste attribuer le type shadow_t au fichier/etc/shadow et
de ne laisser aucun processus le modifier sauf sil tourne dans le domaine passwd_t, ce type
doit tre autoris, explicitement par une rgle de la politique de scurit, modifier dans les
fichiers ayant le type shadow_t.
Lorsquun utilisateur ordinaire se connecte au systme, son processus Shell tourne dans le
domaine unconfined_t(domaine des processus utilisateurs ordinaire). SELinux assure,
travers une rgle de transition, le changement du domaine user_t du shell vers le domaine
passwd_t du processus excutant la commande passwd. Lide de la transition des types est
donc analogue celle du concept du bit SUID.
Dans le scnario prsent par le mcanisme des mots de passe, on trouve quatre types qui
entrent en jeux :
unconfined_t
passwd_t
shadow_t
passwd_exec_t
Le domaine dans lequel le Shell de lutilisateur sexcute.
Le domaine o le programme des mots passe tourne.
Le type de fichier des mots de passe comme : /etc/shadow.
Le type du fichier excutable (la commande)passwd.
Les domaines et types ci-dessus sont utiliss par des rgles de la politique de scurit
(Type Enforcement), de la faon suivante:
La premire rgle :
allow unconfined_t passwd_exec_t : file {getattr execute};

59
Cette rgle permet au shell, qui tourne dans le domaine unconfined_t de lutilisateur
sollicitant le changement de son mot de passe, dexcuter (etpar consquent dinitier un appel
systme execve()) la commande passwd qui possde le type passwd_exec_t.
Le shell consulte les autorisations du fichier passwd avant d'essayer de lexcuter, d'o
la ncessit davoir lautorisation getattr en plus de execute.
La deuxime rgle :
allow passwd_t passwd_exec_t : file entrypoint;

Pour cette rgle, les excutables de type passwd_exec_t servent de point d'entre
pour le type passwd_t. Et quand un processus marqu unconfined_t lance un fichier de
type passwd_exec_t, le processus cr possde finalement le type passwd_t. Il s'agit d'un
contrle de scurit puissant qui garantit quuniquement le programme de mot de passe puisse
tre excut dans le domaine passwd_t du moment o :
Seul le fichier excutable passwd est tiquet avec passwd_exec_t.

le type passwd_t est le seul qui a la permission entrypoint servant de point
d'entre au type passwd_exec_t.
On peut entrer dans passwd_t seulement avec une application de type
passwd_exec_t, laquelle ne peut qu'excuter des librairies permises (lib_t) et ne
peut pas dmarrer d'autres applications.
La troisime rgle :
allow unconfined_t passwd_t : process transition;

Il sagit dune rgle de scurit allow utilisant la permission transition qui est
ncessaire pour permettre le changement du type d'un processus.
Le type d'origine unconfined_t doit avoir la permission de transition vers le nouveau
type passwd_t pour que la transition de domaine soit autorise.
La quatrime rgle:
allow passwd_t shadow_t : file {iocl read write create

getattr setattr lock relabelfrom relabelto append unlink link
rename};
Cela signifie que seuls les processus tournant dans le domaine passwd_t puissent
excuter les oprations :{iocl, read, write, create, getattr, setattr,
lock, relabelfrom, relabelto, append, unlink, link, rename}sur les
fichiers de type shadow_t, ce qui veut dire que seul passwd_t peut crire dans
shadow_t.
En cas gnral passwd_t ne peut crire que dans shadow_t et etc_t.
La rgle principale :
type_transition unconfined_t
passwd_exec_t : process
60
passwd_t;
Cette rgle est introduite pour supporter les transitions qui se produisent par dfaut, elle
sappelle la rgle de transition de type : type_transition, elle spcifie les transitions par
dfaut qui devrait se produire si aucune transition explicite nest prsente.
Gnralement les rgles type_transition sont dfinies par des macros qui les
combinent avec un ensemble de rgles TE (dans notre exemple, il sagit des rgles
susmentionnes).
Dans cet exemple, la rgle type_transition indique que, par dfaut et lors dun
appel systme execve(), si le processus appelant est de type unconfined_t et le type du
fichier excutable est passwd_exec_t, une transition de domaine vers un nouveau domaine
passwd_t se produirait.
2.5. Mise au point sur les travaux de recherche utilisant les modles de contrle d'accs
dans SELinux
2.5.1. Le modle RBAC dans SELinux.
2.5.1.1.
Lusage gnral du modle RBAC
En 1992, David et Rick Ferraiolo Kuhn ont propos dans[24] un usage gnral du modle
RBAC, lequel a intgr les proprits des approches existantes des applications spcifiques.
RBAC est devenu le plus dominant des modles de contrle d'accs. En effet, Il a t considr
comme une alternative au modle MAC (Mandatory Access Control) et au modle DAC
(Discretionary Access Control).
2.5.1.2.
Les modles constituant RBAC
En 1996, Ravi et al. ont introduit dans [7]un Framework pour les modles RBAC qui
intgrent les fonctionnalits suivantes :
RBAC0 a t dfini comme tant le modle de base, dfinie travers les utilisateurs, les
rles et les autorisations.
RBAC1 comprend RBAC0 mais incorpore des hirarchies comme une relation d'ordre
partiel entre les rles.
RBAC2 intgre galement RBAC0, mais ajoute des contraintes. RBAC1 et RBAC2 sont
indpendants les uns des autres, de telle sorte quun systme peut mettre implmenter un
sans lautre.
RBAC3 est un modle qui rassemble pleinement les proprits de RBAC, incorporant
RBAC0, RBAC1, et RBAC2. RBAC3 est quivalent au modle[24], l'exception de
RBAC3 qui permet une hirarchie d'ordre partiel alors que le modle [24] dfinit la
hirarchie comme un arbre enracin.
En termes orients objet, le modle [7] peut tre considr comme incorporant l'hritage
multiple alors que [24] utilise l'hritage unique.
61
2.5.1.3.
Logique de description: modlisation de la hirarchie des rles
Zhao et al. [33] montrent comment utiliser la Logique de description pour modliser la
hirarchie des rles, des permissions et sessions qui lui sont associs. Elle ne couvre pas les
autres types de contrles de scurit trouvs dans SELinux, mais dfinit une structure pour la
modlisation de RBAC et montre comment effectuer des requtes sur le modle.
2.5.1.4.
Formalisation des modles de contrle daccs de SELinux
Dickerson[34] sinspire de [33] pour montrer comment formaliser les modles de

contrles d'accs utilis par SELinuxen invoquant des requtes travers un langage appel :
{ALCQ}.
2.5.1.5.
Description de lintgration de RBAC au modle TE
Hallyn[35] dcrit la confusion apparente qui rsulte de la manire dont RBAC est intgr
au modle Type Enforcement (TE), car la politique de scurit implment dans SELinux et Type
Enforccement (TE) sous une couche RBAC, le modle MLS y est galement implment dune
faon optionnelle.
SELinux spcifie laccs bass sur les rles en terme de TE, Cependant, le but de RBAC
dans SELinux est de permettre la gestion des privilges bass sur les rles que chaque utilisateur
autoris puisse jouer, ensuite de restreindre laccs des rles aux domaines dinfluence (domaines
de scurit sur le systme) toute en ayant un contexte valide dans lequel on peut combiner le rle
avec les types/domaines correspondant.
TE est le plus prsent en matire de scurit, car il est le plus probablement responsable
de tout refus daccs dun sujet a un objet donn.
Enfin, larticle montre travers un simple exemple comment RBAC et TE sont
troitement intgrs.
2.5.2. Le modle Type Enforcement
2.5.2.1.
TE un mcanisme de contrle daccs orient-table.
Boebert et Kain[36] proposrent le modle Type Enforcement (TE) comme tant un

mcanisme de contrle daccs orient-table.
2.5.2.2.
implmentation de TE dans le systme LOCK
OBrien et Rogers [37] montrent quune implmentation complte de TE a t dveloppe

dans le systme {LOCK} (LOgical Coprocessing Kernel), car vers la fin de lanne 1980, le
modle TE a t introduit seulement dans larchitecture Secure Ada Target.
62
2.5.2.3.
Implmentation du modle DTE dans UNIX
TIS (Trusted Information Systems)16 conservait son systme DTE (Domaine and Type
Enforcement) bas sur (Berkeley Software Distribution) BSD17, qui est connu dtre au
dmarrage de FreeBSD18[38].
TIS implmente le modle DTE dans ses pare-feu propritaires, mais les dtails de son
implmentation ne sont pas accessibles au public, et TIS semble avoir cess d'utiliser DTE.
2.5.2.4.
limplmentation du modle DTE sous Linux
Hallyn et al. [39]ont dtaill limplmentation du modle DTE sous Linux, offrant ainsi
aux administrateurs systme un avantage en matire de la scurisation de ses systmes. Ils ont
invoqu galement, sur la base d'une politique qui est lu au dmarrage, les points suivants :
Le contrle d'accs des domaines aux types.
Les transitions de domaine.
L'accs de signal entre les domaines.

2.5.2.5.
Description de larchitecture SELinux
Loscocco et Smalley [40]dcrivent l'architecture et les mcanismes de scurit, les

interfaces de programmation (Application Programming Interface ou API), la configuration
politique de scurit et les performances de SELinux.
2.5.2.6.
TE et objectif de scurit SELinux
Loscocco et Smalley [41] dcrivent la faon dont SELinux a t utilis pour rpondre un
certain nombre dobjectifs de scurit du systme. Ils montrent comment la configuration TE
rpond un ensemble spcifique d'objectifs de scurit. Ils fournissent et expliquent des
exemples dtaills de la configuration pour chaque objectif fix :
La limitation de l'accs aux donnes brutes
La protection de l'intgrit du noyau
La protection de l'intgrit du systme de fichiers

Le confinement des processus privilgis
La sparation des processus.
La protection du domaine de l'administrateur.
16
Trusted Information Systems fait maintenant partie du Network Associates(NAI)
BSD dsigne une famille de systmes d'exploitation Unix

FreeBSD est le systme d'exploitation BSD libre
17
18
63
2.5.3. Le modle RSBAC dans Linux

Le modle RSBAC a t propos en 1997 par Amon Ott sous forme dun travail de thse
[42] de master rdige en allemand et qui proposait le modle Rule Set Based Access Control
(RSBAC) comme une extension du noyau. Il introduit un framework de scurit conu pour
installer, dune faon dynamique, diffrents modles de scurit dans un systme Linux afin de
contrler l'accs aux ressources du systme.
2.5.4. Le modle MLS (Multi-Level Security)
2.5.4.1.
lintgration du modle B LP dans MULTICS
Ce volume[43] dcrit lintgration du modle Bell et LaPadula dans MULTICS, il prcise

galement sa prsence certaines versions de Solaris, HPUX ou autres systmes UNIX. Il est
dsign plutt sous le nom MLS au lieu de BLP.
2.5.4.2.
Le modle MLS et SELinux
Multi-Level Security (MLS) a t mis en uvre sur de nombreux systmes d'exploitation.

Cet article [44] intitul "SELinux and MLS: putting the pieces together" discute les raisons et les
motivations derrire les amliorations apportes au modle MLS SELinux concernant le noyau
2.6.12 de Linux. Larticle reprsente le modle MLS en utilisant des schmas tire dillustration,
il dcrit ensuite la mthode utilise pour crer et configurer la politique MLS de SELinux. Il
dcrit galement la faon dont SELinux a t modifi au niveau de la dfinition de l'architecture
Flask afin damliorer le support du modle MLS pour ladapter et le rendre plus en rponse aux
exigences du monde rel et compatible avec dautres systmes MLS.
2.5.5. Le modle MCS (MultiCategory Security)
Cet article [45] intitul "A Brief Introduction to MultiCategory Security (MCS)" montre
lamlioration apporte par le modle MCS a SELinux : ltiquetage des fichiers par des
catgories est utilise pour contraindre le modle DAC (Discretionary Access Control) et la
logique du modle TE.
Larticle montre aussi que bien que le modle MCS nest autre quune adaptation du
modle MLS, il existe quelques diffrences majeures qui sont:
MCS fonctionne toujours un seul niveau et ne tient pas en considration des niveaux de
sensibilit
MCS rejette le modle de scurit de (BLP) Bell-La Padula.
La nature discrtionnaire de MCS (possibilit quun utilisateur attribue des catgories ces
propres fichiers)
2.6. conclusion
Dans ce chapitre nous avons montr que SELinux prsente une solution de scurit
flexible et granulaire car il permet dexprimer des rgles de scurit pour tous les sujets et les
objets du systme. Ces rgles consistent autoriser des domaines accder des types ce sont
64
des rgles daccs, ou dautoriser des sujets (respectivement des objets) a transiter vers de
nouveaux domaines (respectivement des types) se sont des rgles de transition. Ces rgles
constituent la politique de scurit de SELinux, elles sont nombreuses car leur nombre dpasse
plusieurs centaines de rgles.
Nous avons vu, dans ce chapitre, que plusieurs travaux de recherche concernant
lutilisation des modles DAC, RBAC et MAC dans SELinux ont t invoqus. Nous navons
recens par contre, aucun travail de recherche en relation avec lutilisation du modle OrBAC
dans SELinux.
De ce fait, nous allons voir dans le chapitre 4 que si on utilise le modle OrBAC alors la
politique de SELinux sera allge puisque le nombre de rgles sera diminu considrablement. Le
chapitre 3 prsente le modle OrBAC en tant que modle de scurit qui a introduit de nouveaux
concepts.
65
Chapitre 3
Les Modles de Contrle d'Accs Bass sur
l'Organisation (OrBAC)
3.1. Introduction
OrBAC (Organization Based Access Control) est un modle d'accs qui a repris de ses
prdcesseurs lide dabstraire les entits (dans le modle RBAC un sujet est abstrait en rle).
l'origine, OrBAC a t propos dans larticle [10] pour rpondre aux exigences des politiques de
scurit dans les domaines de soins de sant (les cliniques, les hpitaux, etc.), ainsi pour
amliorer la pertinence et lefficacit des systmes informatiques de ces secteurs. Cest dans le
cadre dun projet national MPSSICSS (Modles et Politiques de Scurit d'Informations et de
Communications en Sant et Social) par le Rseau National de Recherche en Tlcommunication
en France.
Actuellement lutilisation dOrBAC peut concerner des domaines autres que ceux de la
sant. Le but de notre travail est de coder une politique de scurit fine et granulaire comme la
politique de scurit SELinux[46] en utilisant OrBAC, ce qui confirme la puissance expressive de
ce modle.
Les politiques de scurit [47]qui s'appliquent au domaine des soins de sant exigent la
prsence des rgles exprimant des autorisations, interdictions, obligations et recommandations.
Ce sont exactement les qualits du modle OrBAC qui permet dinclure des rgles contextuelles
lies aux permissions, contrairement aux autres modles de contrle d'accs classiques tels que
DAC, MAC, RBAC, TBAC ou TMAC qui se limitent lexpression des permissions dune faon
statique.
La premire section du prsent chapitre sintresse aux lments abstraits et concrets du
modle OrBAC, la deuxime section prsente les diffrentes relations fournie par OrBAC, la
troisime section traite la relation qui existe entre les entits abstraites et les entits concrtes du
modle, la quatrime section prsente un survol sur le langage de formalisme du modle OrBAC,
la cinquime section traite la hirarchie dans OrBAC, la sixime section montre lutilisation des
contrainte en OrBAC et enfin la dernire section expose lutilitaire dadministration dOrBAC :
MotOrBAC.
3.2. lments d'OrBAC
OrBAC est un modle centr sur la notion d'organisation qui est considre comme
lentit active la plus importante de ce modle, c'est donc son principal apport. Ainsi, au sein
dun mme systme, chaque organisation peut dfinir sa politique approprie en utilisant OrBAC
et par la suite plusieurs politiques de scurit associes aux diffrentes organisations peuvent
cohabiter et tre gres de faon simultane.
La smantique de lorganisation dans OrBAC ne se limite pas seulement aux concepts lis
au domaine de la sant (exemple : organisation=clinique, hpital), mais elle peut stendre
66
un concept plus gnral, en la considrant comme un sujet ou comme tant un groupe organis
de sujets qui jouent certains rles.
Lorganisation au sens dOrBAC impose la prsence dun accord (agrment) entre les
entits actives (les sujets) qui sont censes, pour chacun dentre eux, jouer un certain rle.
OrBAC exige donc une certaine synergie structure entre les diffrentes entits actives afin de
former une organisation.
Le modle OrBAC[10][48] dfinit plusieurs entits (sujet, action, objet, rle, activit et
vue) et relations (Empower, Consider, Use, Permission, Is_permitted).
Figure 24-Le modle OrBAC

La Figure 24 illustre le schma gnral du modle OrBAC, Nous allons dtailler, dans les
paragraphes qui suivent, chacun de ces concepts avec leurs niveaux dabstraction.
3.2.1. Niveau abstrait
Ce niveau est appel aussi niveau organisationnel, il est matrialis par l'utilisation de
trois mtas entits : rle, activit et vue, qui forment respectivement labstraction des entits
traditionnelles du contrle d'accs : sujet, action et objet. Ce sont les entits abstraites qui
reoivent, la place des entits concrtes, des privilges travers la dfinition des relations
abstraites Permission, Interdiction, Obligation et Recommandation (Cf. Figure 25). Cest ce
niveau o sopre la spcification d'une politique OrBAC indpendamment du choix de
l'implmentation. Cette politique prcise que certain rle la permission (respectivement
linterdiction, lobligation et/ou la recommandation) de raliser une certaine activit sur une
certaine vue suivant un certain contexte (la notion de contexte sera explique ci-dessous dans
3.2.5)
67
Figure 25- Les relations abstraites du modle OrBAC

3.2.2. Rle
Un rle est une abstraction de sujets (utilisateurs ou organisations), c'est--dire un
ensemble de sujets qui ont des fonctions communes. OrBAC utilise les rles pour organiser les
sujets et simplifier la mise jour de la politique de scurit quand un nouvel utilisateur est ajout
ou supprim. En effet, prenons lexemple dun utilisateur assurant la fonction de comptable qui
vient dtre recrut dans le service la comptabilit (organisation = service comptable), alors il
suffit que cet utilisateur soit mis dans, par exemple, le rle comptable pour quil acquire toutes
les permissions ncessaires pour assurer les tches dun comptable.
3.2.3. Vue
Tout comme labstraction des sujets en rles, les objets sont eux-mmes abstraits en vues.
L'entit vue, ayant une dfinition particulire dans chaque organisation, rassemble des objets qui
possdent des proprits communes. Le fait dautoriser un rle daccder une vue, remplace
lopration dautoriser chaque sujet, jouant ce rle, les permissions daccs chaque objet
utilis dans cette vue.
Si dans OrBAC la vue dsigne les objets ayant des proprits communes, alors une vue au
sens des bases de donnes ramne des rsultats (des objets) qui satisfont un critre commun
(prdicat WHERE), bien quil y ait une diffrence entre les deux types de vue de point de vue
nature des entits. En effet, la vue au sens dOrBAC est une entit physique
(documents_mdicaux, fichiers_compta, etc) par contre la vue au sens des bases de donnes
dsigne une interrogation logique (SELECT) base sur des tables ou d'autres vues qui
n'occupent pas de place physique sur le disque, cest seulement l'instruction qui est mmorise et
non pas le rsultat.
3.2.4. Activit
Une activit regroupe les actions qui partagent les mmes principes, il est noter quon
peut avoir une action qui appartient plusieurs activits. Laction lire, par exemple, peut figurer
dans les deux activits : lecture et consultation. Comme pour les rles et les vues cest lentit
organisation qui prcise les actions qui devront tre mis dans une activit.
68
3.2.5. Contexte
OrBAC utilise une nouvelle entit, appele contexte pour exprimer diffrents types de
conditions supplmentaires qui limitent laccs de certains sujets certains objets. Ce sont des
contraintes qui contrlent l'activation des rgles exprimes dans la politique de contrle d'accs.
Un contexte sert spcifier les circonstances concrtes dans lesquelles les organisations
accordent des permissions de raliser des activits sur des vues. Il est noter que les contextes
assurent le principe de moindre privilge en restreignant les privilges attribuer un rle et par
la suite aux sujets jouant se rle pour la ralisation des tches autorises. Les dommages qui
peuvent rsulter dun accident, dune erreur, ou dune utilisation non autorise19 sont ainsi
limits.
Selon le modle OrBAC un contexte est vu comme une relation entre un sujet, un objet et
une action dans une certaine organisation, cette relation est note :
Dfinit (organisation, sujet, action, objet, contexte) et est schmatise comme suit (Cf.
Figure 26) :
Figure 26- La relation Dfinit dans le modle OrBAC

Le modle OrBAC reprsente les contraintes contextuelles dattribution des droits, il
regroupe les diffrents contextes par type comme suit :
3.2.5.1.
Contexte temporel
Ce sont des contextes qui rgissent la validit des privilges en mesurant leurs dures en
intervalle de temps ou en se rfrant une date prcise, ce qui suppose que le systme
dinformation dispose dun dispositif mesurant le temps (gnralement une horloge systme) et
que la consultation de ce dispositif soit possible.
Exemple : l'infirmier X la permission de lire le dossier mdical dun patient Y la date
18/12/2012.
3.2.5.2.
Contexte spatial
Certaines rgles de contrle daccs sont dtermines en connaissant au pralable le lieu

(localisation, espace) du sujet, il sagit donc dun contexte spatial qui peut tre physique
dpendant dune position gographique (sige, succursale, bureau, rgion, etc.), ou logique
(appartenance un rseau, Cellule GSM, etc.).
19
Cela s'aligne exactement avec la dfinition du principe de moindre privilge dict par le Livre Orange (DOD-5200.28-STD)
69
Exemple : Le mdecin X ne peut accder au dossier du patient Y que sil se connecte

partir de son bureau.
3.2.5.3.
Contexte dclar par lutilisateur
Dans le cas o un sujet, jouant un certain rle dans une organisation, possde la
permission de manifester son intention daccder (en excutant une certaine activit) une
certaine vue, dans un contexte donn, on dit que cest un contexte dclar par lutilisateur. De
cette faon de nouvelles permissions, et ventuellement de nouvelles obligations, ou de nouvelles
interdictions lui seront attribues. Larticle [49] fixe les trois tapes suivantes pour la dfinition
dun contexte dclar par un utilisateur :
1. Dfinition du contexte associ aux objets appartenant une vue Purpose, ou bien lune
des sous vues qui en drivent.
2. Spcification des rles qui ont la permission de dclarer un but donn.
3. Spcification des rles qui lon permet dexcuter certaines activits dans le contexte
associ, dclar par lutilisateur.
3.2.5.4.
Contexte prrequis
Dans de nombreux cas, des autorisations (obligations ou interdictions) sont accordes

un sujet, mais seulement si certaines contraintes spcifiques sont vrifies. Si les informations
ncessaires pour vrifier cette contrainte sont stockes dans la base de donnes systme, et sont
interrogeables pour dventuelles consultations alors ces catgories de contraintes sont appeles
contexte prrequis.
Exemple : Dans lorganisation Fedora 14le processus p1na le droit dmettre le signal
SIGCHLD (Terminaison d'un process fils) quaux processus de sa gnration (fils, petit fils, etc.).
Dans cet exemple lvaluation de la contrainte : mettre le signal aux processus de sa gnration
est ralis, par exemple, en excutant la commande ps pour vrifier lgalit des PPID (Parent
Process Identification) des processus avec le PID (Process Identification) de p1.
3.2.5.5.
Contexte provisionnel
La notion d'obligation provisionnelle a t introduite dans [50][51]. Elle signifie

l'obligation d'excuter, une certaine action, lorsquun sujet effectue une autre action,
gnralement dans un contexte donn (souvent lorsque le contexte est dclare par l'utilisateur).
Dans ce cas, l'obligation provisionnelle est automatiquement lance comme contrepartie de
l'action effectue par le sujet.
On suggre la modlisation de cette notion en utilisant un autre type de contexte appel le
contexte provisionnel. Pour atteindre ce but, on suppose dabord que le systme d'information
gre un journal qui stocke les donnes sur les activits prcdentes des utilisateurs dans le
systme. Ceci est modlis par une vue appele Log.
Les objets appartenant la vue Log possdent six attributs: actor, action, target, activity,
context et date qui reprsente respectivement le sujet (actor) qui effectue une action (action) sur
un objet (target) dans une activit (activity) dans un contexte (context) une date donne (date).
Afin dillustrer cette approche, on va montrer comment modliser la rgle suivante : Dans
lhpital H1, si un mdecin, dans un contexte d'urgence, consulte le dossier mdical d'un patient
donn, alors ce mdecin possde une obligation provisionnelle lui incitant denvoyer un rapport
mdical au mdecin traitant de ce patient.
70
Avant de modliser cette rgle, il y a lieu de noter que OrBAC utilise un langage (Cf.3.4)
pour reprsenter, d'une faon formelle, ses diffrentes entits et relations.
Pour modliser cette rgle, on dfinit d'abord un contexte provisoire appel
Urgent_activity comme suit:
sS, A, oO,
(Define (H 1 , s, o, , Urgent_activity)
l, (Use(H 1 , l, Log) (actor(l)=s)
(activity(l)=consult) (context(l)=Urgency))
Dans lorganisation H 1 , un sujet s excute une action sur lobjet o dans un contexte
provisionnel Urgent_activity si une activit consult a t journalise dans la vue Log dans
un contexte durgence Urgency avec le sujet s comme acteur (actor).
Nous dfinissons ensuite une vue appele Medical_report possdant les trois attributs
suivants :
Adressee : le sujet qui est suppos recevoir le rapport.
Patient : le patient concern par le rapport.
Content : Le contenu du rapport mdical.
En se basant sur cette vue, nous dfinissons une sous-vue

Med_repport_to_attending_physician comme suit:
o O, Use(H 1 ,o,Med_repport_to_attending_physician)
Use (H 1 ,o,Medical_report) patient(o)

patient(Adressee (o) )
En utilisant ce contexte provisionnel et cette vue, on peut alors prciser que le mdecin a
une obligation provisoire denvoyer un rapport mdical au mdecin traitant de ce patient:
Obligation(H 1 , Physician, send,
Med_repport_to_attending_physician, Urgent_activity)
3.2.6. Niveau concret
Cest ce niveau que les politiques concrtes prcisent quun certain sujet la permission
de raliser une certaine action sur un certain objet et ce partir des politiques abstraites, cest-dire en drivant la relation abstraite qui autorise le rle (jou par le sujet) de raliser lactivit
(considrant laction) sur la vue (utilise par lobjet scuriser). On dit que la politique concrte
est drive de la politique abstraite (Cf. 3).
OrBAC a introduit des relations concrtes : Est_permis, Est_interdit, Est_obligatoire et
Est_recommand (Cf. Figure 27) qui sont drives respectivement des relations abstraites :
Permission, Interdiction, Obligation et Recommandation, Afin de dcrire des actions concrtes
que ralisent les sujets sur les objets, et surtout pour spcifier aussi exactement que possible les
entits concrtes qui demeurent hors champs dapplications des rgles abstraites de la politique
de scurit dune organisation donnes. Il sagit donc dune autre faon pour exprimer des
71
exceptions la politique de scurit gnrale spcifie par lesdites relations. Ce qui rend les
politiques exprimes dans le modle OrBAC reproductibles et volutives.
Figure 27-Les relations concrtes du modle OrBAC

Le niveau concret est matrialis par l'utilisation des trois entits concrtes :sujet, action
et objet, dcrites comme suit:
3.2.6.1.
Sujet
Un sujet (comme le montre la Figure 28) est soit une entit active, comme un utilisateur,
c'est--dire un tre humain comme Tom , ou une organisation comme un service particulier
d'un hpital donn, une version dune distribution Linux, etc.
Figure 28-L'entit Sujet d'OrBAC

3.2.6.2.
Action
Au sens dOrBAC, Une action dsigne lacte (le verbe) par lequel un sujet agit sur un
objet. Ils correspondent principalement des actions informatiques concrtes telles que lire,
crire, Envoyer, etc. Cest la politique de scurit qui autorise, oblige, recommande ou interdit
ces accs travers une ou plusieurs rgles de scurit dune faon indirecte, puisque le modle
OrBAC contrle principalement les accs des entits abstraites (Rles, Activits et Vues).
Nanmoins, et en cas de traitement des cas particuliers, des rgles spcifiques peuvent
sappliquer aux entits concrtes (Sujets, Actions et Objets). Cest une technique visant
minimiser lcriture dun grand nombre de rgle. En effet, si par exemple la politique de scurit
dune organisation autorise tous les sujets jouant le rle R deffectuer laction A (entrant dans
lactivit a) sur lobjet o (faisant partie dune vue v), lexception dun sujet particulier Sp qui
nest pas autoris. Alors, au lieu dcrire autant de rgle (autorisant les actions des sujets sur des
objets) que de sujet, daction et/ou dobjet, on crit une rgle qui permet dautoriser le rle R
72
dexercer lactivit a sur la vue v, et ensuite crire une autre rgle de scurit qui exclue le sujet
concret Sp de cette autorisation (le formalisme de ce concept sera traiter plus tard dans ce
chapitre)
3.2.6.3.
Objet
Les objets dans le modle OrBAC, reprsentent gnralement les entits passives qui ne
contribuent pas aux dynamismes du systme (quoi quen appliquant, par exemple, le modle
OrBAC SELinux, il est possible de considrer des processus, qui sont des entits actives comme
des objets. Il est noter que l'ensemble de sujets peut tre inclus dans l'ensemble des objets). Les
objets reprsentent donc les ressources du systme informatique auxquels l'accs est sollicit. Ils
peuvent tre des rpertoires, des fichiers, des lments dune base de donnes ou carrment des
composants matriels comme les mmoires et les disques.
La dfinition dun objet dans une organisation (un tablissement, une administration ou
un hpital) peut tre considrer de diffrentes manires : un dossier de facturation de lentreprise
X, un dossier des congs du fonctionnaire Y ou un dossier de vaccination du patient Z.
3.3. Relations entre les entits abstraites et les entits concrtes
Outres les relations abstraites et concrtes vues prcdemment dans ce chapitre,
OrBACutilise dautres relations (Ce sont les relations verticales reprsentes dans le schma
gnrale dOrA: Cf. Figure 24) qui permettent de relier, dans une organisation particulire,
chaque entit concrte avec sa correspondante abstraite. C'est--dire elles relient les sujets aux
rles, les objets aux vues et les actions aux activits. Les trois relations ternaires utilises sont :
Empower, Use et Consider (Cf.Figure 24).
3.3.1. Relation Empower
Le prdicat Empower est utilis sous forme dune relation ternaire reliant un sujet s un
rle r et incluant une organisation org (Cf. Figure 29).Il est utilis de la faon suivante :
Empower(org, s, r ) est vrai signifie que lorganisation org habilite le sujet s jouer le rle r.
Exemple :
Empower (Distribution_Linux, init, init_t)
Signifie que lorganisation Distribution_Linux emploie le processus init dans
le rle init_t(il sagit dans notre formalisme dun rle OrBAC).
Figure 29-La relation Empower

73
3.3.2. Relation Use

La relation ternaire liant les objets aux vues auxquelles ils appartiennent est appel Use.
Un prdicat Use est utilis comme suit :
Use(org, o, v) est vrai signifie que l'organisation org utilise l'objet o dans la vue v. (Cf.Figure
30).
Exemple :
Use(Distribution_Linux, index.html,(file, httpd_sys_content_t));
Signifie que l'organisation Distribution_Linux utilise l'objet index.html dans
la vue v= (file, httpd_sys_content_t).
Figure 30- La relation Use

3.3.3. Relation Consider
La relation Consider lie les actions aux activits, cest une relation ternaire incluant les
organisations. Un prdicat Consider est utilis comme suit :
Consider(org, a, A) est vrai signifie que l'organisation org considre laction A comme faisant
partie de l'activit a. (Cf.Figure 31).
Exemple :
Consider(ORG-DATA, update, MAJ)
Cette relation signifie que l'organisation ORG-DATA (une base de donnes) considre
laction update comme faisant partie de l'activit MAJ (mise jour).
Figure 31- La relation Consider

74
Remarque :
Nous remarquons que le modle OrBAC abstrait les entits (sujet, action, objet) en mta-entits
(rle, activit, vue). Les oprations joignant les sujets aux rles, les actions aux activits et les
objets au vues, ne peuvent tre dtermines dune faon prcise sans intervention de
lorganisation qui abrite ces entits concrtes. est pour cette raison quon peut trouver un
sujet jouant le rle R1 dans lorganisation Org1et R2 (diffrent de R1) dans lorganisation Org2.
(Il en est de mme pour les actions et les objets).
OrBAC utilise des relations ternaires entre les entits concrtes et leurs correspondantes
abstraites. Et ce contrairement aux modles TMAC [8] et RBAC[7]qui considrent seulement des
relations binaires entre les organisations et les sujets ou entre les sujets et les rles.
3.4. Langage de formalisme du modle OrBAC
Abou El Kalam et al. [10]ont dfini un langage issu de la logique du premier ordre pour
reprsenter les diffrentes entits et relations du modle OrBAC. Ainsi, les variables, les prdicats
et les relations sont reprsents par un ensemble de symboles. Les termes du langage sont
constitus par des symboles et des constantes qui correspondent aux instances des entits
abstraites et concrtes dOrBAC, de symboles de variables qui sont elles aussi types de la mme
manire, et de symboles de prdicats qui correspondent aux relations : Empower, Use, Consider,
Permission, Interdiction, Define.
Les formules du langage sont construites partir des formules atomiques, des connecteurs
boolens : (, , , ) et des quantificateurs (, ).
3.5. Hirarchies dans OrBAC
Dans un schma OrBAC, le fait de grer facilement un nombre important dentits
quelles soient abstraites ou concrtes nest pas une tche vidente, do leur rangement en sous
entits cohrentes (au sens de lorganisation), c'est--dire quune organisation peut tre scinde
en sous-organisation, un rle en sous-rle, une activit en sous activit et une vue en sous vue.
Ces dcompositions gnrent des liens hirarchiques entre lentit parent (gnralisation) et
lentit Enfant (spcialisation).
3.5.1. Hirarchie des rles
Les rles OrBAC sont gnralement organiss, dune faon similaire que dans le modle
RBAC [25] sous forme de hirarchie base sur le principe de spcialisation/gnralisation, ce qui
permet au sous-rle Enfant dhriter des privilges du rle parent. Pour exprimer cette hirarchie,
OrBAC introduit le prdicat : sub_role(org, R1, R2) qui signifie que dans lorganisation org, le
rle R1 est un sous-rle du rle R2.
Si on dispose d'une organisation org, de deux rles R1 et R2 (avec R1 un sous-rle de R2),
d'une activit activ, d'une vue vue et d'un contexte cont, alors R2 hrite de R1 le privilge
permission, cette hritage est modlis par la rgle suivante :
org, R 1 , R 2 , activ, vue, cont

sub_role(org,R 1 ,R 2 ) permission(org,R 2 ,activ, vue, cont)
permission (org, R 1 , activ, vue, cont)
75
Cela signifie que si lorganisation org accorde la permission au rle R2 de raliser

lactivit activ dans la vue vue dans le contexte cont alors org accorde aussi la permission au rle
R1 de raliser lactivit activ dans la vue vue dans le contexte cont.
La gestion des hirarchies de rles pose un srieux problme de la cohrence du modle
OrBAC cause de la prsence des autorisations ngatives (interdictions). Ainsi la relation qui lie
les rles et les sous-rles dans une hirarchie peut tre interprte de diffrentes faons ce qui
rend lhritage des interdictions plus complexe grer. Alors comme dans RBAC, il existe deux
faons pour dfinir la hirarchie de lhritage :
La hirarchie organisationnelle : tant donns deux sujets s1 et s2, jouant respectivement les
rles R1 et R2 dans une organisation org, tels que s1 est hirarchiquement suprieur s2. Dans
certainscas20, s1 peut hriter de toutes les permissions du rle R2. On dit que R1
(respectivement R2) est senior (respectivement junior) de R2 (respectivement R1). Cette
relation est modlise par le prdicat : senior_role (org, R1, R2).
La hirarchie spcification/gnralisation : Ce type de relation est modlis en introduisant
le prdicat : specialized_role(org, R1, R2) qui signifie que dans lorganisation org, le rle R1
est une spcialisation du rle R2. Par exemple Le rle chirurgien est une spcialisation du rle
mdecin.
Cuppens et al. [52]ont prsent quartes rgles de lhritage de rle (RH1, RH2, RH3, RH4)
qui permettent dexprimer lhritage des permissions et/ou des interdictions attribues aux rles.
3.5.2. Hirarchie des activits
D'une faon similaire que les rles, les activits sont aussi structures sous forme de
hirarchie, ainsi on peut dire que dans lorganisation org, lactivit a1 est une sous-activit de a2.
Ce type de relation hirarchique est modlis au moyen du prdicat sub_activity (org, a1, a2).
Une telle hirarchisation nest autre quune spcialisation. Ainsi, dans une organisation
org, lactivit MAJ_X (mise jour de base de donnes X) est spcialise en deux activits :
INSERT_X (insertion des enregistrements dans des tables de la base X) et WRITE_X (criture
dans des tables de la base X), nous avons donc :
sub_activity(org, INSERT_X, MAJ_X)
et
sub_activity(org, WRITE_X, MAJ_X)
3.5.3. Hirarchie des vues
De la mme faon que pour les rles et les activits, lensemble des vues est structur par
des hirarchies dpendant de lorganisation. Le fait de dire que la vue v1 est une sous-vue de la
vue v2 dans lorganisation org signifie que v1 est une spcialisation de v2, le prdicat
sub_view(org, v1, v2) modlise cette hirarchisation. Ainsi les permissions sont hrites de la vue
v1 vers la vue v2 selon la rgle suivante :
org, r, a, v 1 , v 2 , c
permission (org, r, a, v 2 , c) sub_view (org, v 1 , v 2 )
permission (org, r, a, v 1 , c)
20
Lexception a la gnralit est que dans le cas o R1 = directeur d'hpital et R2 = mdecin un utilisateur jouant le rle R1
n'hritera pas forcment du rle R2.
76
Lhritage des interdictions est dfini par une rgle similaire celle concernant la
permission, elle consiste transcrire le fait que si la vue v1 est une sous-vue de la vue v2dans
lorganisation org et si un rle linterdiction de raliser une certaine activit sur la vue v2, alors
ce rle aura linterdiction de raliser cette activit sur la vue v1.
3.5.4. Hirarchie des organisations
Comme pour les rles, les activits et les vues, OrBAC construit aussi la hirarchie
dorganisation, et introduit le prdicat sub_organization qui est suppos dfinir une relation
dordre partiel sur lensemble des organisations.
On crit, par exemple sub_organization( organisation1 , organisation2) pour signifier que
lorganisation organisation1est une sous-organisation de lorganisation organisation2.
Dans certains cas, la modlisation de laffectation dune ou de plusieurs sousorganisations a un rle est dfinit en utilisant loprateur de conjonction () entre le prdicat qui
dfinit la (ou les) sou-organisation(s) avec la (ou les) relation(s) Empower qui permettent
demployer la (ou les) sous-organisation(s) dans ledit rle :
organisation 1 , organisation 2 , role
sub_organization( organisation 1 , organisation 2 )

Empower( organisation 1 , organisation 2 , role)
error()
Remarque : Une entit abstraite (rle, activit ou vue) dfinie dans une certaine organisation
nest pas ncessairement dfinie dans toutes ses sous-organisations. Rciproquement certaines
entits abstraites peuvent tre dfinies dans des sous-organisations sans ltre dans
lorganisation mre.
Il y a hritage de structure hirarchique du sous-ensemble des rles dfinis dans une
organisation qui sont galement dfinis dans une de ses sous-organisations. La rgle ci-aprs
modlise lhritage de la structure suivante :
tant donne une organisation organisation2et une de ses sous-organisations
organisation1, dans lorganisation organisation1, le rle role1 est un sous-rle du rle role2, ces
deux rles relvent tous les deux de lorganisation organisation2.
organisation 1 , organisation 2 , role 1 , role 2

sub_organization(organisation 2 , organisation 1 )
sub_role( organisation 1 , role 1 , role 2 )
Relevant_role(organisation 2 , role 1 )
Relevant_role(organisation 2 , role 2 )
sub_role( organisation 2 , role 1 , role 2 )
Dans cette rgle le remplacement respectif du prdicat sub_role par les prdicats
specialized_role, sub_ activity et sub_ view permet dappliquer le mme principe de lhritage
des privilges dans la hirarchie de spcialisation respectivement, des rles, des activits et des
vues.Lhritage des permissions et des interdictions est modlis par la rgle suivante :
organisation 1 , organisation 2 , role, activit, vue,

context
sub_organization(organisation 2 , organisation 1 )
permission (organisation 1 , role, activit, vue,
77
context) Relevant_role(organisation 2 , role)

Relevant_activity(organisation 2 , activit)
Relevant_view(organisation 2 , vue)
permission (organisation 2 , role, activit, vue,
context)
Dans le cas de lhritage des interdictions, une modlisation similaire cette dernire est
adopte en remplaant les relations :
Permission (organisation i , role, activit, vue, context) (i=1, 2)
par
Prohibition(organisation i , role, activit, vue, context) (i=1 , 2)
3.6. Contraintes
RBAC fut le premier modle qui a propos la notion de contraintes et plus prcisment
dans le sous-modle RBAC2[25], puis analys dans [53], les contraintes peuvent tre associes au
modle de manire imposer un certain nombre de proprits ncessaires la ralisation des
objectifs de scurit. Pour spcifier des contraintes, le modle OrBAC introduit un prdicat
error(), qui joue le rle de conclusion [54][51]dans la rgle modlisant la contrainte.
OrBAC considrons des contraintes dites contraintes d'exclusion mutuelle entre les rles,
les vues et les activits (Comme dans le modle RBAC[55][56][25][57][26]). Il existe deux types
d'exclusion mutuelle : statiques et dynamiques.
Exclusion statique : Il sagit par exemple du cas dune organisation organisation o un sujet
s ne peut tre habilit jouer, la fois, deux rles role1 et role2 :
s, Empower(organisation, s, role 1 )
Empower(organisation, s, role 2 ) error()
Cependant, il existe certains rles particuliers qui doivent tre jou par un seul utilisateur,
ils sont indiqus par une contrainte qui concerne lattribution des rles aux utilisateurs, appele
contrainte duale.
Exclusion dynamique : Ce type de contrainte indique que bien quun utilisateur puisse
jouer plusieurs rles, il n'est pas autoris les activer simultanment.
OrBAC peut utiliser des contraintes appliquer aux organisations dans un but de vrifier
quune entit abstraite (rle, activit ou vue) est bien dfinie dans une organisation donne, ce
sont des conditions ncessaires satisfaire pour quune organisation org habilite un sujet s dans
un rle r, considre laction A comme faisant partie de lactivit a ou utilise lobjet o dans la vue
v, nous avons donc les contraintes suivantes :
org, s, r:
Empower(org,s,r) Relevant_role(org,r) error()
org, A, a:
Consider(org,A,a) Relevant_activity(org,a) error()
78
org, o, v:
Use(org, o, v) Relevant_view(org, v) error()
Semblablement a ces dernires, OrBAC utilise dautre rgles, mais concernant les
permissions et les interdictions :
Les permissions :
org,
s, r, A, a, o, v, c :
Permission(org,r,a,v,c) Relevant_role(org, r)
Relevant_activity(org,a) Relevant_view(org, v)
error()
Les interdictions :
org,
s, r, A, a, o, v, c :
Interdiction(org,r,a,v,c) Relevant_role(org, r)
Relevant_activity(org,a) Relevant_view(org, v)
error()
3.7. MotOrbac
La complexit est au cur des systmes d'information (SI) d'aujourd'hui. Souvent on
constate que ces systmes grent des architectures htrognes : rseaux, systmes dexploitation,
bases de donnes, applications web, etc. Ce qui rend les tches des administrateurs des politiques
de scurit trs fastidieuses. En effet, ces politiques sont gnralement dfinies et ensuite gres
en manipulant des lignes de commandes ou en configurant artisanalement les lments en
relations avec la scurit du systme au risque et pril de ladministrateur qui les manipulent.
Beaucoup doutils dadministration existent et sont oprationnels, bien quils permettent
dallger remarquablement les tches ardues des administrateurs, ils sont ou bien de porte
restreinte (par exemple ils se limitent la scurit rseau) ou bien ils ncessitent une expertise
importante. Au titre de la prsente thse, on sintresse principalement la politique de scurit
SELinux qui est gnralement cre par la personnalisation d'un modle de politique appel
refpolicy21. Toutefois, la description et la vrification des configurations de cette politique de
scurit est difficile parce que, dans refpolicy, on trouve plus de 100.000 lignes de configurations,
des milliers d'lments tels que les permissions, les macros et les labels (les contextes de scurit
SELinux).
3.7.1. Historique et architecture de MotOrBAC
Cuppens et al. [12] ont prsent un prototype appel MotOrBAC (acronyme qui dsigne
Moteur OrBAC), qui a t dvelopp en langage Java pour administrer les politiques de scurit
bases sur lorganisation (OrBAC), dautres fonctionnalits telles que la simulation de la
politique de scurit, lanalyse de la cohrence de la politique et la spcification de la politique
dadministration sont galement fournies par ce prototype. Larchitecture de MotOrBAC est
prsente dans la Figure 32.
MotOrBAC a permis principalement dintgrer dans un unique modle de scurit
lexpression de toutes les exigences de scurit rseau, systme ou applicatives. En effet,
MotOrBAC est bas sur le modle OrBAC qui permet dexprimer une politique de scurit au
21
refpolicyest un modle de politique dvelopp et maintenupar la communautSELinux. Il est composde macros et deconfigurationspour les
applicationstypiques.
79
niveau organisationnel. Ainsi, il est possible de passer du gnral (abstrait) au particulier

(concret) dans lexpression dune politique de scurit et ce en dsignant des sous-organisations
de lorganisation mre, on peut mme dlguer certaines tches dadministrations des sujets
jouant des rles diffrents.
Figure 32 -Larchitecture de MotOrBAC

3.7.2. Modules de MotOrBAC
Le prototype MotOrBac est compos de quatre modules (Figure 32) :
A. Lanalyseur de cohrence de la politique : ce module permet, travers les rapports des
diagnostics de redondance et dinconsistance, de valider automatiquement les rgles
dune politique de scurit, puisque gnralement le nombre de ces rgles dpasse les
centaines, voire mme les milliers.
B. la sauvegarde des donnes : les donnes relatives aux lments de la politique de
scurit sont enregistrs et reprsent en XML (ou Prolog).
C. le module de communication : il joue le rle dintermdiaire entre les diffrents
modules.
D. linterface graphique : est utilise pour simplifier la saisie ou la modification des
politiques de scurit, elle est divise en six parties:
80
Figure 33- linterface graphique du MotOrBAC

1. Les politiques charges: un onglet est cr pour chaque politique dite.
2. La spcification d'une politique abstraite :
la hirarchie de l'organisation,
lutilisation dune bote outils pour crer dune faon simple des organisations,
des rles, des activits, des vues et des rgles de scurit,
Des entits abstraites: Trois onglets montrent les hirarchies des rles, des activits
et des vues.
Contextes : utilis pour spcifier les contextes et leurs dfinitions utilises dans les
rgles abstraites.
Rgles abstraites: compose de trois onglets correspondant aux trois types de
rgles abstraites, les permissions, des interdictions et des obligations.
Conflits: affiche les conflits dtects dans la politique choisie et aider
l'administrateur les corriger.
Dfinitions dentit : cet onglet est utilis pour spcifier les dfinitions dentit.
Simulation de la politique concrte : montre la politique concrte infrer de la
politique slectionne et des tats des contextes.
3. Menu et icnes: Utilises pour charger, enregistrer ou crer des politiques en plus
dautres fonctionnalits.
4. Entits concrtes : compos de trois onglets Sujets, Actions et Objets. Des boutons
(add, delete et Edit) sont utiliss pour grer des entits concrtes et un menu
contextuel permet d'attribuer des entits concrtes des entits abstraites.
5. Boutons AdOrBAC[58]: ces boutons sont utiliss pour activer ou dsactiver
l'valuation des politiques AdOrBAC et de la grer. l'administration de la politique de
scurit peut tre activ et contrl, et un utilisateur peut se connecter et/ou dfinir
son mot de passe.
81
6. Barre d'tat en bas : la barre d'tat au bas de l'interface affiche diverses informations:
l'utilisateur AdOrBAC connect, le nombre de conflits abstraits et concrets, le nombre
d'interdictions concrets et abstraits, etc.
Le prototype MotOrBAC assure cinq fonctionnalits :
1) Saisie dune politique de scurit : Cette fonctionnalit permet ladministrateur de
la politique de scurit dun systme dinformation, de saisir via linterface
MotOrBAC les diffrentes entits abstraites dOrBAC en plus des contextes et des
rgles de la politique de scurit. En effet, il peut dfinir des organisations, avec
ventuellement des sous-organisations comme il peut visualiser une politique de
scurit relative une organisation en utilisant un menu droulant destin cet effet.
Ensuite il y a possibilit de dfinir des rles, des activits, des vues ainsi que leurs
sous-entits correspondantes (sous-rles, sous-activits et sous-vues). Il est noter que
le modle OrBAC inclut quatre vues prdfinies role, activity, view et context qui
permettent respectivement de grer les rles, activits, vues et contextes de chaque
organisation. La manipulation de ces entits conduit linsertion dans la politique de
scurit des faits rcapituls dans le tableau suivant :
Faits
sub_organization(org1,org2)
use(Org,Object,View)
Senior_role(Org, role1, role2)
Description
org1 est une sous-organisation de org2
Dans lorganisation Org, lobjet Object est utilis
dans la vue View
dans lorganisation Org, le role role1 est
hirarchiquement suprieur au rle role2.
Tableau 12- Des faits insrs dans la politique de securit

Il est galement possible de dfinir des contraintes sur les entits ainsi cre, et ce en
utilisant des prdicats comme error et separated_role.
Enfin, MotOrBAC offre une grande facilit de gestion des entits abstraites en permettant
dautomatiser la gestion de lhritage :
des privilges lis la hirarchie des entits abstraites
des contraintes de sparation
des privilges lis la hirarchie dorganisation
de la dfinition des contextes
2) Simulation de la politique : MotOrBAC offre la possibilit de simuler la politique en

saisissant les entits concrtes : les sujets, actions et objets (qui sont caractriss par
des attributs) de lorganisation et en drivant automatiquement la politique au niveau
concret partir de la politique abstraite saisie prcdemment. MotOrBAC montre aussi
ltat d'activation pour chaque rgle concrte.
Dans le modle OrBAC, la politique concrte s'appliquant aux sujets, actions et objets
d'un systme est drive d'une politique abstraite spcifie au niveau organisationnelle.
MotOrBAC peut afficher la politique concrte drive d'une politique abstraite.
L'onglet policy simulation montre toutes les rgles de scurit concrtes induites partir
des rgles de scurit abstraites et les contextes dans les onglets respectifs Rules et Context state.
La partie de simulation de l'interface de MotOrBAC est compose des lments suivants:
82
Le contrle des dates : Ladministrateur peut utiliser l'onglet de simulation pour fixer la
date utilise par le gestionnaire du temps de la politique. Cette horloge est utilise par
certains types de contexte.
Longlet concrete security rules : la table liste les autorisations concrtes en vert, les
interdictions
concrtes
en
rouge
et
les
obligations
concrtes
en bleu. Chaque entre dans cette table prcise l'tat de la rgle, son type, le sujet, l'action
et l'objet. La colonne state affiche l'tat des rgles. Les autorisations et les interdictions
peuvent tre soit actives soit inactives, en fonction de ltat de contexte associ. Les
obligations peuvent tre dans quatre tats diffrents: active ou inactive comme les deux
autres types de rgles, et violated et fullfiled.
L'onglet context: prsente les listes de tous les dfinitions pour chaque contexte ainsi que
les tats correspondants.
Aprs avoir dfinies dans MotOrBAC les entits concrtes, on leur applique la politique
abstraite par drivation, pour cela, on introduit le prdicat is_permitted.
3) Vrification de la cohrence de la politique de scurit : MotOrBAC permet de
dtecter les conflits au niveau concret ou abstrait de la politique de scurit spcifie
par ladministrateur.
La prsence des conflits au niveau concret est due gnralement aux simulations des
politiques prsente prcdemment. MotOrBAC offre une fonction pour analyser ces conflits au
niveau organisationnel. Ensuite, on introduit le prdicat conflit pour les dtecter laide de la
rgle suivante :
Rgle
conflit
permission(Org1,Role1,Activity1,View1,Context1,Priority1),
prohibition(Org2,Role2,Activity2,View2,Context2,Priority2),
not (separated_role(Org1,Role1,Org2, Role2)),
not (separated_activity(Org1,Activity1,Org2,Activity2)),
not
(separated_view(Org1,View1,Org2, View2)),
not (separated_context(Org1,Context1,Org2,Context2)),
not (Priority1< Priority2),
not (Priority2< Priority1).
Signification
Un conflit est driv si
une permission et une interdiction
organisationnelles existent dans les
organisations Org1 et Org2
Et il nexiste pas de contraintes de
sparation entre les rles, activits, vues et
contextes
Et les priorits associes respectivement
la permission et linterdiction ne sont pas
comparables.
Tableau 13-Rgle de dtection de conflit.

4) Rsolution de conflits : Il existe plusieurs stratgie de rsolution de conflits des leurs
apparitions pour rtablir la cohrence de la politique de scurit :
La mise jour de la politique en modifiant une des rgles conflictuelles.
Lajout dune (ou plusieurs) contrainte(s) de sparation pour sassurer que les entits
abstraites ne peuvent plus rentrer en conflit. (Exemple : sparation des rles)
La modification du niveau de priorit dune des rgles conflictuelles, cest une

solution simple mais utiliser avec prcaution (risque de redondance ou
dinapplicabilit de lune des rgles conflictuelles).
Lindiffrence aux conflits : le fait dignorer un conflit, suppose que ladministrateur
connaisse et value les causes et les risques que cela peut engendrer au niveau concret.
83
5) Gestion des droits dadministration : Si le modle ARBAC[59][60] a t dfini pour

administrer le modle de contrle daccs RBAC[7][5]. Le modle OrBAC[10]
possde lui aussi son propre modle dadministration, il sagit du modle
AdOrBAC[58]. MotOrBAC offre la possibilit aussi de grer tout ou partie dune
politique de scurit en laffectant un rle dadministration.
Le modle AdOrBAC est ax sur la gestion des objets dadministration, lexpression
de la politique dadministration consiste spcifier qui possde des privilges de grer
lesdits objets, qui sont regroups dans des vues (Cf. Figure 34) et ce pour se
conformer avec le modle OrBAC.
Figure 34-Les vues administratives

Ainsi, le prdicat USE est utilis pour spcifier les objets affects ces vues.
AdOrBAC permet dadministrer les activits suivantes :
gestion des permissions (pra : Permission Role Assignement),

gestion des affectations de rles aux sujets et dactivits aux actions (ura, aaa),
gestion des hirarchies dentits organisationnelles (rha, aha, vha, oha, cha),
gestion des dfinitions de contextes (hold).
6) Gestion des privilges : Les affectations des privilges aux rles sont gres par la
vue pra qui est aussi une classe pourvue des attributs (des proprits) caractrisant les
diffrents paramtres dun privilge. Ces attributs sont dfinit comme suit :
type : il sagit du type du privilge ayant les trois valeurs possible : permission,
Prohibition, obligation.
authority : lorganisation dans laquelle le privilge est appliqu au rle.
(Exemple :authority(Obj, Auth)).
grantee : le rle qui possde le privilge. (Exemple : grantee(Obj, Role))
Privilege : lactivit qui pourra tre considre lorsque le privilge est utilis.
(Exemple : privilege(Obj, Activity)).
84
Target : la vue sur laquelle le rle possde le privilge. (Exemple :

target(Obj,View)).
context : le contexte dutilisation du privilge (Exemple : context(Obj, Context)).
level : Gnralement utilis pour rsoudre les conflits, il dsigne le niveau de

priorit associ au privilge. (Exemple : level(Obj, Priority)).
3.8. Conclusion
Nous avons prsent dans ce chapitre, le modle de contrle d'accs OrBAC, il est centr sur la
notion d'organisation qui donne un sens aux entits abstraites et aux relations qui existent entre
elles, la notion de contexte est lun des plus intressant apports dOrBAC car il permet dexiger
certaines conditions dapplication des rgles de scurit. Dans le modle OrBAC, la politique de
scurit peut tre exprime par des permissions, interdictions, obligations et recommandations.
Or nous pouvons rduire considrablement le nombre de rgles de la politique de scurit de
SELinux si on essaye dabord dadapter les entits SELinux aux entits OrBAC puis de les
abstraire, ces oprations ainsi que dautres agissements seront traits dans le chapitre 4 suivant.
85
Chapitre 4
Codage en modle OrBAC de la politique de scurit
par dfaut de SELinux.
4.1. Introduction
SELinux est l'une des solutions de scurit les plus utilise dans les systmes
d'exploitation Linux, il offre la possibilit d'utiliser diffrents modles de contrle d'accs.
Ce chapitre fournit un codage d'une politique de scurit SELinux par dfaut en utilisant le
modle de contrle d'accs bas sur l'organisation (OrBAC). Nous allons utiliser Fedora
14, comme un exemple de distribution Linux afin d'illustrer notre codage. Pour chaque
concept (rle, type, contexte, ..) utilis dans SELinux, nous fournissons son homologue
dans le modle OrBAC pour confirmer la puissance expressive de ce modle.
La solution de scurit SELinux a t incorpore dans plusieurs distributions Linux
comme RedHat, Fedora, Gentoo, et SUSE Linux. Elle fournit une couche supplmentaire
de scurit afin de protger et de contrler l'accs aux diffrents objets d'un systme
d'information.
Dans ce chapitre nous allons commencer par explorer lemplacement des fichiers
et rpertoires lis la politique de scurit installe et analyser leurs configurations.
Ensuite, nous tudions les contextes de scurit associs par dfaut aux utilisateurs et aux
fichiers du systme. Les paramtres de la politique de scurit par defaut de Fedora 14
sont aussi tudis pour avoir des statistiques concrtes sur leurs nombres.Nous montrons
ensuite que chaque concept dans la politique de scurit SELinux possde une contrepartie
naturelle dans le modle OrBAC ce qui confirme la puissance expressive du systme
OrBAC[46]. A la fin de ce chapitre nous prsentons un exemple de politique de rfrence
SELinux pour le dmon dhcpd [61] que nous coderons avec le modle OrBAC.
Comme nous lavons dtaill au le chapitre 1, Il existe diffrents modles de
contrle d'accs qui ont t proposes dans la littrature:
HRU (Harrison, Ruzzo et Ullmann) [15],

RBAC (contrle d'accs bas sur les rles) [5][62],
TBAC(contrle d'accs bas sur des tches) [63],
etc.
Nous avons galement vu au chapitre 3que le modle OrBAC[10] possde

lavantage dexprimer les contrles d'accs des politiques de scurit au niveau
organisationnel (niveau abstrait) sans rfrence des utilisateurs particuliers, des objets
ou des actions. Il est bas sur le concept d'organisations et de rles et permet de faire face
86
diffrentes modalits dontiques22 tels que les permissions, les obligations et les
interdictions.
Il prend galement en charge une infrence des rgles qui permettent de driver des
permissions (interdictions, obligations) concrtes sur des utilisateurs (objets, actions)
spcifiques.
Ce chapitre montre aussi comment les politiques de scurit (installe par dfaut)
utilises par SELinux peuvent tre codes par le modle OrBAC. Pour illustrer notre
travail, nous allons utiliser Fedora 14[64] en tant quun exemple de distribution Linux. Il
est bien entendu facile dadapter notre travail pour les autres distributions. Fedora 14
nest donc quun exemple pour montrer les principales tapes de notre encodage.
Tout dabord, ds linstallation de la distribution Fedora 14, celle-ci active par
dfaut SELinux et fournie une politique toute faite pour les cas courants.
Nous avons vu dans le chapitre 2, lutilisation de SELinux des deux
paramtres :SELINUX et SELINUXTYPE, en particulier sous Fedora 14 ils sont stocks
dans le fichier /etc/selinux/config et possdent des valeurs par dfaut telles
que :SELINUX=enforcing et SELINUXTYPE=targeted.
La premire section de ce chapitre explore et analyse les configurations des fichiers
et des rpertoires qui hbergent la politique de scurit SELinux de la distribution
Fedora_14, la deuxime section prsente les paramtres de la politique de scurit
SELinux par dfaut de Fedora 14, la troisime section montre que chaque concept dans la
politique de scurit SELinux possde son correspondant dans le modle OrBAC. Enfin,
dans la dernire section de ce chapitre nous prsentons un exemple de codage de la
politique SELinux.
4.2. Fichiers et rpertoires lis la politique de scurit dfaut
Sous Fedora14, l'emplacement de la politique de scurit (politique source et
politique binaire) est dans le dossier: /etc/selinux qui contient le sous-rpertoire
targeted/ racine de la politique cible.
4.2.1. Le fichier de configuration de la politique de scurit par dfaut
Le fichier de configuration par dfaut de SELinux est/etc/selinux/config,
il est lu par libselinux pour interprter comment le systme est configur. Il contient
deux variables d'environnement: SELINUX et SELINUXTYPEdfinies (par dfaut)
respectivement aux valeurs enforcing et targeted.
SELINUX=Enforcing cette valeur indique au systme de fonctionner avec
SELinux en contrlant tous les accs au systme et de stopper tous ceux qui sont
refuss. Dans ce mode le noyau bloque tous les accs sauf s'ils sont explicitement
autoriss. Tous les accs refuss sont rapports dans le systme de journalisation
22
La logique dontique est l'origine des systmes normatifs, qui permettent de modliser les obligations, les violations et les sanctions dans une
organisation, et notamment dans un systme multi-agents.
87
AVC (Access Vector Cache), moins quil y existe un vecteur dontaudit, crit
explicitement qui dit que le noyau ne doit pas journaliser le message.
SELINUXTYPE=targeted Cette valeur indique que seuls les dmons rseau

cibls sont protgs.
Remarque : Lorsque SELinux est excut en un mode autre que

Enforcing (c'est--dire Permissive ou s'il est Disabled), les fichiers
nouvellement crs nauront aucun contexte de scurit, ce qui posera un problme lors
de passage au mode Enforcing. La solution est donc de faire entrer la commande
suivante :
$ su -lc 'touch /.autorelabel'
Pour forcer le retiquetage de la totalit du systme au prochain dmarrage.

4.2.2. Contexte de connexion par dfaut associs aux utilisateurs
Dans le rpertoire/etc/selinux/targeted/contexts/users/,on
trouve gnralement les fichiers portant les noms : guest_u, root, staff_u,
unconfined_u, user_u, xguest_u.
Dans la politique cible, seul le fichier root se trouve dans ce rpertoire. Lesdits
fichiers sont utiliss pour dterminer le contexte de connexion d'un utilisateur. Par
exemple, pour l'utilisateur root, il se voit attribuer le contexte
user_u:system_r:unconfined_t qui nest autre que le contenu du fichier
root.
4.2.3. Contexte par dfaut associ aux fichiers et rpertoires
4.2.3.1.
Pour les rpertoires de travail
Les deux exemples suivants montrent la faon dont les contextes de scurit sont
affects aux rpertoires de travail home-directory (le rpertoire par dfaut associ un
utilisateur quand il se connecte dans le systme).
SELinux attribue diffrents contextes aux fichiers/rpertoires en fonction de leurs
importances.
Ces
contextes
sont
stocks
dans
le
fichier
/etc/selinux/targeted/modules/actifs/file_contexts.homedirs
sous forme dentres, ce fichier est spcialement utilis pour attribuer les contextes par
dfaut aux rpertoires de travail des utilisateurs.
Exemple 1 :
/home/[^/]*
-d unconfined_u:object_r:user_home_dir_t:s0
88
Ce premier exemple signifie que les rpertoires (option -d)

utilisateurs auront le contexte de scurit :
de travail des
unconfined_u:object_r:user_home_dir_t:s0.
Exemple 2 :
/home
system_u:object_r:home_root_t:s0
Ce deuxime exemple signifie que le rpertoire /home possde le contexte par

dfaut system_u:object_r:home_root_t:s0. Il s'agit d'un rpertoire
important, car il contient les fichiers et les rpertoires des utilisateurs. C'est
pourquoi ildoit tre confin dans le type (TE) home_root_t.Les autres
utilisateurs
qui
ont
le
contexte
unconfined_u:unconfined_r:unconfined_t ne peuvent pas accder
ces objets.
4.2.3.2.
Pour les autres rpertoires
Le rpertoire /etc/selinux/targeted/modules/active/contient un
fichier nomm file_contexts qui est utilis pour initialiser le contexte de scurit
pour des fichiers et des rpertoires. Les exemples suivants illustrent trois diffrents
contextes associs aux fichiers :
Exemple 3 :
/srv/.*
system_u:object_r:var_t:s0
Cet exemple signifie que tous les objets sous le rpertoire /srv qui ont un nom
qui commence par le caractre. (point) et se termine par nimporte quel
caractre
*
(toile),
auront
le
contexte
de
scurit
system_u:object_r:var_t:s0.
Exemple 4 :
/dev/.*tty[^/]*
-c
system_u:object_r:tty_device_t:s0
Ce deuxime exemple signifie que, seuls les priphriques(terminaux) qui sont en

mode
caractre
auront
le
contexte
de
scuritsystem_u:object_r:tty_device_t:s0.
Exemple 5 :
/dev/.mdadm\.map -- system_u:object_r:mdadm_var_run_t:s0
Ce dernier exemple signifie que seuls les fichiers nomms.map auront le contexte
de scurit system_u:object_r:tty_device_t:s0.
89
Remarque : Pour restaurer le contexte par dfaut associ un fichier (ou un

rpertoire), on doit premirement savoir son contexte dorigine en recherchant son
chemin dans lun des fichiers:
/etc/selinux/targeted/modules/actifs/file_contexts.home
dirs
/etc/selinux/targeted/modules/active/file_contexts
Ou en utilisant la commande matchpathcon :

$ matchpathcon /home
/home
Ensuite restaurer (redresser) le contexte par dfaut : (home_root_t) travers la

commande suivante :
$ su -lc 'restorecon -v /home'
restorecon reset /home context system_u:object_r: home_t:s0 ->
4.3. Paramtres de la politique de scurit SELinux

Cette section donne quelques informations concernant les paramtres principaux
utiliss dans la dfinition d'une politique de scurit par dfaut. Ces principaux
paramtres sont les classes, les types et les permissions (vecteur sallow) :
classes: le nombre de classes diffre d'une distribution (en plus de la version)

Linux une autre. Par exemple Fedora 14 utilise 77 classes. file, dir, et
processus sont des exemples de classes. Les classes sont dterminantes dans
les modles de SELinux. En effet, chaque objet (en particulier un fichier)
appartient une classe. Cette classe dtermine l'ensemble des actions potentielles
(galement connue comme une permission) qui peuvent tre excutes sur les
objets appartenant cette classe.
allow: par dfaut, Fedora 14 utilise 268004 rgles allow. Un exemple de rgle
allow est :
allow unconfined_t cert_t : dir { ioctl read getattr
lock search open };
Cette rgle signifie que si un utilisateur possde un contexte avec le domaine
unconfined_t alors celui-ci est autoris excuter les actions suivantes:
ioctl, read, getattr, lock, search et open, pour tous les rpertoires qui
sont confins dans le type cert_t. les rgles allow sont tout simplement des
rgles de permission.
90
Permission: Chaque classe est associe une liste d'actions autorises. Par
exemple, la classe file dispose d'un ensemble de 21 actions autorises qui sont
{append, entrypoint, execute, getattr, link, mounton,
quotaon, relabelfrom, rename, swapon, write, create,
execmod, execute_no_trans, ioctl, lock, open, read,
relabelto, setattr, unlink}.
Notez que ces actions sont des actions lmentaires. Ainsi, les permissions de
SELinux sont dfinies un bas niveau sur les actions lmentaires, et non sur
toutes les actions. Par exemple, dans SELinux une rgle de permission ne
s'applique pas sur l'action de haut niveau comme par exemple la commande ls ou
grep, mais sur la liste des actions de bas niveau produites par ces commandes.
4.4. Encodage en modle OrBAC de la politique de scurit dfaut SELinux
Cette section montre comment une politique de scurit SELinux (par dfaut)peut
tre code avec le modle OrBAC. Cela signifie que nous avons besoin de montrer
comment chaque concept introduit dans SELinux peut tre traduit dans le systme
OrBAC. Autrement dit, on a besoin de montrer comment remplir chaque table (Cf. Figure
24) du modle OrBAC partir de la politique SELinux.
Deux concepts du modle OrBAC ne sont pas directement utiliss dans SELinux.
En effet :
Le concept de contexte du modle OrBAC n'est pas utilis dans SELinux (le
contexte SELinux na absolument rien voir avec celui utilis dans OrBAC). Il
aura la valeur par dfaut True ce qui signifie qu'il n'ya pas de condition
supplmentaire pour l'application des rgles de scurit.
Le concept d'organisation du modle OrBAC est suppos avoir une valeur fixe,
c'est--dire que nous supposons ici que nous n'avons qu'une seule organisation que
nous appellerons simplement SELINUX_DISTRIBUTION (dans notre cas, il sagit
de la distribution Fedora 14).
Le contenu de chaque concept (ou table) dans OrBAC, dfini et obtenu partir de
SELinux est dcrit comme suit :
4.4.1. Les entits de la relation Employ
4.4.1.1.
Sujet
Lentit sujet contientla liste des UID(User IDentifier) du systme prsent

dans SELinux. LUID peut tre associe des utilisateurs ou des processus.
91
Pour chaque sujet, nous allons dfinir un attribut qui reprsentera son identit
SELinux : ID_SELinux(identit de l'utilisateur SELinux).
Par exemple, le sujet root possde ID_SELinux(root) gal
unconfined_u.
4.4.1.2.
Rle
Le concept de rles est utilis la fois par OrBAC et SELinux. Cependant,

au codage de SELinux, nous nallons pas correspondre les rles du modle OrBAC
ceux utiliss dans SELinux. La table de rle (utilis dans OrBAC) contiendra
l'ensemble de tous les types (et non pas les rles) utiliss dans SELinux.
Le choix de cette correspondance est justifi par le fait que le type de
SELinux et le rle du modle OrBAC reprsentent tous les deux les entits qui
reoivent les permissions sur des objets.
Rappelons quun contexte SELinux attribu un utilisateur contient la fois
les rles et les types. Toutefois, les rgles allow ne sont pas dfinies sur les
rles, mais plutt sur le type. En revanche dans OrBAC, les rgles de permissions
sont dfinies sur des rles. C'est pour cette raison que les rles dans OrBAC
correspondent parfaitement aux types SELinux au lieu des rles.
4.4.1.3.
Employ
La relation Employ relie des sujets des rles, autrement dit, elle autorise un
sujet jouer un rle.
Lorganisation SELINUX_DISTRIBUTION attribue un rle OrBAC un utilisateur
u.
Si et seulement si
Il existe un rle SELinux attribu un utilisateur u et tel que ce rle (de SELinux)
est confin dans le domaine type_t.
Plus formellement:
Employ(SELINUX_DISTRIBUTION, u, r) est valide
Default_role_Selinux(ID_SELinux (u)) = role_SELinux
et
Type (role_SELinux) =r est valide dans SELinux
92
4.4.2. La relation Consider

Les tables OrBAC, concernant les entits : action, activit et la relation
consider, sont remplies comme suit :
4.4.2.1.
Action
Les actions dans OrBAC sont ceux utilises dans les politiques de scurit
SELinux telle que : getattr, execute, and open.
Il est rappeler quune rgle allowest de la forme :
allow types_source types_cible:classes{list_actions};
Ainsi, les actions dans le systme OrBAC sont l'union de toutes les listes des
actions qui sont fournies dans les rgles de SELinux.
4.4.2.2.
Activit
Compte tenu du fait que le nombre d'actions n'est pas lev, nous supposons
simplement que chaque action reprsente une activit : activit = action.
4.4.2.3.
Consider
La relation consider peut tre considre comme la relation identit, puisqu'il

ny a quune seule activit par action.
4.4.3. La relation Uses
4.4.3.1.
Objets
Un objet est une entit passive qui peut tre un fichier ou un rpertoire (il peut
tre mme une entit active comme un processus) du systme. Chaque objet possde
deux attributs: classe d'objet et type d'objet.
Par exemple, le rpertoire racine("/") possde la classe rpertoire : dir et il
est confin dans le type :root_t.
4.4.3.2.
Vues
Une vue du modle OrBAC est reprsente par un couple compos de la

classe de lobjet et de type de lobjet: Vue= (classe de lobjet, type de lobjet).
Exemple :
93
Distributions
Nombre de classes
Nombre de types
Nombre de vues
Fedora 14
77
3177
244629
CentOS 5.6
61
1868
113948
RHEL 6
77
3073
236621
4.4.3.3.
Use
Lentit Use est une relation ternaire qui relie les objets leur vue, et puisque
chaque vue peut tre reprsente sous forme dun couple (class, type), alors la
relation Use (org, o, V) est dfinie comme suit:
Use (SELINUX_DISTRIBUTION, o, V)
Si et seulement si
class (o) =class
et
type (o) =type
O
oest un objet et V une vue telle que V= (class(o), type(o)).
classe(o) (respectivement type(o)) dsigne la classe (respectivement le

type) de l'objet o.
Exemple :
Use (SELINUX_DISTRIBUTION, /,
V= (dir, root_t)) est valide
Si et seulement si
classe ("/") = dir
et
type ("/") = root_t.
4.4.4. La relation abstraite : Permission

Permission (org, r, a, v, c) signifie que l'organisation org accorde la
permission au rle r pour raliser l'activit a sur la vue v dans le contexte c. Rappelons
que le contexte est attribu une valeur par dfaut T (True). Le contexte T signifie que
ladite permission est toujours valide sans restrictions ni conditions supplmentaires.
Les rgles de permission abstraites dans OrBAC sont tout simplement obtenues
partir des rgles allow utilises dans SELinux.
Rappelons quil existe 268004 rgles allow recenses dans SELinux Fedora 14et
elles possdent la forme suivante:
94
allow types_source types_cible:classes {list_actions};
O:
-
types_source: reprsente un ou plusieurs types sources (associ des

sujets)
types_cible: reprsente un ou plusieurs types cibles (associs des objets)
classes: dsigne un ou plusieurs classes d'objets.
{list_actions}: reprsente une ou plusieurs actions dfinies pour la (ou

les) classe(s) spcifie(s),
Par consquent, nous avons :

permission (SELINUX_DISTRIBUTION, Role_Orbac, Activity, View, Default)
Si et seulement si
Il existe une rgle allow :
allow src_type trgt_type:obj_class {list of actions};
O :
- Role_Orbac=src_type
- View=( obj_class, trgt_type)
-
Activity{list of actions};
95
Exemple:
Permission (SELINUX_DISTRIBUTION, foo_t, read, View, T) est valide
Si et seulement si
Il existe une rgle allow telle que :
allow foo_t root_t : dir { read } ;
et
readperms(class(/)) = perms(dir))
= {add_name, create, getattr, link, mounton,
quotaon, relabelfrom, remove_name, reparent,
search,
swapon,
write,
append,
execute,
ioctl, lock, open, read, relabelto, rename,
rmdir, setattr, unlink}.
(Car root_t estle type du repertoire /)
et
View= (dir, root_t)=( class(/),type(/)).
4.4.5. La relation concrte Is_Permitted

Is_permitted(s, A, o) est une relation concrte qui lie un sujets, une action A et un
objet o, et qui signifie que le sujet s a concrtement la permission de raliser laction A
sur lobjet o.
Is_permitted est drive des permissions accordes au rle R, au vue V et aux
activits a par la relation permission.
La rgle conditionnelle de drivation se prsente comme suit:
Si
Permission (org, R, V, a, c) et
Employ (org, s, R) et
Use (org, o, V) et
Consider (org, A, a) et
Define (org, s, o, A, c)
Alors
Is_permitted(s, o, A):
Par exemple, si dans le contexte T, l'organisation SELINUX_DISTRIBUTION accorde au
rle foo_t la permission d'excuter lactivit {write} sur la vueView=(file,
admin_home_t), si SELINUX_DISTRIBUTION emploie le sujet root dans le rle
foo_t, si SELINUX_DISTRIBUTION utilise l'objet /root/fich1 dans la vue
View=(file, admin_home_t), si SELINUX_DISTRIBUTION considre que laction
write relve de lactivit {write} et si, dans SELINUX_DISTRIBUTION, le contexte T
est vrai entre : root, /root/fich1 et write
96
Alors
Root possde la permission d'effectuer l'action write sur le fichier /root/fich1.
Plus formellement:
Si
Permission(SELINUX_DISTRIBUTION, foo_t, {write}, View, T) et
Employ(SELINUX_DISTRIBUTION, root, foot_t) et
Use(SELINUX_DISTRIBUTION, /root/fich1, View) et
Consider(SELINUX_DISTRIBUTION, write, {write}) et
Define(SELINUX_DISTRIBUTION, root, /root/fich1, write, T)
Alors
Is_permitted (root, /root/fich1, write)
La premire relation suppose(comme nous l'avons invoqu prcdemment dans
4.4.4)que:
-
Il existe une rgle allow permettant au domaine foo_t d'excuter

{write} dans des fichiers qui ont le type admin_home_t:
allow foo_t admin_home_t : file { write } ;
View= (class(/root/fich1),type(/root/fich1))
admin_home_t).
(file,
La seconde relation supposeque (comme nous l'avons invoqu dans4.4.1.3): Le
domaine SELinux foot_t est un rle OrBAC.
La troisime relation signifie que (comme nous l'avons dfinie dans 4.4.3.2), nous
avons tout simplement la vue View =(file, admin_home_t).
La quatrime relation suppose que write est en mme temps une action et une
activit.
La cinquime relation signifie que, dans SELINUX_DISTRIBUTION, le contexte Test
vrai entre : le sujet root, lobjet/root/fich1 et laction write
La sixime relation signifie que, le sujet root la permission d'effectuer l'action
write sur lobjet/root/fich1.
4.5. Exemple dillustration

Pour illustrer le codage de SELinux en OrBAC, nous prsentons un exemple de
politique de rfrence pour le dmon Linux dhcpd[61]. Cet exemple peut servir comme
rfrence de codage appliquer toutes les politiques des autres dmons cibls. Nous
utilisons dans notre exemple la distribution Red Hat Linux 4 (que nous noterons RHL4),
que nous considrerons galement comme lorganisation (selon le modle OrBAC) au
97
sein de laquelle sont dfinis les concepts principaux de notre politique. Nous supposerons
donc : SELINUX_DISTRIBUTION=RHL4.
Emplacements des fichiers de politique de dhcpd :Les deux fichiers ci-aprs constituent
la politique de scurit du dmon dhcpd.
/etc/selinux/domains/program/dhcpd.te : Dans ce fichier, sont
dfinies les rgles de scurit pour le domaine dhcpd_t du dmon dhcpd.
/etc/selinux/file_contexts/program/dhcpd.fc :
Ce fichier
dfinit le contexte de scurit pour les fichiers associs avec le dmon dhcpd
serveur, en attribuant chacun dentre eux le type dhcp_<*>_t.
Un extrait de ce fichier se prsente comme suit :
# dhcpd
/etc/dhcpd.conf -- system_u:object_r:dhcp_etc_t
/etc/dhcp3(/.*)? system_u:object_r:dhcp_etc_t
/usr/sbin/dhcpd.* -- system_u:object_r:dhcpd_exec_t
/var/lib/dhcp(3)?/dhcpd\.leases.* -- \
Le domaine dhcpd_t associs au politique dhcpd : Il sagit dans cette partie,

didentifier les principales rgles utilises dans la politique dhcpd et par la suite de
coder ces rgles en modle OrBAC, le codage des rgles concernant les autres domaines
(dhcpd_exec_t,
dhcpd_port_t,
dhcpd_state_t,
dhcpd_tmp_t,
dhcpd_var_run_t, dhcp_etc_t et dhcp_state_t) est similaire ceux
traits dans cette exemple lexception des rgles de transition qui sont codes dans le
Chapitre5 (Codage des transitions SELinux en OrBAC).
Le domaine dhcpd_t est lun des plus importants domaines pour le dmon dhcpd,
car presque toutes les rgles, notamment celles dveloppes dans des macros, et qui se
trouvent dans le fichier (dhcpd.te) lutilisent.
Attribution des types dhcpd_<*>_t : En analysant le fichier dhcpd.fc
nous remarquons que lattribution dun contexte de scurit un fichier (ou
rpertoire) se rduit lattribution dun type en respectant le canevas :
dhcpd_<*>_t . En effet, les identits (SELinux) ainsi que les rles sont fixs
respectivement aux valeurs : system_u et object_r , Ce qui signifie que tous ces
fichiers possdent lidentit standard SELinux system_u utilis pour identifier les
dmons. Le rle object_r est le rle des objets systme tels que les fichiers et les
priphriques.
Pour ce qui est du codage en OrBAC, chaque fichier (resp. rpertoire) list dans
dhcpd.fc sera utilis dans une vue reprsente sous forme dun couple form de la
98
classe de fichier (resp. la classe de rpertoire) et du type SELinux. Prenons le fichier

etc/dhcpd.conf figurant sur la premire ligne du fichier dhcpd.fc. Il est de
classe file et de type dhcp_etc_t par consquent il sera mis dans la vue :
V=(file, dhcp_etc_t). Nous avons donc la validit de la relation :
Uilise(RHL4, etc/dhcpd.conf,
V= (file, dhcp_etc_t));
Les rgles ncessaires pour laccs au rseau

Pour que le dmon dhcpd puisse accder aux rseaux, il doit avoir les
permissions ncessaires pour exploiter les sockets UDP et TCP ou envoyer et recevoir sur
une interface rseau partir de nimporte quel node et sur nimporte quel port.
Trois grandes classes dobjets relatives aux rseaux sont fournies par SELinux, elles sont :
tcp_socket pour les sockets TCP ;
netif pour les interfaces rseau ;
et, node pour les nuds (node ) du rseau.
Prenons lexemple suivant :

allow dhcpd_t netif_type : netif { tcp_send udp_send };
Cette rgle autorise tous les processus confins dans le domaine dhcpd_t( en particulier
dhcpd) denvoyer et recevoir sur les sockets TCP et UDP, toutes les interfaces rseau
(netif ) ayant le type netif_type.
En OrBAC cette rgle se traduit par les deux relations suivantes:
permission (RHL4, dhcpd_t, tcp_send, V= (netif, netif_type),
Default);
et
permission
Default);
(RHL4,
dhcpd_t,
udp_send,
V=(netif,
netif_type),
En effet :
Le type source dhcpd_t est assimil un rle OrBAC. (Cf. 4.4.1.3 )
Chacune des actions tcp_send et udp_send est assimile aux activits

portant les mmes noms.
La vue V est un couple compos de la classe dobjet cible : netif et de type

de lobjet cible : netif_type, on a donc V = (netif,
netif_type).
Default est la valeur par dfaut du contexte OrBAC, Cest la valeur pour
laquelle on ne prend pas en considration les conditions (spatiales, temporelles,
etc.) dexcution de la permission.
99
Le fait que dhcpd joue un rle qui soit confin dans dhcpd_t, se traduit en
OrBAC par:
Le sujet dhcpd possde ID_SELinux(dhcpd ) gal system _u ;
Default_role_Selinux(ID_SELinux (dhcpd )) =
Default_role_Selinux(system _u)=object_r;
Et, Type (role_SELinux) = Type (object_r ) =dhcpd_t qui est un type

valide dans SELinux ;
Par consquent, lorganisation RHL4 emploie lutilisateur (processus)dhcpd dans le
rle (OrBAC) dhcpd_t , c'est--dire la relation : Employ (RHL4, dhcpd,
dhcpd_t) est valide.
La condition de drivation de la relation abstraite permission (on traite uniquement lune
des deux relations) :
permission(RHL4,
dhcpd_t,
netif_type), Default);
tcp_send,
V=
(netif,
permission(RHL4, dhcpd_t, udp_send, V=(netif, netif_type),

Default);
est la suivante :
Si dans le contexte T (=Default) , l'organisationRHL4 accorde au rle
dhcpd _t
la permission d'excuter lactivit {tcp_send } sur la
vueV=(netif, netif_type) ,
Si l'organisationRHL4 emploiele sujet dhcpd dans le rle dhcpd _t,
Si l'organisationRHL4 utilise l'objet eth0 dans la vue V=(netif,
netif_type) ,
Si l'organisationRHL4 considre que laction tcp_send relve de lactivit
{tcp_send } et Si dansl'organisationRHL4 , le contexte T(=Default) est
vrai entre : dhcpd , eth0 et tcp_send
Alors
dhcpd
eth0 .
possde la permission d'effectuer l'action tcp_send sur le fichier
100
Plus formellement:
Si
permission(RHL4, dhcpd_t, tcp_send, V=(netif, netif_type),
Default)et
Employ (RHL4, dhcpd,dhcpd_t) et
Utilise(RHL4, eth0, V=(netif, netif_type)) et
Consider(RHL4, tcp_send,{tcp_send}) et
Define(RHL4, dhcpd, eth0, tcp_send, Default)
Alors
Is_permitted (dhcpd, tcp_send, tcp_send).
4.6. Conclusion
Nous avons vu dans ce chapitre quil est possible de fournir un codage d'une
politique de scurit SELinux par dfaut en utilisant le modle OrBAC. Pour cela nous
avons utilis Fedora 14, comme un exemple de distribution Linux afin d'illustrer notre
codage. Nous avons utilis galement la distribution RHL4 pour coder quelques rgles de
la politique SElinux du dmon dhcpd avec le modle OrBAC. Le chapitre 5 va se pencher
sur le codage en OrBAC des rgles de transition. Ce qui justifie lexpressivit du modle
OrBAC et la capacit dutilisation dautres modles daccs pour SELinux.
101
Chapitre 5
Codage des rgles de transition SELinuxen modle
OrBAC
5.1. Introduction
En SELinux, plusieurs processus sexcutent dans leurs domaines dorigine,
cependant dautres processus spciaux ne peuvent tre excuts que dans des domaines
particulier, par consquent un changement de domaine est alors ncessaire.
Ce chapitre montre comment lon peut coder les rgles de transition en OrBAC. Il
complte le Chapitre 4 qui sest concentr seulement sur le codage des rgles daccs.
La premire sous-section de la section principale du prsent chapitre traite le
codage en OrBAC de lattribution de type par dfaut un objet nouvellement cr, la
deuximesous-section montre comment lon peut coder la spcification dun domaine par
dfaut pour un processus et ce dans les deux cas de prsence ou dabsence dune rgle de
la politique de scurit qui force lattribution de domaine, lexemple de la procdure de
changement de mot de passe est invoque au niveau de la dernire sous-section afin
dillustrer le cas de transition de domaine partir dune rgle de la politique de scurit.
5.2. Transition de types en SELinux
Une nouvelle rgle fut introduite pour supporter les transitions qui se produisent
par dfaut. Comme elle est utilise dans le cas du programme des mots de passe, cette
rgle sappelle la rgle de transition de type type_transition. Elle spcifie les
transitions par dfaut qui devraient se produire si aucune transition explicite nest
prsente. La forme dune rgle type_transition est comme suit :
type_transition source_t destination_t : classes defaut_t
O :
source_t et destination_t : dsignent un ou plusieurs types

defaut_t : un seul type, sinon il y aurait un conflit
classes : elle peut tre ou bien process pour designer la transition de type
processus ou bien file (ou autre classe de fichier) pour designer la transition de
cration de fichier.
Les rgles type_transitionne reprsentent pas des permissions et sont

dfinies par des macros qui les combinent avec un ensemble de rgles TE qui doivent tous
contribuer pour permettre la transition (voir lexemple des mots de passe).Chaque
domaine original et nouveau domaine doivent assurer les conditions suivantes :
102
Le domaine original devrait avoir accs au fichier excutable.
Le domaine original devrait avoir la permission de faire une transition au nouveau

domaine.
Le nouveau domaine devrait se voir accorder la permission dentrer via un

programme.
Etc.
5.2.1. Spcification dun type par dfaut pour un nouvel objet

1er Cas : Si un processus dans le domaine shell_t cre un objet ode classe fichier dans
un rpertoire de type rep_t, le nouveau fichier se verra attribuer le type defaut_t.
(Si tous les accs sont permis par les rgles de TE). Et ce selon la rgle de transitions
suivante :
type_transition shell_t rep_t : file defaut_t
2ime Cas : Si aucune rgle explicite qui force ltiquetage du type par dfaut nest
prsente dans la politique, alors lors de la cration dun objet o, celui-ci se voit, par
dfaut, attribuer le type de son rpertoire parent. Il y a donc hritage de type.(A)
La cration dun objet o nest autre que la cration dune instance de la classe de
lobjet en question :
Par exemple pour crer un fichier vide sous Linux, on utilise la commande touch:
[khal@A410E15 ~]$ touch fich1
Dans ce cas New_object(o) est quivalent la commande touch o (avec o un objet de

classe file).
On a donc :
Type (New_object(o)) = defaut_t (1er Cas ci-dessus)

Type (New_object(o)) = Type(parent_dir(o)) = rep_t (2ime
Cas ci-dessus).
O parent_dir(o) dsigne le rpertoire o le shell a cr lobjet o.
Comme nous lavons invoqu dans les articles [46] et [65], la vue correspondante a
lobjet nouvellement cre est :
V= (class(o), type(o)) = (file, defaut_t). (1er Cas ci-dessus)
V=(class(o), type(o)) = (file, Type(parent_dir(o)))
=(file, rep_t). (2ime Cas ci-dessus)
103
De plus nous appellerons :
TRANS_RULE_CONTEXTle contexte dans lequel il existe une rgle de transition de

type qui spcifie un type par dfaut (1er Cas ci-dessus), et
NO_TRANS_RULE_CONTEXTle contexte qui reflte linexistence daucune rgle
explicite qui attribue par dfaut des types ou des domaines aux fichiers, rpertoires
ou tout autre objetlors de sa cration, ou lors de lancement dun processus par un
autre processus(2ime Cas ci-dessus).
Le scnario (A) se traduit en OrBAC (en respectant la manire de remplissage des
tables concernant ce modle comme dans larticle[46] sus-indiqu) comme suit :
Permission (SELinux_Distribution, Role_Orbac, a, V, c)
Cela exige que si lorganisation SELINUX_DISTRIBUTIONaccorde la permission au

rle Role_Orbac de raliser lactivit a dans la vue V dans le contexte c, alors il
existe :
Un prdicat Hold qui dfinit le contexte c de la faon suivante :
Hold (SELINUX_DISTRIBUTION, ID_SELinux(user), create, o, c)
avec:
Role_Orbac = Type(ID_SELinux(user))=shell_t
a=create (ou tout autre permissions ncessaires la
cration de fichier)
si
c
=
NO_TRANS_RULE_CONTEXTalors
V=(file,Type
(parent_dir(o))).
si c = TRANS_RULE_CONTEXT alors V = (file, defaut_t).
Parent_dir(o) peut tre considr comme un attribut de lentit objet o, cela

veut dire que les objets cres dans le mme rpertoire aurons le type de leur rpertoire
parent.
Remarque : Dans les deux cas ci-dessus ou le type de lobjet fichier prend la valeur
rept_t ou defaut_t, la transition de type nest effective que si elle est complte par
des rgles allow telles que :
- allow shell_t rep_t:dir {... ioctl write}; (les 2 cas cidessus).
- allow shell_t default_t:file {create ioctl append write ...};
(pour le 1er cas).
- allow shell_t rep_t:file
(pour le 2ime cas).
{create
ioctl
append
write
...};
Ces rgles se traduisent en OrBAC respectivement par les prdicats suivants :

- permission(SELINUX_DISTRIBUTION, shell_t, Activity, (dir, rep_t),
cont); avec :
104
Activity {..., ioctl, write}

cont= no_Trans_rule_context
ou
cont= Trans_rule_context
- permission
(SELINUX_DISTRIBUTION,
defaut_t), cont); avec :
Activity,
(file,
Activity { create, ioctl, append, write, ... } et

cont= Trans_rule_context
- permission
(SELINUX_DISTRIBUTION,
rep_t), cont); avec :
shell_t,
shell_t,
Activity,
(file,
Activity { create, ioctl, append, write, ... }

cont = No_Trans_rule_context
5.2.2. Spcification dun domaine par dfaut pour un nouveau processus

5.2.2.1.
Cas dabsence dune rgle explicite
En labsence dune rgle explicite qui attribue des domaines par dfaut (voir utilisation de
la rgle type_transition), un processus tourne toujours dans le domaine du
processus qui la lanc, cest son processus parent :
Si P un processus tournant dans le domaine Dp, lance un programme Prgde
typePrg_exec_t (on suppose quil existe une rgle qui autorise lexcution de Prg par
P), alors le processus P (fils du processus P) tourne dans le domaine Dpgale Dp. (2)
Cela signifie que :
Si
PPID (p) = PID (p)
(P tant le processus enfant de P issus de lexcution du programme Prg, que nous
pouvons noter : P(Prg)=P, PID et PPID tant respectivement
le Process
Identification et Parent Process Identification)
Il existe une rgle TE :
allow Dp Prg_exec_t : file {...execute};
Alors
Dp = Dp
De la mme manire que prcdemment, et en ce qui concerne la dfinition des vues

OrBAC partir des entits SELinux, la vue correspondante lobjet Prgest :
V = (class (Prg), type (Prg)) = (file, Prg_exec_t)
Le scnario (2) se traduit en OrBAC comme suit :
105
Permission (SELINUX_DISTRIBUTION, Role_Orbac, a, V, c)
Cela exige que si lorganisation SELINUX_DISTRIBUTION accorde la permission au rle

Role_Orbac de raliser lactivit a sur la vue V dans le contexte c, alors il existe :
Un prdicat Hold qui dfinit le contexte c de la faon suivante :
Hold (SELINUX_DISTRIBUTION, ID_SELinux(P), execute, o, c)
Avec:
Role_Orbac = Dp,(Domaine SELinux=Rle OrBAC)
a=execute (le processus P execute le programme Prg)
V = (class (Prg), type (Prg)) = (file, Prg_exec_t)

c =
5.2.2.2.
a.
NO_TRANS_RULE_CONTEXT
Cas de transition de domaine partir dune rgle
En SELinux
travers des rgles SELinux, il peut tre permis un domaine dun processus
Linux de transitionner, durant l'excution d'un programme, vers un nouveau domaine et
la sortie du programme le domaine initial est alors restaur. Gnralement, le nouveau
domaine est ncessaire pour effectuer certaines fonctionnalits dites de confiance, telles
que par exemple, la gestion des fichiers des mots de passe des utilisateurs Linux.
Une application de la transition de domaine dun processus est dmontre par
l'exemple de la gestion des mots de passe (Cf. 2.4.5.4 et 2.4.5.3) :
[khal@A410E15 ~]$ id
uid=518(khal)gid=519(khal)
groupes=519(khal)
contexte=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Il sagit du shell, de lutilisateur khal, qui tourne dans le domaine des utilisateurs
ordinaires unconfined_t.
[khal@A410E15 ~]$ ls -Z /usr/bin/passwd

-rwsr-xr-x.
root
root
system_u:object_r:passwd_exec_t:s0
/usr/bin/passwd
La commande /usr/bin/passwd possde le type passwd_exec_t.

[khal@A410E15 ~]$ passwd
Changement de mot de passe pour l'utilisateur khal.
Changement du mot de passe pour khal.
Mot de passe UNIX (actuel) :
Nouveau mot de passe :
Retapez le nouveau mot de passe :
passwd
:
mise
jour
russie
de
tous
les
106
jetons
d'authentification.
Une fois la commande passwd est lance par le shell de lutilisateur khal, la
rgle:
allow unconfined_t passwd_exec_t : file {getattr execute} (1);
permet ce shell qui tourne dans le domaine unconfined_t dexcuter la commande

passwd (ayant le type passwd_exec_t).
[root@A410E15 ~]# ps -efZ
.....
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
20099 20098 0 May02 pts/0 00:00:00 -bash
.....
unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 root
20099 0 00:34 pts/0 00:00:00 passwd
.....
khal
24075
La rgle :
allow passwd_t passwd_exec_t : file entrypoint (2);
signifie que les fichiers excutables de type passwd_exec_t servent comme point
dentre pour le type passwd_t.
La permission transition qui est ncessaire pour permettre le changement du
type d'un processus est assure par la rgle :
allow user_t passwd_t : process transition (3);
Le type d'origine unconfined_t doit avoir la permission de transition vers le

nouveau type passwd_t, pour que la transition de domaine soit autorise. La rgle (2)
oblige que cette transition doit passer par le lancement dun fichier de type
passwd_exec_t.
En ouvrant une session en tant que root, le rsultat de la commande ps efZ
montre que le shell (bash) tournant dans le domaine unconfined_ttourne dans le
domaine passwd_t quand il lance la commande passwd.
[khal@A410E15 ~]$ ls -Z /etc/shadow
----------.
root
root
system_u:object_r:shadow_t:s0
/etc/shadow
Le type du fichier des mots de passe /etc/shadow est shadow_t.

La rglesuivante:
allow passwd_t shadow_t : file {iocl read write create getattr
setattr lock relabelfrom relabelto append unlink link rename}
107
(4);
Veut dire que seuls les processus tournant dans le domaine passwd_t puissent excuter
les oprations : iocl, read, write, etc. sur le fichier ayant le type
shadow_t.
Enfin la rgle suivante :
type_transitionunconfined_t passwd_exec_t : process
passwd_t;
Dans cet exemple, la rgle type_transition indique que, par dfaut et lors dun
appel systme execve(), si le processus appelant est de type unconfined_t et le
type du fichier excutable est passwd_exec_t, une transition de domaine vers un
nouveau domaine passwd_t se produirait.
b.
En OrBAC
Lorsque le shell bash (jouant le rle unconfined_t) de lutilisateur khal

excute la commande /usr/bin/passwd (utilis dans la vue V=(file,
passwd_exec_t)), le nouveau processus (fils du bash de lutilisateur khal) joue
alors un nouveau rle OrBAC : passwd_t.
Figure 35- Transition de rle OrBAC

Il sagit donc dune transition de rle OrBAC dcoulant dune transition de type
SELinux, ainsi les excutables servants de points dentres (ce sont les fichiers de
typepasswd_exec_t) vers le domaine passwd_t, sont abstraits en vue V=(file,
passwd_exec_t)laquelle reprsente le point dentre pour les rles OrBAC vers le
rle passwd_t.
Dans ce qui suit nous allons traduire les conditions SELinux en code OrBAC pour
avoir finalement le code de lopration de transition.
Le fait quun processus P1(par exemple le bash dun utilisateur) tourne dans le
domaine unconfined_t, il jouera en consquence le rle unconfined_t. car
108
un domaine SELinux la mme signification quun rle OrBAC, ceci se formalise

par le prdicat :
Employ (SELinux_distribution, P1, unconfined_t);
La commande/usr/bin/passwdest un fichier excutable de type

passwd_exec_t : Dans lorganisation SELinux_DISTRIBUTION lobjet
o=/usr/bin/passwd est li la vue V reprsente par le couple (classe(o),
type(o)) = (file, passwd_exec_t)par la relation Use comme suit :
use(SELinux_distribution,
passwd_exec_t))
/usr/bin/passwd,(file,
Lexcutable/usr/bin/passwd est un point dentre au type passwd_t :

allow passwd_t
passwd_exec_t : file entrypoint;
Cela signifie que si un sujet s veut transiter d'un domaine Ds= unconfined_t
un autre domaine Ds= passwd_t, il doit excuter un programme (Entry Point)
ayant le type passwd_exec_t, soit le programme (ou la commande)
/usr/bin/passwd note :
EP (Ds, Ds). Nous avons donc :
passwd_exec_t = EP(unconfined_t, passwd_t)
Il est remarquer que la rgle allow concernant le point dentre ne suffit pas
pour assurer la transition partir du domaine unconfined_t un domaine
passwd_t. Pour cela, il est donc indispensable quune autre rgle explicite de
transition figure dans la politique, cette rgle scrit comme suit :
allow unconfined_t passwd_t : process transition;
La transition entre deux domaines SELinux implique une transition entre deux rles
OrBAC, dans [66]la rgle exprimant la transition entre les domaines et mettant en
place la notion de point d'entre, possde la forme suivante :
SR (permission, org, D1, Enter, D2, through(EP (D1, D2))).
Dans cette rgle, les hypothses suivantes sont considrer :

a. Le domaine source D1est considr comme tant un rle du modle OrBAC.
b. Le domaine de destination D2 considr comme une vue du modle OrBAC,
cependant il peut tre considrer comme un rle.
c. Enter (Cf. Figure 35) tant lactivit OrBAC qui spcifie la transition
permise entre les domaines (les rles OrBAC) D1et D2.
109
d. through(EP (D1, D2))est un contexte qui peut tre utilis pour dfinir
un point dentre (Entry point) que nous avons reprsent par :EP (D1, D2),
par consquent la prsente rgle nest valide que si ce contexte lest aussi.
Dans notre cas, la rgle ci-dessus scrit :
SR (permission, SELINUX_DISTRIBUTION,
passwd_t, through(passwd_exec_t)).
unconfined_t,
Enter,
Remarque : cette rgle rassemble les deux rgles SELinux : celle concernant le
point dentre et celle autorisant la transition.
P1possde la permission dexcuter (execute)et davoir les attributs (getattr)

du fichier /usr/bin/passwd et ce selon la rgle suivante :
allow unconfined_t passwd_exec_t : file {getattr execute};
Cela se traduit par : l'organisation SELINUX_DISTRIBUTION accorde la permission

au rle OrBAC user_t pour raliser lactivit activity {getattr,
execute} sur la vue V = (file, passwd_exec_t) dans le contexte Cont,
par consquent la rgle allow de SELinux se traduit par la validit des rgles
OrBAC suivantes :
Permission
(SELINUX_DISTRIBUTION,user_t,
passwd_exec_t), Cont) ;
Permission (SELINUX_DISTRIBUTION,
passwd_exec_t), Cont)
user_t,
execute,
getattr,
(file,
(file,
Tout en sachant que le contexte Cont puisse avoir une valeur par dfaut (Exemple :
Cont = TRUE) pour signifier que ces permissions sont toujours valides sans
restrictions ni conditions supplmentaires.
Cont peut tre enrichi avec d'autres contextes OrBAC (temporels, spatiales)
utiliss en jonction avec le contexte des points dentre, afin de restreindre ou
conditionner lapplication de la rgle qui lutilise.
Gnralement nous pouvons avoir :
Cont=

DEFAULT
through(EP(D1,D2)
ContTemp
ContSpacial
P2est le processus enfant issue de lexcution du fichier /usr/bin/passwd par

le processus P1 (On a doncP1(/usr/bin/passwd) = P2)
Le processus P2se voit donc jouer le rle OrBACpasswd_t(car il possde le
type : passwd_t), formul comme suit :
Employ (SELINUX_DISTRIBUTION, P2, passwd_t)
110
Finalement la rgle :
allow passwd_t shadow_t : file {iocl read write
getattr setattr lock relabelfrom relabelto append
link rename};
create
unlink
est traduite par les 13 prdicats :

Permission(SELinux_distribution,
(file, shadow_t), Cont)(1i13).
passwd_t,
permsi,
Avec:
passwd_t : dsigne le rle cible issue de la transition du rle

unconfined_t
permsi
{iocl, read, write, create, getattr,
setattr,
lock,
relabelfrom,
relabelto,
append,
unlink, link, rename}, nous avons autant de prdicats permissions
que depermsi. dans la Figure 35 nous avons reprsent seulement permsi=
write pour allger la figure.
(file, shadow_t) : dsigne la vue des fichiers des mots de passe.
Cont : dsigne le contexte qui peut tre paramtr selon les conditions
dexcution du prdicat.
5.3. Conclusion
Dans ce chapitre nous avons montr comment coder les rgles de transition en
OrBAC. Pour cela nous avons commenc par coder les cas de spcification des types et
domaines par dfaut, ensuite nous avons trait le cas de prsence ou dabsence dune
rgle de transition qui force lattribution de type ou de domaine. Le concept du point
dentre (Entry point) connu dans le modle DTE a t introduit dans le modle OrBAC
pour pouvoir correspondre toutes les rgles indispensables la transition de SELinux
celles nouvellement conues dans OrBAC.
Le fait de pouvoir coder en OrBAC, la fois les rgles daccs et les rgles de
transitions de la politique de scurit SELinux, confirme lexpressivit du modle OrBAC.
Le chapitre 6 montre que le modle OrBAC est aussi extensible et volutif car une
nouvelle entit appele priorit a t introduite pour confirmer cette volutivit.
111
Chapitre 6
Gestion possibiliste des priorits dans les modles de
contrle d'accs.
6.1. Introduction
Les modles de contrle d'accs sont des outils importants pour la modlisation des
politiques de scurit. Ils permettent de limiter l'accs des donnes sensibles aux seuls
utilisateurs autoriss. Ce chapitre se concentre sur le modle OrBAC (organisation-based
access control) qui reprsente un cadre gnrique permettant de reprsenter de manire
compacte les rgles gnrales des politiques de scurit. Plus prcisment, nous
proposons d'ajouter au modle OrBAC une nouvelle entit, appele priorit permettant de
coder les diffrentes formes d'incertitude qui peuvent tre rencontres dans les rgles de
scurit. Les entits (priorits) introduites seront modlises en thorie des possibilits qui
reprsente un cadre naturel pour la manipulation et le traitement des informations
incertaines. Nous proposons diffrentes rgles qui permettent de driver des permissions
concrtes partir des permissions abstraites priorises.
Les diffrents modles de contrle d'accs proposs dans la littrature: HRU
(Harrison, Ruzzo and Ullmann) [15], DAC (Discretionary Access Control Model) [4],
TBAC (Team-based Access Control Model) [67], RBAC (Role-Based Access
Control)[5][6][7], OrBAC (Organization Based Access Control) [10], etc. prsentent des
solutions adaptes pour protger les donnes sensibles des utilisateurs non autoriss et ce
en limitant l'accs aux donnes sur la base des politiques de scurit.
Ce chapitre propose d'intgrer une composante d'incertitude dans le modle de
contrle d'accs. Dans la pratique, l'attribution d'une permission, pour atteindre une
certaine action dans un systme d'information, n'est pas toujours complte. En plus de
contextes, une permission peut tre imprgne de l'incertitude due par exemple la
prsence d'exceptions ou tout simplement en raison de la fiabilit de la source. Par
exemple, on peut fournir une certaine rgle de droit qui peut justifier une permission (ou
l'interdiction). Cependant, il peut arriver que certaines doutes/incertitudes sur une telle
rgle (certaine) de droit peuvent exister. Par exemple au sein dune ancienne rgle de
droit il peut tre propos dautres rgles rcentes et prioritaires avec une avec une
recommandation contradictoires.
Au sein du prsent chapitre, Les priorits et les incertitudes sont reprsentes dans
le cadre de la thorie des possibilits.
La thorie des possibilits et de la logique possibilit [7][10][11]permettent de
traiter des informations incertaines d'une manire ordinale, explicitement, seules les
priorits entre les informations sont importantes. La logique possibiliste est une simple
extension de la logique propositionnelle, en attribuant un poids chaque formule. Ce
poids reprsente l'incertitude/priorit de la formule. Et cest partir de la valeur de ce
poids que la formule devienne propritaire.
112
OrBAC[10] est le modle de contrle d'accs considr dans le prsent chapitre. Le

choix de ce modle est principalement justifi par sa puissance expressive pour
reprsenter les rgles de scurit gnrales. L'ide principale est de sparer les
informations gnrales reprsentant les rgles gnriques, partir de donnes factuelles
reprsentant les lments concrets d'un systme d'information. Dans OrBAC, les relations
entre ces lment set leur abstraction sont souvent fournis par des relations claires qui
n'admettent ni incertitudes ni exceptions. Ce chapitre montre comment tendre ces
relations pour pouvoir traiter l'incertitude. Cela permet d'amliorer les systmes OrBAC
avec une nouvelle fonctionnalit qui intgre lentit priorit dans diffrentes relations du
systme OrBAC.
La premire section du prsent chapitre rappelle la logique possibiliste, la
deuxime section traite lajout de lentit priorit au modle OrBAC notamment au niveau
des relations qui lient les entits concrtes leurs homologues abstraites, la troisime
section sintresse au priorits au niveau des relations abstraites et montre, en choisissant
un mode de transition, comment driver la priorit de la relation concrte correspondante.
6.2. La logique possibiliste
La logique possibiliste est une extension de la logique classique propose dans
[68][69], elle est issue de la thorie des possibilits de Zadeh [70]. Elle partitionne
lensemble des interprtations en deux parties : les modles de la base, et les
contremodles et ce au niveau smantique.
Une base de croyance possibiliste est le rsultat obtenu, au niveau syntaxique, en
associant chaque formule un degr qui reflte son niveau de priorit par rapport aux
autres formules de la base, contrairement la logique probabiliste classique qui considre
que toutes les formules de la base ont le mme niveau de priorit.
6.2.1. Distributions de possibilits
On considre Lun langage propositionnel construit sur V ensemble fini de variables
propositionnelles. On note lensemble de toutes les interprtations de L qui dsigne un
ensemble de formules bien formes construites partir dun ensemble fini datomes
propositionnels et des connecteurs :
(conjonction),
(disjonction), (implication
matrielle), et (ngation).
Le concept de la distribution de possibilit, note , est lun des objets principaux

de la thorie des possibilits. La distribution de possibilit est dfinie comme tant une
application dun ensemble dtats possibles vers lintervalle [0, 1] qui reprsente une
chelle traduisant une connaissance partielle sur le monde :
:
[0, 1]
()
() dsigne le degr de compatibilit de linterprtation avec les croyances

disponibles si on reprsente des connaissances incertaines, ou un degr de satisfaction si
on reprsente des prfrences.
113
Par convention, nous avons :
() = 1 correspond un tat possible et signifie que est totalement compatible

(ou satisfaisant) avec les croyances disponibles. Sil existe au moins une
interprtation 0 vrifiant (0) = 1 alors la distribution est dite normalise.
() = 0 correspond un tat impossible et signifie que nest certainement pas
compatible (ou insatisfaisant) avec les croyances disponibles.
() > 0 signifie que est quelque peu possible.
() >(`) signifie que est plus compatible (plausible, satisfaisant) que `.
Ensuite, tant donne une formule du langage L, on y dfinie deux valuations

partir de la distribution :
le degr de cohrence de avec les croyances disponibles exprimes par :

() = max () : .
Le degr de certitude ou de ncessit qui value dans quelle mesure la formule
peut tre dduit partir des croyances disponibles :
N() = 1- ()
6.2.2. Bases possibilistes
Une base possibiliste dsigne un ensemble de formules pondres :
= (i , ai) : i=1,..,n avec :

i est une formule classique (ou mme du premier ordre)
ai (]0, 1])dsigne le poids (niveau de priorit) de la formule i ,
Cest partir de la base quelles sont reprsentes syntaxiquement des

informations incertaines (ou des informations avec proprits).
Remarque :
Le couple (i , ai) signifie que le degr de certitude de la formule i est au moins
gale ai, c'est--dire, N(i ) ai
On dit quune formule est propritaire que la formule si N() N( ).
Elle est associe toute base possibiliste , une distribution de possibilit unique
note , de telle sorte que la valeur 1 (plus grand degr de possibilit) sera attribue
chaque interprtation de qui satisfait toutes les croyances de . Cependant les autres
interprtations qui ne satisfont pas totalement les croyances de la base seront ranges
par rapport la formule du plus grand poids qu'elles falsifient. Ainsi, on obtient la
dfinition suivante[11]:
, () =
1 si(i , ai) , i
1 max ai : (i , ai) et isinon
114
Si contient uniquement les formules compltement certaines, cest--dire ai=1,

i, alors () =1 ssi est un modle de la base (() =0 ssi est un contremodle).
Exemple 1:
Considrons lexemple suivant inspir de Cuppens [48] sur un problme de

scurit et qui concerne le classement de dossiers, contenant les composants des produits,
par leur niveau de confidentialit :
secret professionnel
change avec partenaires, et
public.
Supposons que les rgles de classement sont :
tout dossier concernant un nouveau produit est class secret professionnel.
les dossiers sont classs en change avec partenaire sur ordre du conseil de
lentreprise
Un dossier est class public ds quil devient caduc (par exemple, il existe un autre
produit plus efficace sur le march, ou encore le dossier a plus de vingt ans, etc.).
Imaginons que le dossier D concerne un nouveau produit. Ce fait est cohrent avec
lensemble des rgles. Supposons maintenant que lagent reoit une information
prioritaire o il est demand de classer D au niveau public. Il est clair que cette nouvelle
information contredit la base, et quil nexiste pas une faon unique de modifier la base et
de restaurer sa cohrence. Dans notre exemple, deux possibilits sont offertes :
Remettre en cause que D porte sur un nouveau produit, ou
Affaiblir la rgle concernant les nouveaux produits.
Soit = {(N D, 0.3), (O D, 0.6), (C D, 0.9), (N, 0.1)} la base de

croyances codant lensemble des rgles et des faits donn dans lexemple, o N, O, C, D
dsignent respectivement "nouveau produit", "ordre du conseil dentreprise", "produit
caduc", "un dossier donn". Ici les niveaux de certitude codent des niveaux de priorit
associe aux formules. Les niveaux de confidentialit "secret professionnel", "partage" et
"public" sont par convention cods par les degrs (daccessibilit) 0.3, 0.6, 0.9 (plus le
degr est petit, plus laccs au dossier est restreint). La distribution de possibilit associe
cette base est :
115

NOD
NOD
NOD
NOD
NOD
NOD
NOD
NOD
Autres
interprtations
()
1
1
1
1
0.7
0.4
0.1
0.1
0
Exemple 2 :
Considrons la base possibiliste suivante : = ( (r (p q),0.3) ,(r p, 0.9) ,(p,
0.1)), avec r, p et q des symboles propositionnels.
Les interprtations possibilistes (i)0i7 formant lensemble sont dfinies
comme suit :
i
0=
r p q
1= r p q
2= r p q
3= r p q
4= r p q
5= r p q
6= r p q
7=r p q
(i)
0.1
0.1
0.1
0.1
0.1
0.7
0.1
1
L'interprtation 7 est la prfre car elle satisfait toutes les formules de .

Nous allons rappeler la notion d'a-coupe et a-coupe stricte d'une base de croyances
possibiliste.
Dfinition 1: Soit une base possibiliste, a [0, 1], on appelle la a-coupe (resp. la acoupe stricte) de , note a (resp. >a) la base classique dfinie par :
a = i : (i , ai) et ai a(resp. ai>a)
lensemble : Inc()=maxai : ai est incohrente dsigne le degr dincohrence
de .
Quand est cohrente, on pose Inc() = 0. Le degr dincohrence Inc() est le degr
maximal tel que lensemble de formules ayant un poids suprieur Inc() est cohrent.
116
La a-coupe stricte est une notion importante, jouant un rle central dans le
processus dinfrence. Le concept dinfrence est dfini en logique possibiliste de la
faon suivante :
Dfinition :
Dfinition 2 : Une formule est une consquence possibiliste de , note , sil

existe un degr a [0, 1] tel que a et a est cohrente.
Lorsque a est maximal, alors a est appel le degr de certitude associ la
formule. Dans la suite, on crira (, a) si on veut aussi prciser le degr de
certitude des formules dduites de la base.
La dfinition prcdente montre que linfrence possibiliste se base uniquement sur
une sous-base cohrente, note Cons(), dfinie par :
Cons() = i : (i , ai) , ai> Inc().
On, effet on peut facilement vrifier que : ssi Cons()
Linfrence possibiliste peut tre tendue au cas des conditionnels, c'est--dire en

prsence dobservation . Une formule est une consquence possibiliste de , dans le
contexte , note simplement , ssi (, 1).
Les correspondances entre la syntaxe et la smantique tendent celle de la logique
classique. En effet, soit Bel() = : , () () lensemble des

interprtations prfres dans . Alors :
est cohrente ssi est normalise. Si est incohrente alors
Inc()=1 max ( ),
Les modles classiques de la sous-base Cons() concident avec les interprtations

prfres dans , c'est--dire Cons() = Bel(), et
ssi() ().
La dernire quivalence indique que linfrence possibiliste est une relation
dinfrence prfrentielle au sens de Bossu et Siegel [71] et de Shoham [72]
Exemple Reprenons lexemple 1 ci-dessus. On peut facilement vrifier que est
cohrente, c'est--dire, Inc()=0, et que ND = Bel().
Dfinition 3 :Soit ( , a) une croyance dans . Alors, ( , a) est dite sous-somme par si
( ( , a))a .
Cest--dire quune formule ( , a) est sous-somme (ou redondante) si elle est
infre par les autres formules ayant un niveau de certitude suprieure ou gal a. On peut
montrer que si ( , a) est une croyance sous-somme de , alors et = ( , a) sont
quivalentes, c'est--dire =
117
6.3. Ajout des priorits au modle OrBAC

Cette section se concentre sur le modle de contrle daccs bas sur lorganisation
OrBAC propose dans [10]. Ce modle est centr sur le concept de l'organisation et
modlis en logique du premier ordre. OrBAC offre la possibilit de prendre en compte la
notion de contextes, ce qui permet de reprsenter des rgles conditionnelles. OrBAC
permet galement de modliser les trois modalits dontiques : la permission,
l'interdiction et lobligation. En plus, diffrentes extensions ont t proposes pour traiter
par exemple les contextes temporels [49] ou pour manipuler l'administration des
politiques de scurit [12].
Ce chapitre propose une autre extension du modles OrBAC. L'ide est d'intgrer
l'incertitude [73]dans les diffrentes composantes de modles OrBAC. Nous
reconsidrons ces concepts de base du modle OrBAC[10], en utilisant un langage
(reprsent par un diagramme) bas sur le modle entit-relation. Pour chaque
composante, nous intgrons l'entit priorit afin de reflter l'incertitude qui peut tre
prsente dans la dfinition des rgles de scurit.
6.3.1. Organisation
Lorganisation est lentit la plus importante dans le modle OrBAC. Elle peut tre
considre comme un groupe organis de sujets qui jouent le mme rle. Comme nous le
verrons ci-dessous, tous les concepts principaux des politiques de scurit sont dfinis au
sein d'une organisation.
6.3.2. Sujets et rles
Dans le modle OrBAC, un sujet peut tre soit un utilisateur (par exemple, Tom ou
un processus), ou une organisation (par exemple, Distribution_Linux).
Lentit rle est utilise pour structurer des sujets dans des organisations. Les rles
associent des sujets remplissant les mmes fonctions.
Le fait que des sujets jouent certains rles dans des organisations, revient joindre
ces entits par la relation Emploi qui peut tre incertaine, gnralement cela se produit
quand il y a l'hritage entre rles. Dans certaines situations, quelques hritages peuvent
tre discutables.
La relation Emploi (org, s, r, p) (Cf.Figure 36) signifie que l'organisation org emploie le
sujet s dans le rle r.
118
Figure 36- La relation Emploi

6.3.3. Objets et vues
Dans le modle OrBAC, l'entit objet correspond aux entits inactives du systme.
Les "fichiers ordinaires" du systme d'exploitation Linux est un exemple d'objets.
Lentit vue correspond un ensemble d'objets qui satisfont une proprit commune, elle
caractrise la manire de lutilisation des objets dans les organisations, la relation Utilise
(org, o, v, p) signifie que l'organisation org utilise l'objet o dans la vue v.
p reflte encore l'incertitude associe visualiser l'objet o dans la vue v. Ici p peut
reflter une relation spcifique. Par exemple, considrons la commande (laction
concrte) Linux grep. Considrons deux activits : "lecture de documents" et
"recherche dexpressions dans les documents".
De toute vidence, grep est une action typique de " recherche dexpressions
dans les documents", alors quelle peut tre utilise dans lactivit "lecture de
documents", cependant, grep n'est pas une action typique pour une telle activit de
lecture.
Figure 37-La relation Utilise

6.3.4. Les actions et activits
Dans le modle OrBAC, lentit action contient des actions informatiques telles
que "lire", "crire", etc. de la mme manire que les sujets et les objets qui sont abstraits
en rles et vue, l'entit Activit correspond abstrait les actions qui partagent les mmes
principes (par exemple, criture, consultation, etc.)
La relation Considre sera utilise pour joindre les entits Organisation, action et
activit. Plus prcisment, Considre (org, , a, p) signifie que l'organisation org
considre qu'une action relve de l'activit a avec un degr d'incertitude p.
119
Figure 38-La relation Considre.

p peut reflter l'incertitude sur la source qui fournit la rgle de permission. La
source qui est base sur une ancienne loi (ou de la loi nationale) devraient avoir un degr
de certitude infrieur celui dune source base sur une loi rcente (ou d'une loi
europenne).
6.3.5. Contextes
Les contextes sont utiliss pour spcifier les circonstances concrtes dans
lesquelles les organisations accordent des permissions aux rles pour exercer des activits
sur des vues.
La relation dfinit (org, s, , o, c, p) signifie que dans lorganisation org, le

contexte c est vrai entre le sujet s, l'objet o et l'action avec un degr de certitude p.
Figure 39-La relation dfinit

6.4. Prioriser les autorisations abstraites et concrtes.
Dans le modle OrBAC, les relations Permission, Interdiction et Obligation,
correspondent des relations entre les organisations, les rles, les vues, les activits et les
contextes. La relation permission(org, r, a, v, c, p) signifie que l'organisation org accorde
au rle r la permission de raliser l'activit a sur la vue v dans le contexte c. Les relations
Interdiction_(org, r, a, v, c, p) et obligation(org, r, a, v, c, p) sont dfinies de faon
similaire.
120
Figure 40-La relation permission

Les relations Permission, Interdiction et Obligation sont introduites comme des
faits. Elles ne sont pas directement associes aux utilisateurs, actions et objets, mais
leurs abstractions respectivement aux rles, activits et vues.
Dans OrBAC, la relation Est_permis (s,, o, p) signifie que le sujet s est autoris
effectuer une action sur l'objet o avec un degr de certitude p. Les relations Est_Interdit
et Est_oblig sont dfinies de la mme manire. Ces relations sont drives logiquement
des permissions (respectivement Interdictions et obligations) accordes au rle de la
faon suivante:
(Pour chaque contextec)
s o r av
Permission (org, r, a, v, c, p1)

Emploi (org, s, r, p2)
Utilise (org, o, v, p3)
Considre (org, , a, p4)
Dfinit (org, s, , o, c, p5)
Est_permis (s, , o, f(p1, p2, p3, p4, p5))
Figure 41- La relation Est_permis

Dans le contexte c, si l'organisation org, accorde au rle r la permission de raliser
l'activit a sur la vue v avec l'incertitude p1, et si org emploi le sujet s dans le rle r avec
lincertitude p2, et si org utilise l'objet o dans la vue v, et si org considre que l'action
121
fait partie de lactivit a et si, au sein de l'organisation org, le contexte c est vraie entre s,
, et o, alors s est permis de raliser laction sur lobjet o avec lincertitude f(p1, p2, p3,
p4, p5).
De mme pour la relation Interdiction.
La question est maintenant de savoir comment dfinir f (p1, p2, p3, p4, p5)?
Diffrentes stratgies peuvent tre dfinies.
6.4.1. Mode de combinaison pessimiste:
L'ide dans le mode de combinaison pessimiste consiste dfinir le degr
d'incertitude associ une permission concrte comme tant le minimum des degrs
dincertitude des diffrents lments permettant de driver ladite permission concrtes,
savoir:
f (p1, p2, p3, p4, p5) min (p1, p2, p3, p4, p5)
Il s'agit d'une prcaution et par la suite dun moyen sr pour accorder des
permissions concrtes. Un des avantages de ce mode de combinaison, c'est que l'on peut
rutiliser directement la machine de logique possibiliste introduite 6.2 (La logique
possibiliste ci-dessus) l'article 2. L'ide est trs simple. Tout d'abord, les entits (sujets,
objets, vues, des rles, ...) sont reprsentes par des prdicats unaires du premier ordre
alors que les relations (Emploi, Utilise, permission, etc.) sont reprsentes par des
prdicats n-aires du premier ordre, en fonction du nombre darguments des relations. Puis,
nous construisons une connaissance possibiliste o le premier prdicat unaire prend le
degr 1 (il n'y a aucune incertitude), tandis que les prdicats n-aire de la forme Q (x1, ...,
xn, pi) sont transforms en (Q (x1, ..., xn), pi) o pi est le degr d'incertitude.
6.4.2. Mode de combinaison optimiste:
L'ide dans ce mode de combinaison est de dfinir le degr de certitude associ aux
permissions concrtes et ce en choisissant le maximum des degrs dincertitude des
diffrents lments permettant de driver ladite permission concrtes, savoir:
f (p1, p2, p3, p4, p5) max (p1, p2, p3, p4, p5)
De toute vidence, ce mode de combinaison est aventureux. Par exemple, un

utilisateur peut jouer un certain rle avec une incertitude, alors que toute permission
concrte drive (Est_permis) sera pleinement accorde, mme si les permissions
abstraites ne sont pas du tout certaines.
6.4.3. Mode de combinaison Actualis
L'ide dans ce mode de combinaison est de considrer chaque degr de certitude
comme un facteur d'actualisation. L'effet d'actualisation peut treobtenu en utilisant
l'oprateur de produit savoir:
122
f (p1, p2, p3, p4, p5)
p1 p2 p3p4 p5
De toute vidence, cette combinaison est trs prudente. Cependant, sa

transformation en base de connaissances possibilistes n'est pas immdiate et est coteuse.
6.5. Exemple dillustration
Dans un environnement Linux o SELinux est activ, on considre un processus
pwriter lanc par un utilisateur, ce processus se charge dcrire une quantit importante de
donnes sur un mdia de stockage (disque dur, bande, etc.).
Le contexte de scurit de pwriter (pwriter_u : pwriter_r : pwriter_t) lui est
attribu de diverses faons, dans cet exemple on sintresse au cas o le r-tiquetage de
ce processus peut (probablement) ne pas aboutiret par la suite choue cause d'un
contexte invalide. En effet, lauteur de la politique de scurit peut omettre, par exemple
lopration de montage de la partition /selinux, et par consquent lutilitaire
setfiles23dattribution des contextes ne peut les valider. Nous pouvons avoir la
partition /selinux mont, dans ce cas il est probable qu'une nouvelle politique n'ait pas
encore t charge et donc les contextes ne soient pas valides. Finalement, le processus
pwriter peut ne pas avoir le bon domaine SELinux cause de lexcution dune rgle de
transition inapproprie. Dans cet exemple, nous allons dterminer le degr de certitude le
plus appropri, partir des degrs de certitude des autres relations abstraites du modle
OrBAC pour que lopration dcriture soit ralise.
Si on suppose que le processus pwriter crive dans un fichier de disque appel
fich ayant le contexte de scurit SELinux : fich_u:fich_r:fich_tet que la
politique de scurit (SELinux) dispose dune rgle autorisant cette criture :
allow pwriter_t fich_t : file {getattr write};
En considrant que le type SELinux pwriter_t dsigne le rle OrBAC que joue le
sujet pwriter dans lorganisation SELINUX_DISTRIBUTION(=RHL4) . Laffectation du
sujet pwriter au rle OrBAC pwriter_t, peut tre imprgne de l'incertitude due au
moins lune des causes prcites. Cest--dire que lorganisation RHL4 emploie le
sujet pwriter dans le rle pwriter_t avec la priorit p empl :
Emploi(RHL4, pwriter, pwriter_t, pempl);
Notons dabord que V=(file, fich_t) dsigne la vue OrBac, dans laquelle
lorganisation RHL4 utilise lobjet fich.
Des causes comme celles prcites concernant laffectation des sujets aux rles,
peuvent aussi rendre cette utilisation incertaine. En effet, la vue V est compose de
23
Setfiles est un programme principalement utilis pour initialiser la base de donnes de contexte de scurit sur un
ou plusieurs systmes de fichiers.
123
llment fich_t qui suit les mmes procdures de r-tiquetage comme celle des
domaines.
Notons putil l'incertitude associe visualiser l'objet fich dans la vue V=(file,
fich_t) . Nous avons la relation suivante :
Utilise (RHL4, fich, V=( file, fich_t), putil)
Puisque write relve toujours de l'activit {write }, Lorganisation RHL4

considre que action write relve de l'activit {write } avec un degr d'incertitude
pact=1. La relation considere scrit :
Considre (RHL4, write, {write}, pact)
Pour ce qui est du contexte OrBAC, nous allons imposer un contexte

Cont_taille qui impose par exemple que le fichier fich copier ne doive pas avoir
une taille qui dpasse une taille fixe (exemple 5 giga octets) par ladministrateur de la
scurit.
Cont_taille est un contexte prrequis car la vrification de la taille des
informations copier dans le fichier fich peut tre faite en utilisant des commandes,
des filtres ou des scripts.
On insert galement la relation dfinit un degr dincertitude pcont tel que dans
lorganisationRHL4 , le contexte Cont_taille est vrai entre le sujet pwriter ,
l'objet fich et l'action write :
dfinit (RHL4, pwriter, write, fich, Cont_taille, pcont)
Dans cet exemple la relation Permission (resp. Interdiction et Obligation), relie

lorganisation RHL4, le rle fich_t , la vue V=(file,fich_t) , lactivit
{write } et le contexte Cont_taille .
On introduit galement un degr de priorit pperm (resp. pinte et pobli)
la relation permission(resp. Interdiction et Obligation), ce degr reflte lincertitude que
la relations qui relie les entits indiques soient relies.
La relation :
permission (RHL4, pwriter_t,{write},V=(file,fich_t),
Cont_taille, pperm)
signifie que l'organisation RHL4, accorde au rle fich_t la permission de

raliser l'activit {write } sur la vue V=(file, fich_t) dans le contexte
Cont_taille avec le degr de priorit pperm.
Les relations :
Interdiction (RHL4, pwriter_t ,{write},V=(file,fich_t),
124
Cont_taille, pinte)
Et
obligation(RHL4, pwriter_t,{write},V=(file, fich_t),
Cont_taille, pobli)
sont dfinies de faon similaire.

La relation concrte Est_permis (resp. Est_interdit, Est_oblig) est obtenue en drivant
logiquement la relation abstraite Permission (resp. Interdiction et Obligation) de la faon
suivante :
permission (RHL4, pwriter_t,{write},V=( file, fich_t),
Cont_taille, pperm)
Emploi(RHL4, pwriter, pwriter_t, pempl)
Utilise (RHL4, fich, V=( file, fich_t), putil)
Considre (RHL4, write, {write}, pact)
dfinit (RHL4, pwriter, write, fich, Cont_taille, pcont)
Est_permis(pwriter, write, fich, f(pperm, pempl, putil, pact, pcont))
Qui veut dire que :

Dans le contexte Cont_taille , si l'organisation RHL4, accorde au rle
pwriter_t la permission de raliser l'activit write sur la vue
V=(file,fich_t) avec l'incertitude pperm, et si RHL4 emploie le sujet pwriter
dans le rle pwriter_t avec lincertitude p empl, et si RHL4 utilise l'objet fich dans
la vue V=(file,fich_t) avec lincertitude p util, et si RHL4 considre que
l'action write fait partie de lactivit {write} avec lincertitude pact (=1) et si, au
sein de l'organisation RHL4, le contexte Cont_taille est vraie entre pwriter ,
write, et fich , } avec lincertitude pcont.
Alors pwriter est permis de raliser laction writesur lobjetfich avec
lincertitude pestpermis.
Le degr pestpermis est une fonction des autres degrs dincertitude relatifs aux
relations abstraites :
pestpermis=f(pperm, p empl, p util, pact, pcont).
Le moyen sr pour obtenir la permission concrte est de choisir le mode pessimiste
(base sur le choix de la priorit minimale), c'est--dire :
pestpermis = min(pperm, p empl, p util, pact, pcont).
Remarque: Dans cet exemple, le mode optimiste bas sur le choix de la priorit
maximale rend sure la ralisation de la permission concrte, car pact =1 et ce malgr
lincertitude de la ralisation dau moins lune des relations abstraite. En effet, et comme
nous lavons invoqu au prambule de lexemple, lopration (SELinux) de r-tiquetage
125
peut chouer et par consquent lorganisation RHL4 serait incertaine demployer le

sujet pwriter dans le rle (OrBAC) pwriter_t( c'est--dire que p empl1).
6.6. Conclusion
Ce chapitre proposait une extension du modle OrBAC en intgrant le concept de
priorit qui peut tre associs avec les rgles de la politique de scurit. Ces priorits sont
reprsentes dans le cadre la thorie des possibilits. Nous avons propos diffrentes
rgles d'agrgation pour driver les priorits associes aux permissions concrtes partir
des rgles prioritaires des permissions abstraites.
Parmi les trois modes de combinaison proposs, le mode pessimiste (bas sur le
choix de la priorit minimale) est le plus appropri, car il fournit un moyen sr pour
obtenir la permission concrte. De plus, il peut tre facilement cod en logique
possibiliste partir de laquelle des infrences efficientes peuvent tre appliques.
Ce travail est important puisquil traite des rgles de scurit incertaines et il peut
galement tre utilis pour rsoudre les conflits induits par la prsence simultane des
rgles de permission et d'interdiction.
Le chapitre 7 illustre la gestion des incertitudes est des priorits travers l'implmentation
du dernier exemple (6.5-Exemple dillustration).
126
Chapitre 7
Implmentation
7.1. Introduction
Ce chapitre prsente l'implmentation du codage de la politique SELinux en
Modle OrBAC, notamment en ce qui concerne les dcisions daccs.La gestion des
incertitudes est les prioritssont illustres et trait traversle dernier exemple du chapitre
prcdant.
Limplmentation de lexemple sus-indiqu, ncessite dans un premier temps,
lajout du sujet pwriter et de lobjet fich la base de donnes que nous avons cre
au pralable afin de la connecter notre application. Ensuite, nous saisissons les contextes
de scurit SELinux : (pwriter_u, pwriter_r, pwriter_t) et (fich_u,
fich_r, fich_t).
Lapplication prvoit la liaison des sujets (ou objets) aux identifiants SELinux, des
identifiants SELinux aux rles et des rles aux types/domaines.Une fois cette tape
termine, nous disposons donc de tous les lments pour remplir, travers lapplicatif, les
tables du modle OrBAC par les entits SELinux correspondantes.
Nous avons paramtr notre programme pour quil supporte par dfaut
lorganisation : CENTOS et le contexte (OrBAC) : DEFAULT.
Pour chaque relation de notre exemple, lapplication lui attribue arbitrairement un
nombre (lment de lintervalle] 0, 1]) qui reprsente une simulation de la priorit qui
pondre la relation en question.
La relation concrteIs_permittedrsultantepossde une priorit calcule en
fonction du mode de combinaison utilis : optimiste, pessimiste ou avanc.
La premire partie de ce chapitre prsente sous un format graphique le Modle
Conceptuel de Donnes (MCD) des entits utilises par SELinux, puis le Modle
Physique de Donnes (MPD) correspondant. Il sagit dune tape prliminaire pour
reprsenter le MCD et le MPD du modle OrBAC lesquels sont prsents la deuxime
partie de ce chapitre. Pour cela nous avons utilis PowerAMC, un logiciel de conception
des modles, sont choix est motiv par le fait quil reste un des seuls logiciels qui permet
de travailler avec la mthode MERISE. Ainsi il est facile de gnrer le script SQL de
cration de la base de donnes, selon le SGBD (Systme de Gestion de Bases de
Donnes) voulue.
Notre application est construite laide de lenvironnement de dveloppement
Borland Delphi qui est un logiciel de dveloppement rapide RAD (Rapid Application
Development). Il permet de raliser rapidement et simplement des applications Windows,
127
avec un minimum de ligne de code. Sa version 7 que nous avons choisiefournit beaucoup
de fonctionnalits ncessaires pour le dveloppent dapplication.
Nous avons encore choisi le SGBDR natif de Delphi qui est Paradox (version 7)
pour crer notre base de donnes. Les tables sont cres manuellement car le logiciel
PowerAMC ne permet pas de gnrer, partir du modle MPD, le script SQL de cration
dune base de donnes de type paradox.
Une base de donnes de type MySQL par exemple peut tre cre facilement
partir du script SQL gnr par le logiciel PowerAMC, mais il reste non vident de
russir la connecter lenvironnement Delphi malgr lutilisation de lODBC (Open
Database Connectivity) sous windows_7.
7.2. Le MCD des lments SELinux
Les lments du systme (Linux) entrant en jeux pour la dcision du contrle daccs
SELinux sont :
Liste des entits :
action (id_action, action)
Classe_Objet (Id_Classe, Classe)
Objet_Linux(Id_Objet, Objet)
Rle_SELinux(Id_role, role)
Sujet_Linux(Id_Sujet, Sujet)
Type_SELinux(Id_type, type)
User_SELinux(Id_SELinux, User_SELinux)
Liste des associations :
Appartient : Objet_Linux <-->User_SELinux
Confine : Rle_SELinux <-->Type_SELinux

Dtient : action <--> Classe_Objet
Joue : Rle_SELinux<--> User_SELinux
Lie : Sujet_Linux <-->User_SELinux
Possde : Classe_Objet <--> Objet_Linux

128
Le diagramme MCD de SELinux se prsente comme suit :

joue
1,n
est jou par
joue
lie
Est li
lie le
1,n
1,n
0,n
Sujet_Linux
Id_Sujet_Linux <pi> Texte (8) <O>
Sujet_Linux
Texte (16) <O>
pk_suobjet <pi>
...
User_SELinux
Rle_SELinux
Id_SELinux <pi> Texte (16) <O>

User_SELinux
Texte (20)
Id_role <pi> Caractre long variable (16) <O>

role
Caractre long variable (20)
Identifiant_2 <pi>
...
Identifiant_1 <pi>
...
1,n
Objet_Linux
1,n
Id_Objet <pi> Caractre long variable (16) <O>

Objet
est confin dans

0,n
appartient
est proprietarie de
est la proprit de
confine
Identifiant_1 <pi>
...
confine
0,n
1,1
est de classe
Possde
concerne
Classe_Objet
Type_SELinux
Id_Classe <pi> Caractre long variable (16) <O>

Classe
Caractre long variable (20) <O>
Id_type <pi> Caractre long variable (16) <O>

type
pk_classe <pi>
Identifiant_1 <pi>
1,n
est concerne par
action
Id_action <pi> Caractre long variable (16) <O>
action
1,n
concerne
dtient
1,n
Identifiant_1 <pi>
...
Diagramme 1- MCD des lments SELinux

Il sagit dune representation formelle (Cf. Diagramme 1) des informations que SELinux
utilise pour assurer son contrle dacces. Elle nest pas directement exploitable par un
SGBDR, de ce fait notre MCD est ensuite deriv en un autre modleappel
modlephysique de donnes (MPD). (Cf. Diagramme 2)
Le MPD de SELinux
129
lie
joue
Id_Sujet_Linux TEXT <pk,fk1>

Id_SELinux
TEXT <pk,fk2>
Est li
lie le
Id_SELinux TEXT <pk,fk1>

Id_role
TEXT <pk,fk2>
joue
est jou par

Rle_SELinux
Sujet_Linux
User_SELinux
Id_Sujet_Linux TEXT <pk>

Sujet_Linux
TEXT
Id_SELinux
TEXT <pk>
User_SELinux TEXT
est confin dans

confine
Id_role TEXT <pk,fk1>
Id_type TEXT <pk,fk2>
est proprietarie de
Objet_Linux
est la proprit de
Id_Objet TEXT <pk>

Id_Classe TEXT <fk>
Objet
TEXT
appartient
Id_SELinux TEXT <pk,fk1>
Id_Objet
TEXT <pk,fk2>
est de classe
confine
Classe_Objet
concerne
Id_Classe TEXT <pk>

Classe
TEXT
Type_SELinux
Id_type TEXT <pk>
type
TEXT
est concerne par

action
Id_action TEXT <pk> concerne
action
TEXT
dtient
Id_Classe TEXT <pk,fk1>
Id_action TEXT <pk,fk2>
Diagramme 2- Le MPD des lments SELinux
130
Id_role TEXT <pk>

role
TEXT
Le MCD dOrBAC
Les lments du modle OrBACqui entrent en jeux pour llaboration du MCD sont :
Liste des entits :
action(Id_activite, Activite)
Classe_Objet(Id_Classe, Classe)
Contexte(Id_Contexte, Contexte)
Objet_Linux(Id_Objet, Objet)
Organisation(Id_Organisation, Organisation)
Priorite(Id_priorite, priorite)
Type_SELinux(Id_type, type)
User_SELinux(Id_SELinux, User_SELinux)
Liste des associations :
Consider : <-->( Organisation, action, action2,Priorite)
Define: <--> (Organisation, User_SELinux, action, Objet_Linux,

Contexte,Priorite)
Employ: <-->( Organisation, User_SELinux, Type_SELinux, Priorite)

Is_permitted: <-->( User_SELinux, action, Objet_Linux, Priorite)
permission: <-->( Organisation,Type_SELinux, action, Classe_Objet,

Type_SELinux2, Contexte, Priorite)
Use: <-->( Organisation, Objet_Linux, Classe_Objet, Type_SELinux2, Priorite)
131
0,n
Organisation
Id_Organisation <pi> Texte (16) <O>
Organisation
Texte (30)
Identifiant_1 <pi>
...
0,n
Type_SELinux
Vue OrBAC
Classe_Objet
0,n
Id_Classe <pi> Texte (16) <O>

Classe
Texte (20) <O>
0,n 1,n
0,n
Id_type <pi> Texte

<O>
type
Texte (20)
pk_classe <pi>
Identifiant_1 <pi>
Type_SELinux2
0,n
1,n
Id_type Texte (16) <O>
type
Texte (20)
permission
0,n
0,n
Employ
Use
0,n
0,n
Priorite
Id_priorite <pi> Squentiel (3) <O>
priorite
Rel court
0,n
0,n
pk_priorite <pi>
...
0,n
0,n
Contexte
Id_Contexte <pi> Texte (16) <O>
Contexte
Texte (30) <O>
Is_permitted
Consider
0,n
0,n
0,n
Id_SELinux <pi> Texte (16) <O>

User_SELinux
Texte (20)
0,n
0,n
1,1
Objet_Linux
Id_activite <pi> Texte (16) <O>

Activite
Texte (20)
Identifiant_1 <pi>
...
Identifiant_2 <pi>
...
1,n
0,n
1,1
action
User_SELinux
pk_contexte <pi>
...
0,n
Id_Objet <pi> Texte (16) <O>

Objet
Texte (20)
Identifiant_1 <pi>
...
0,n
0,n
0,n
Define
Diagramme 3-Le MCD des lments d'OrBAC
132
Organisation
Id_Organisation text <pk>
Organisation
text
Classe_Objet
Id_Classe text <pk>
Classe
text
Type_SELinux
permission
Id_type text <pk

type
text
Id_Organisation
Id_type
Id_action
Id_Classe
Typ_Id_type
Id_priorite
Id_Contexte
Id_activite
Employ
Id_SELinux
Id_priorite
Id_Organisation
Id_type
text
int(3)
text
text
text
text
text
text
text
int(3)
text
text
<pk,fk5>
<pk,fk1>
<pk>
<pk,fk2>
<fk6>
<pk,fk3>
<pk,fk4>
<fk7>
Use
Id_Organisation
Id_Objet
Id_Classe
Id_type
Id_priorite
<pk,fk2>
<pk,fk3>
<pk,fk4>
<pk,fk1>
Priorite
Id_priorite int(3) <pk>
priorite
real
Is_permitted
Id_SELinux
Id_action
Id_Objet
Id_priorite
Id_activite
text
text
text
int(3)
text
<pk,fk1>
<pk>
<pk,fk4>
<pk,fk3>
<fk2>
Consider
Id_Organisation
Id_action
Id_activite
Id_priorite
act_Id_activite
Contexte
text
text
text
int(3)
text
<pk,fk3>
<pk>
<fk1>
<pk,fk4>
<fk2>
Id_Contexte text <pk>

Contexte
text
Objet_Linux
Id_Objet text <pk>
Objet
text
action
User_SELinux
Id_SELinux
text <pk>
User_SELinux text
Id_activite text <pk>

Activite
text
Define
Id_organisation
Id_SELinux
Id_Objet
Id_action
Id_Contexte
Id_priorite
Id_activite
text
text
text
text
text
int(3)
text
<ak,fk5>
<ak,fk1>
<ak,fk6>
<ak,fk3>
<ak,fk4>
<ak,fk2>
Diagramme 4- Le MPD des lments d'OrBAC
133
text
text
text
text
int(3)
<pk,ak,fk4>
<pk,ak,fk2>
<pk,ak,fk1>
<pk,ak,fk5>
<pk,ak,fk3>
7.3. Prsentation de lapplication

Cette partie a pour objet de prsenter des copies dcran de lapplication
implmentant le codage de la politique SELinux en OrBAC ainsi que les simulations des
priorits.
7.3.1. La page d'accueil
La page d'accueil Simulation des priorits (Cf. Figure 42)du programme permet
de choisir lun des quatre menus droulants : Entits SELinux, Entits OrBAC,
Autorisations et Paramtres (Cf. Figure 43):
Figure 42- La page d'accueil "Simulation des priorits"
Figure 43- Les menus du programme.

Dans la suite de ce chapitre nous prsentons les diffrentes fonctionnalits des
menus, au fur et mesure de la saisie des informations de lexemple implmenter.
Saisie des lments Linux : il sagit de saisir des objets, des sujets, des classes dobjet
et des actions du systme. Dans notre cas, nous nous contenterons de saisir seulement
les lments qui entrent en jeux pour former la rgle de scurit SELinux suivante :
allow pwriter_t fich_t : file {write};
134
Nous saisissonsdonclobjet fich, le sujet pwriter, la classe dobjet file et

laction write.
Les menus Entits SELinux > lment Linux > Sujet Linux etEntits
SELinux>lmentLinux >Objet Linux permettent de saisir respectivement le sujet
pwriter (Cf. Figure 44) et lobjet fich (Cf. Figure 45) :
Figure 44-Saisie d'un Sujet Linux
Figure 45-Saisie d'un Objet Linux

La saisie dun objet doit tre prcde par la saisie de sa classe correspondante. La
distribution CentOS 6.2 dfinit 81 classesd'objets, ce qui rend plus facile
deregroupercertaines permissions pardes classes spcifiques, chacune de ces
classes est reprsentes sous forme dun rpertoire contenant des permissions elles
sont tous localises dans le rpertoire/selinux/class. Au sein de notre
implmentation nous nous contentons de saisir quelques classes dobjets : file
que nous introduisons travers la fentre (Cf.Figure 46) qui se trouve au menu :
Entits SELinux > lment Linux > Classe dobjet.
135
Figure 46- Les classes d'objet
Le menu Entits SELinux > lment Linux > Actions permet de saisir les actions
supportes par les objets Linux (Cf. Figure 47), laction write est saisie comme suit :
Figure 47- Saisie d'une action
Saisie des contextes de scurit : Nous saisissons ensuite les contextes de

scurit SELinux:
(pwriter_u:pwriter_r:pwriter_t)
et
(fich_u:fich_r:fich_t) respectivement de lutilisateur pwriter et de
lobjet fich (Cf. Figure 48, Figure 49 et Figure 50).
Ajout dun identifiant SELinux:Le menu Entits SELinux > Contexte SELinux >
User_u permet de saisir des identifiants SELinux, dans notre exemple la saisie des
identifiants pwriter_u et fich_u se fait travers la fiche intitule Utilisateur
SELinux (Cf. Figure 48)
136
Figure 48-Ajout d'un identifiant SELinux

Ajout dun rle SELinux: Le menu Entits SELinux > Contexte SELinux >
Role_u permet de saisir des rles SELinux, dans notre exemple la saisie des rles
pwriter_r et fich_r se fait travers la fiche intitule Rle (Cf. Figure 49)
Figure 49-Ajout d'un rle SELinux

Ajout dun rle SELinux: Le menu Entits SELinux > Contexte SELinux >
Type/Domaine permet de saisir des types (ou domaines) SELinux, dans notre exemple
la saisie du domaine pwriter_t et du type fich_t se fait travers la fiche
intitule Type/Domaine (Cf. Figure 50)
137
Figure 50-Ajout d'un Type/Domaine SELinux

Attribution didentifiant SELinux : Lattribution dun identifiant SELinux a un sujet
ou un objet est assur respectivement par les menusEntits SELinux > Attribution
didentit > un objet et Entits SELinux > Attribution didentit > un sujet.
Dans notre exemple on attribue respectivement lobjet fich et au processus
pwriter les identitsSELinux :fich_u et pwriter_u et ce travers les
fiches (Cf. Figure 51 et Figure 52) portant respectivement les titres Lier un objet
Linux une Identit SELinux et Lier un utilisateur Linux une Identit
SELinux.
Figure 51-Attribution d'une Identit SELinux un Objet
138
Figure 52-Attribution d'une Identit SELinux un Sujet

Attribution de rle : chaque identifiant SELinux on attribue un rle, par exemple aux
identifiants : fich_u et pwriter_u sont associs respectivement les rles fich_r et
pwriter_r. cette fonctionnalit est assure via la fiche intitul Identit -->Rle (Cf.
Figure 53) qui se trouve au menu : Entits SELinux > Attribution de Rle.
Figure 53- Attribution de Rle
139
Attribution dun Type/Domaine : Chaque rle SELinux est mis dans un type (ou un
domaine), dans notre cas les rles fich_r et pwriter_r sont confins
respectivement dans le typefich_t et le domaine pwriter_t via la fiche (Cf.
Figure 54) qui se trouve au menu : Entits SELinux > Attribution de
Type/Domaine.
Figure 54-Attribution d'un Type/Domaine
Saisie dune Organisation : Lcran Organisation (Cf. Figure 55) qui se trouve dans
le menu : Entits OrBAC> Organisation permet de saisir les organisation OrBAC.
Dans notre cas, lorganisation considrer est la distribution de Linux, elle est
dterminer en utilisant la commande: cat /etc/redhat-release (Cf.Listing
2) pour connatre la distribution/version de Linux (Centos).
Listing 2-Distribution Linux
140
Figure 55- Saisie des organisations OrBAC
Saisie dun contexte OrBAC :

trouve dans le menu : Elment
supprimer un contexteOrBAC.
DEFAULT pour signifier que
supplmentaires.
La fiche Contexte OrBAC(Cf. Figure 56) qui se

OrBAC> Contexte OrBACpermet dajouter ou de
Nous utilisons dans notre exemple le contexte
les autorisations seront excutes sans contraintes
Figure 56-Saisie du Contexte OrBAC
La relation Employ : le menu Entits OrBAC> User-->Rle permet de simuler

une priorit alatoire pour quun sujet OrBACjoue un rle OrBAC (type/domaine
SELinux). Dans notre exemple lorganisation CentOS emploie le sujet pwriter
dans le rle OrBACpwriter_t avec la priorit pempl=0,38(Cf.Figure 57)
141
Figure 57- Simulation d'une priorit de la relation Employ
La relation Consider : le menu Entits OrBAC> Action-->Activit permet de

simuler une priorit alatoire pour quune action soit considre comme une
activit. Dans notre exemple lorganisation CentOS considre toujours laction
write comme une activit portant le mme nom : {write } avec un degr de
priorit pact=1. (Cf.Figure 58)
Figure 58-Simulation d'une priorit de la relation Consider
La relation Use : Dans le men Entits OrBAC> Objet-->Vue, on trouve la fiche

intitul La relation USE (Cf. Figure 59), elle permet de simuler la priorit pour
quun objet soit utilis dans une vue. Dans notre cas, lobjet fich est utilis dans
la vue (file, fich_t) avec la priorit putil = 0,08.
142
Figure 59-Simulation d'une priorit de la relation Use
La relation Permission : Dans le menu Autorisations > Abstraites> Permission,

on trouve la fiche intitule Permission (Cf.Figure 60), elle permet de simuler la
priorit pour quun rle excute une activit sur une vue. Dans notre cas cela
signifie que l'organisation CentOS accorde au rle OrBACfich_t la
permission de raliser l'activit {write } sur la vue V=(file, fich_t),
dans le contexte DEFAULT avec le degr de priorit pperm = 0,15.
Figure 60-Simulation d'une priorit de la relation Permission
La relation Define : Dans le men Autorisations > La relation Define,on trouve

la fiche intitule La relation Define(Cf. Figure 61) qui permet de simuler une
priorit pcont =0,21 tel que dans lorganisationCentOs , le contexte DEFAULT
est vrai entre le sujet pwriter , l'objet fich et l'action write.
143
Figure 61-Simulation d'une priorit de la relation Define

La
relation
concrte
Is_permitted :
Dans
le
menu
Autorisations>Concrtes>Is_permitted, on la fiche intitule : La relation concrte:
Is_permitted (Cf.Figure 62) dans laquelle nous simulons la priorit de la relation
Is_permitted. Dans notre exemple cela veut dire que dans le contexte DEFAULT , si
l'organisation CentOs, accorde au rle pwriter_t la permission de raliser
l'activit {write} sur la vue V=(file, fich_t) avec l'incertitude pperm,=0,15 et si
CentOs emploi le sujet pwriter dans le rle pwriter_t avec lincertitude
p empl=0,38 , et si CentOs utilise l'objet fich dans la vue V=( file, fich_t)
avec lincertitude p util=0,08 , et si CentOs considre que l'action write fait partie
de lactivit {write} avec lincertitude pact =1 et si, au sein de l'organisation
CentOs, le contexte DEFAULT est vraie entre pwriter , write, et fich avec
lincertitude pcont=0,21, alors pwriter est permis de raliser laction writesur
lobjetfich avec lincertitude pestpermis(Cf. Figure 63) qui peut avoir lune des trois
valeurs : PIs_permPis , PIs_permOpt ouPIs_permAvarespectivementselon que le mode de
combinaison considrer est soit Pessimiste, Optimiste ou Avanc.
Avec :
PIs_permOpt = min(pperm, p empl, p util, pact, pcont)=min(0.38, 1, 0.8, 0.15, 0.21)=0.8
PIs_permPis = max(pperm, p empl, p util, pact, pcont)=max(0.38, 1, 0.8, 0.15, 0.21)=1
PIs_permAva =f(pperm, p empl, p util, pact, pcont)=0.38 * 1 * 0.8 * 0.15 * 0.21.
144
Figure 62- Calcul de la priorit de la relation Is_permitted
Figure 63-Rcapitulatif des pondrations des relations OrBAC

Les paramtres par dfaut : le menu Paramtres>Paramtres permet
travers la fiche Paramtres par dfaut (Cf. Figure 64) de choisir lorganisation et
le contexte OrBAC par dfaut.Le programme stocke Ces paramtres dans la
table DefaultOrgCont.db pour une rutilisation ultrieure lors des prochaines
sessions.
145
Figure 64 - Paramtres par dfaut.

Une table appele AllPriorite a aussi t rajoute la base de donnes pour servir de
conteneur dinformations des relations ainsi que des priorits correspondantes, il sagit
dune table auxiliaire qui peut contenir au maximumun enregistrement. Le vidage de la
table AllPriorite se fait travers la mme fiche (Cf. Figure 64) en choisissant le
radioboutonOui de loption Vidage de la table des simulations, lapplication propose
ensuite la confirmation de ce vidage (Cf. Figure 65 ).
Figure 65- Confirmation du vidage de la table des simulations
146
CONCLUSION ET PERSPECTIVES
Au sein de la prsente thse, nous avons prsent ltat de lart des diffrents modles de
contrles daccs prsents dans la littrature (DAC, RBAC, MAC), nous avons aussi montr pour
chacun de ces modles prsents, les points forts ainsi que leurs primtres dapplication. Nous
avons aussi mis en exergue les limites de ces modles.
Ensuite, nous avons prsent dans cette thselemodle OrBAC
(Organization Based
Access Control), une extension du modle RBAC. Il permet de dfinir la notion de contexte
comme tant une disposition particulire qui permet d'activer ou de dsactiver des autorisations.
OrBAC permet aussi dexprimer, en plus des permissions, des interdictions et des obligations et
de grer les conflits qui peuvent apparatre en prsence de ces autorisations.
En OrBAC, la notion dorganisation est trs importante, car elle dtermine la smantique
de chaque entit de ce modle, elle peut avoir le sens dun groupe de sujet, dun service dans une
direction, comme elle peut mme avoir le sens dune distribution/version du systme
dexploitation Linux. Ainsi chaque organisation structure ses sujets pour les employer dans des
rles, ses actions pour les considrer dans des vues et ses objets pour les utiliser dans des vues.
Cette structure gnre deux niveaux dabstraction: le niveau abstrait contenant les rles, activit
et vues et le niveau concret qui comprend les sujets, les actions et les objets. Labstraction des
entits permet de sparer la rdaction de la politique de scurit de son implantation.
Nous avons aussi prsent SELinux comme une solution de scurit qui sintgre au
noyau Linux. Elle utilise un ensemble de modles de contrle daccs comme DAC, RBAC, et
MAC pour fournir une couche de vrification supplmentaire, qui va au-del de ce qui est dj
fourni par le modle DAC. Chaque accs un objet sera vrifi par rapport la politique de
scurit du systme. Cette vrification est en plus des vrifications des droits daccs classiques
habituels effectues par le modle DAC.
Les dcisions de contrle d'accs de SELinux sont faites en utilisant les labels de scurit
qui sont reprsents par des chanes comme entite_u:role_r:type_t. Chaque dcision
de contrle d'accs implique deux contextes : celui de l'utilisateur tentant de raliser l'action et
147
celui de l'objet sur lequel l'action est ralise. SELinux utilise les inodes pour stocker les
contextes de scurit des fichiers.
La politique de scurit SELinux possde aussi des rgles spciales connues sous le nom
de rgles de transition, auquel cas un contexte diffrent du contexte initial est affect un sujet
lorsque cela est requis pour excuter un programme, une commande particulire ou une
procdure de confiance ncessitant un accs privilgi une ressource. Les objets nouvellement
crs se voit galement changer leur contexte, et ce dans le cas o cet objet hrite du contexte de
scurit de l'objet parent (par exemple un fichier cr dans un rpertoire).
Les rgles de dcision, de transition et les dclarations des diverses entits du systme
constituent la politique de scurit SELinux. Les rgles de la politique SELinux commencent
gnralement
par
les
mots
cls :
allow,
auditallow,
dontaudit,
type_transition. Nous recensons :

-
268004 rglesallowutilises par dfaut, dans la politique de la distribution

Fedora_14
11134 rglesallowutilises par dfaut, dans la politique de la distribution RHL4.
Ce nombre important de rgles rend la politique SELinux trs complexe et alourdit sa

gestion. Nous avons exploit lexpressivit du modle OrBAC pour coder les rgles daccs de la
politique de scurit prsente par dfaut sur SELinux, nous avons utilis la distribution Fedora
14. Notrecodage consiste remplir les tables du modle OrBAC par les entits SELinux
correspondantes. Nous avons suppos que nous disposons dune seule organisation appele
Distribution_Linux, et qu'aucune condition particulire nest exige pour l'application des
rgles de scurit, c'est--dire que le contexte OrBAC est fix la valeur TRUE (ou DEFAULT).
Dautres adaptations ont t faites au niveau de quelques entits pour assurer convenablement le
codage : Les types/domaines SELinux correspondent aux rles OrBAC et les objets SELinux
correspondent la vue forme du couple constitu par le la classe de lobjet et le type de lobjet.
Le codage des transitions a t galement trait, nous avons pu coder lattribution des
types par dfaut en plus des transitions des domaines lies la procdure de changement de mot
de passe (procdure de confiance). Les valeurs des contextes ont t adaptes selon la prsence
ou non dune rgle explicite de transition, les adaptations des entits demeure les mme que pour
les rgles daccs.
148
Nous avons montr ainsi que le modle OrBAC ne concerne pas seulement le domaine
mdical (organisation=Hopital, Service des urgences, etc.), mais aussi bien les systmes
dexploitation (organisation=Distribution_Linux).
Une amlioration importante du modle OrBAC a t apporte par cette thse, il sagit de
lintroduction de lentit priorit chaque relation (Emploie,
Considre,
Utilise, Permission, Est_permis) du modle OrBAC. Lentit priorit quantifie

(valeur relle dans ]0, 1]), pour chaque entit, la certitude pour quun sujet soit employ dans un
rle, une action soit considre dans une activit, un objet soit utilis dans une vue, etc.
La relation concrte Est_permis(resp. Est_interdit, Est_oblig) drive de la relation
abstraite Permission (resp. Interdiction, Obligation)est galement pondre par une priorit qui
dpend de celles des relations abstraites : Emploie, Considre, Utilise,Dfinit
etPermission (resp. Interdiction, Obligation).
Diverses stratgies peuvent tre adoptes pour dterminer la valeur de la priorit de
chaque relation concrte partir des priorits des relations abstraites correspondantes :
Considrer la priorit drive comme tant le minimum des priorits des
relations abstraites correspondantes. Il s'agit d'une prcaution et par la suite dun moyen
sr et trs scuritaire pour accorder des permissions concrtes, Il sagit dun mode de
combinaison pessimiste.
Considrer la priorit drive comme tant le maximum des priorits des
relations abstraites correspondantes. Cest un mode de combinaison optimiste et

aventureux.
Considrer la priorit drive comme tant une combinaison des facteurs
dactualisation des priorits des relations abstraites correspondantes, Ce mode

dactualisation est trs prudent. Cependant, sa transformation en base de connaissances
possibilistes n'est pas immdiate et couteuse.
Pour illustrer la notion de priorit, un exemple a t prsent concernant un processus
tentant deffectuer une opration dcriture dans un fichier volumineux, cet exemple possde la
particularit de la valeur de lentit priorit lie la relation considre. Cettevaleur vaut
1, car dans le codage de SELinux en modle OrBAC nous avons assimilla relation considre
lidentit. Par consquent le choix de mode de combinaison optimiste nest surtout pas
149
une bonne ide, car la relation concrte serait certaine indpendamment des degrs de certitude
des relations abstraites correspondantes.
Plusieurs perspectives peuvent tre traites pour montrer davantage lexpressivit et
lvolutivit du modleOrBAC, telles que par exemple llargissement de son primtre
dapplication, notamment en ce qui concerne le codage des politiques de scurit des bases de
donnesdune part, et le codage des priorits dexcution des processus Linux(voir utilisation de
la commande nice de Linux) dautre part et ce en essayant de trouver une relation entre ces
prioritset celles concernant le degr de certitude trait dans le chapitre 6.
Codage des politiques de scurit des bases de donnes : maintenant que nous avons pu
coder la politique de scurit SElinux en modle OrBAC, nous pouvons tendre notre champ
dapplication pour coder les politiques de scurit des bases de donnes utilisant les mmes
principes et techniquesquutiliseSELinux en matire dtiquetage de ses entits. Nous pouvons
utiliser SEPostgreSQL comme un exemple de SGBDR24afin d'illustrer notre codage. Aux objets
de la base de donnes tels que : les tables, les colonnes, les lignes, les procdures, etc. sont
attribus des contextes de scurit qui contiennent les mmes composantes que celles utilises par
SELinux (Cf. 1) avec une utilisation davantage des composants optionnels : Le niveau MLS et
la catgorie MCS.Par exemple les contextes suivant sont associsrespectivement une table et
ses deux colonnes :
unconfined_u:object_r:sepgsql_table_t:s0:c10(contexte de la table).
unconfined_u:object_r:sepgsql_table_t:s0:c10 (contexte de la colonne 1 de la table).

unconfined_u:object_r:sepgsql_table_t:s0:c20 (contexte de la colonne 2 de la table).
Pour pouvoirsupporter et grer les informations du contexte de scurit (les labels),

SEPostgreSQL a d tendre et ajouter plusieurs utilitaires, fonctions, objets, etc. En effet, par
exemple les tables internes suivantes ont t ajoutes : pg_database, pg_class,
pg_attribute et pg_security.
Une dcision de contrle d'accs est prise en tenant en considration une paire de contexte
de scurit : Les contextes de scurit du client et de lobjet (exemple une table) de la base de
donnes. Le SEPostgreSQL appel SELinux pour lui communiquer lensemble des actions
autorises entre le contexte du client et le contexte de lobjet. Il y a donc une collaboration troite
entre SEPostgreSQL et SELinux.
24
Un SGBDR (RDBMS en anglais) (Systme de Gestion de Base de Donnes Relationnel) est un logiciel qui permet de manipuler le contenu des
bases de donnes relationnelles.
150
A linstar de SELinux et pour coder la politique de scurit SEPostgreSQL en OrBAC,

nous devons fournir dabord pour chaque concept (client, rle, table, colonne, contexte,
etc...)utilis dans SEPostgreSQL, son homologue dans le modleOrBAC. Cest une opration qui
nest pas toujours facile mettre en uvre puisquelle dpond essentiellement des faons dont les
quelles lesdits concepts sont configurs dans le SGBD. En effet, PostgreSQL[74]gre les droits
d'accs aux bases de donnes en utilisant le concept de rles. Un rle peut tre vu soit comme un
utilisateur de la base de donnes, soit comme un groupe d'utilisateurs de la base de donnes,
suivant la faon dont le rle est configur. Les rles peuvent possder des objets de la base de
donnes (par exemple des tables) et peuvent affecter des droits sur ces objets d'autres rles pour
contrler qui a accs ces objets. De plus, il est possible de donner l'appartenance d'un rle un
autre rle, l'autorisant du coup utiliser les droits affects au rle dont il est membre.
Dautres fonctionnalits de PostgreSQL, telles que l'hritage, les vues, les fonctions, les
dclencheurs et la gestion des dpendancesdoivent avoir leurs homologues en OrBAC.
Dautres rgles doivent tre tudies lors du traitement des oprations de transition des
types/domaines suite au changement de mot de passe dun utilisateur dune base de donnes
PostgreSQL ou lors de la cration dun nouveau objet (table, colonne, etc.) linstar des rgles de
transition et des rgles daccs tudies prcdemment dans les chapitres 4.1 et 5.
Codage des priorits d'ordonnancement d'un processus : le systme Linux
ordonnancelexcution de chaque processus en lui affectant une priorit dordonnancementqui
correspond un numro. Par dfaut, Lors de lancement dune commande, le processus qui lui
correspondpossdeune priorit d'ordonnancement de zro.Une valeur plus leve signifie que le
processus une priorit d'excution plus faible.Son numro de priorit baisse ou augmente
respectivement selon quil obtient ou non plus de temps d'excution pour le processeur.
Plusieurs processus demandant le processeur peuvent sexcuter en concurrence avec le
processus dune commande lente.Par exemple, la recherche dun fichier partir du rpertoire
racine de larborescence (la commande find) dun disque volumineux est une oprationtrs
longue, il est donc ncessaire que le systme intervienne pour, dune part prioriser lexcutiondes
processus rapides et dautre part attribuer une priorit rduite au processus de la commande en
question afin qu'elle ne ralentisse pas trop le systme.
Daprs ce qui est dit, un processus P du systme obtient chaque instant une priorit de la
suite finie : p1,p2,,pN (lentier N dpend du processus et de loccupation du processeur) pour
terminer son execution (on suppose que pN est la dernire priorit attribue a P).
151
Dans un environnement OrBAC, on suppose que lorganisation utilise est : Distet que
le contexteOrBACutilisest:Contexte.
Si le processus P (de contexte SELinuxp_u:p_r:p_t) est autoris excuter une
action A sur un objet O(de contexte SELinuxO_u:O_r:O_t),alors nous avons la relation de
drivations suivante :
permission (Dist, p_t,{A},V=(classe(O), O_t), Contexte,
pperm)
Emploi(Dist, p, p_t, pempl)
Utilise (Dist, O, V=(classe(O), O_t), putil)

Considre (Dist, A, {A}, pact)
dfinit (Dist, p, A, O, Contexte, pcont)
Est_permis(p, A, O, f(pperm, pempl, putil, pact, pcont))

Alors notre perspective est dessayer de trouver sil existe une relation qui lie la priorit
(possibiliste)
concrte
de
P :
f(pperm,pempl,putil,pact,pcont)et
sa
priorit
dordonnancement pN.Si non, faut-t-il considrer les (pi)comme tant des conditions particulires
dexcution et par la suite les assimiler a des contextes OrBAC?
152
Bibliographie
[1] R. William Cheswick and M. Steven Bellovin, Firewalls and Internet security: repelling the
wily hacker, Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1994.
[2] P. Samarati and S. de Vimercati, Access Control: Policies, Models, and Mechanisms,
Foundations of Security Analysis and Design on, pp. 137-196, 2000.

[3] December This Publication, Trusted Computer System Evaluation Criteria (Orange Book).
[4] B. W. Lampson, Protection, Proc Fifth Annual Princeton Conference on Information
Sciences and Systems, vol. Princeton University., pp. 437-443, March 1971.
[5] D. F. Ferraiolo,S. Ravi, G. Serban, K. D. Richard , and C. Ramaswamy , Proposed NIST
Standard for Role-Based Access Control, ACM Transactions on Information and System
Security, p. 4(3):224274, August 2001.
[6] S. I. Gavrila and J. F. Barkley, Formal Specification for Role Based Access Control
User/Role and Role/Role Relationship Management, Third ACM Workshop on Role-Based,

pp. 81-90, 22-23 Octobre 1996.
[7] S. Ravi and E. J. Coyne, . and H. L. Feinstein, and C. E. Youman, Role-Based Access
Control Models, Computer, vol. 29, n %12, pp. 38-47, February 1996.
[8] R.K. Thomas, Team-based access control (TMAC): a primitive for applying role-based
access controls in collaborative environments, the second ACM workshop on Role-based

access control, Fairfax, Virginia, United States, pp. 13-19, 6-7 November 1997.
[9] R.K. Thomas and R.S. Sandhu, Task-based Authorization Controls (TBAC): A Family of
Models for Active and Enterprise-oriented Authorization Management, 11 th IFIP Working

Conference on Database Security, Lake Tahoe, California, USA, pp. 166-181, 1998.
[10] A. Abou El Kalam, R. El Baida,P. Balbiani, S. Benferhat, F. Cuppens, Y. Deswarte, A.
Mige, C. Saurel and G.Trouessin, Organization Based Access Control, 4th IEEE
International Workshop on Policies for Distributed Systems and Networks (Policy'03), 4-6
June 2003.
[11] D. Dubois, J. Lang, and H. Prade, Possibilistic logic. Handbook of Logic in Artifical
Intelligence and Logic Programming, Oxford University Press, vol. 3, pp. 439-513, 1994.
[12] F. Cuppens, N. Cuppens-Boulahia, and C. Coma, MotOrBAC: an administration and
simulation tool of security policies, Security in Network Architectures (SAR) and Security of
Information Systems (SSI), First Joint Conference, 6-9 June 2006.
153
[13] Y. Deswarte and A. A EL Kalam, Modle de scurit pour le secteur de la sant,
Technique et Science Informatiques, vol. 23, pp. 291-321, 2004.

[14] E. Carl Landwehr, Formal Models for Computer Security, ACM Comput. Surv., vol. 13,
n %13, pp. 247-278, Sept 1981.

[15] M. A. Harrison, W. L. Ruzzo and J. D. Ullman, Protection in operating systems,
Communications of the ACM, pp. 19(8):461-471, 1976.

[16] D. E. Bell and L. J. LaPadula, Secure Computer Systems: Unified Exposition and Multics
Interpretation, Tech. Rep. ESD-TR-73-306, The MITRE Corporation, Technical Report.,

March 1976.
[17] J. P. Anderson, Computer security technology planning study, Technical Report ESD-TR-
73-51, Air Force Electronic Systems Division, Bedford, MA., 1972.

[18] S. Black and V. Varadharajan, A Multilevel Security Model for a Distributed Object-
Oriented System Networks and Communications, HP Laboratories Bristol HPL, 90-74,

1990.
[19] D. F. C. Brewer and M. J. Nash, The Chinese Wall Security Policy, IEEE Symposium on
Security and Privacy, pp. 206-214, 1989.

[20] K. J. Biba, Integrity considerations for secure computer systems, Technical Report TR-
3153, The Mitre Corporation, Bedford, MA,, June 1975.

[21] D.D. Clark and D.R. Wilson, A comparison of commercial and military computer security,
In IEEE Symposium on Security and Privacy (Oakland'87), vol. IEEE Computer Society
Press, pp. 184-195, 1987.
[22] W. E. Boebert and R. Y. Kain, A Practical Alternative to Hierarchical Integrity Policies, In
Proceedings of the Eighth National Computer Security Conference, 1985.

[23] K. W. Walker, D. F. Sterne, M. L. Badger, M. J. Petkac, D. L. Sherman, and K. A.
Oostendorp, Confining Root Programs with Domain and Type Enforcement, In

Proceedings of the 6th Usenix Security Symposium, San Jose, California, 1996.
[24] D. Ferraiolo and R. Kuhn, Role-Based Access Control, In 15th NIST-NCSC National
Computer Security Conference, pp. 554--563, 1992.

[25] Ravi Sandhu, Bhamidipati and Qamar Munawer, The ARBAC97 Model for Role-Based
Administration of Roles, ACM Transactions on Information and System Security, February

1999.
[26] B. Thuraisingham, W. Ford, M. Collins and J. O'Keefe, Design and implementation of a
154
database inference controller, Data Knowl. Eng, N 3, vol. 11, pp. 271-297, Dec. 1993.
[27] B. McCarty , SELinux: NSA's Open Source Security Enhanced Linux, O'Reilly Media, Inc.,
2004.
[28] P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner and J. F.
Farrell, The Inevitability of Failure: The Flawed Assumption of Security in Modern

Computing Environments, In Proceedings of the 21st National Information Systems
Security Conference, pp. 303-314, 1998.
[29] B. Sniffen, J. Ramsdell and D. Harris, Guided Policy Generation for Application Authors,
Proc 2006 Security Enhanced Linux Symposium, 2006.

[30] M.Abrams, K.Eggers, L.LaPadula and I.Olson, A Generalized Framework for Access
Control: An Informal Description, Proceedings of the 13th National Computer Security

Conference, October 1990.
[31] S. Smalley and T. Fraser., A Security Policy Configuration for the Security-Enhanced
Linux, Technical report, NAI Labs, Oct 2000.

[32] etbe - Prsentation about SELinux, Wednesday, 11 April 2007. [En ligne]. Available:
http://etbe.blogspot.ca/2007/04/presentations-about-se-linux.html. [Accs le 2007].

[33] Z. Chen, H. Nuermaimaiti, L. Shengping and L. Zuoquan, Representation and reasoning on
rbac: A description logic approach, pp. 381-393, 2005.

[34] A. A. Dickerson, Model and analysis of Role-Based Access Control in SELinux using
Description Logic, Informatics and Mathematical Modelling, Technical University of

Denmark, {DTU}, 2006.
[35] H. Serge , Role-based access control in SELinux, 2008. [En ligne]. Available:
http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/.
[36] W. E. Boebert and R. Y. Kain, A Practical Alternative to Hierarchical Integrity Policies, In
Proceedings of the 8th National Computer Security Conference, p. 18, 1985.

[37] R. OBrien and C. Rogers, Developing applications on lock, Proceedings of the National
Computer Security Conference, N 14, pp. 147-156, 1991.

[38] B. Lee, F. S. Daniel, L. S. David, M. W. Kenneth and A. H. Sheila , A Domain and Type
Enforcement {UNIX} Prototype, Trusted Information Systems, Inc., pp. 127--140, 1995.
[39] Hallyn, Serge E. and Kearns, Phil, Domain and type enforcement for linux, Proceedings of
the 4th annual Linux Showcase & Conference, vol. 4, pp. 15-15, 2000.
[40] P. Loscocco and S. Smalley, Integrating Flexible Support for Security Policies into the
155
Linux Operating System, February 2001.

[41] P. Loscocco and S. Smalley, Meeting critical security objectives with security-enhanced
Linux, Proceedings of the 2001 Ottawa Linux Symposium, july 2001.

[42] O. Amon, Rule Set Based Access Control as proposed in the"Generalized Framework for
Access Control" approach in Linux, Diplomarbeit, Fachbereich Informatik, Universitt

Hamburg, 10 Novembre 1997.
[43] D. E. Bell and L. J. LaPadula, Secure Computer Systems: Mathematical Foundations, vol.
I, 1973.
[44] C. Hanson, SELinux and MLS: putting the pieces together, Tech. rep. NAI-02-007,
Trusted Computer Solutions, Inc, 2006.

[45] J. Morris, A Brief Introduction to Multi-Category Security (MCS), 16 September 2005.
[En ligne]. Available: http://james-morris.livejournal.com/5583.html.

[46] S. Benferhat, K. Bouriche and M. Ouzarf, Encoding default-based SELinux-security policy
in Organization-Based Access Control Model, Internet Technology and Secured

Transactions, 2011. ICITST 2011. International Conference for, December 2011.
[47] A. Abou El Kalam, P. Balbiani, S.Benferhat, F. Cuppens, Y. Deswarte, R.Elbaida, C. Saurel
and G. Trouessin, Modles et politiques de scurit des systmes d'information et de

communication en sant et social, Informatique et Systmique, vol. 7, 2005.
[48] F. Cuppens, N. Cuppens-Boulahia, T. Sans and A. Mige, A formal approach to specify and
deploy a network security policy, 26-27 August 2004.

[49] F. Cuppens and A. Mige, Modelling Contexts in the Or-BAC Model, 19th Annual
Computer Security Applications Conference (ACSAC '03), December 2003.

[50] M. Kudo and S. Hada, XML document security based on provisional authorization,
Proceedings of the 7th ACM conference on Computer and communications security, pp. 8796, 2000.
[51] S. Jajodia, P. Samarati and V. S. Subrahmanian, A Logical Language for Expressing
Authorizations, Proceedings of the 1997 IEEE Symposium on Security and Privacy, pp. 3142, 1997.
[52] F. Cuppens, N. Cuppens-Boulahia and A. Mige, Inheritance hierachies in the Or-BAC
Model and Application in a network environnement, 2nd Foundation of Computer Security

Workshop, July 2004.
[53] G. Ahn and R. Sandhu, Role-based authorization constraints specification, ACM Trans.
156
Inf. Syst. Secur., vol. 3, n %14, pp. 207-226, Nov 2000.

[54] E.Bertino, B.Catania, E.Ferrari and P.Perlasca., A Logical Framework for Reasoning about
Access Control Models, ACM Transactions on Information and System Security, February
2003.
[55] Ahn, Gail-Joon and Sandhu, Ravi, The RSL99 language for role-based separation of duty
constraints, Proceedings of the fourth ACM workshop on Role-based access control, pp. 43-54, 1999.
[56] R. Chandramouli, R. Sandhu and R. Ramaswamy, Role-Based Access Control Features in
Commercial Database Management Systems, In Proceedings of 21st NIST-NCSC National

Information Systems Security Conference, pp. 503-511, 1998.
[57] K. Kristopher, A Database of Computer Attacks for the Evaluation of Intrusion Detection
Systems, DARPA OFF-LINE INTRUSION DETECTION EVALUATION, PROCEEDINGS

DARPA INFORMATION SURVIVABILITY CONFERENCE AND EXPOSITION (DISCEX),
pp. 12-26, 1999.
[58] F.Cuppens and A.Mige, Administration Model for Or-BAC, International Journal of
Computer Systems Science and Engineering (CSSE), 2004.

[59] R. Sandhu, V. Bhamidipati and Q. Munawer, The ARBAC97 model for role based
administration of roles., ACM Trans. Inf. Syst. Secur., 2(1):105135,, 1997.

[60] R. Sandhu and Q. Munawer, The ARBAC99 Model for Administration of Roles, In 15th
Annual omputer Security Applications onference (ASA 99), vol. IEEE Computer
Society, 1999.
[61] Red Hat, Inc., Red Hat Entreprise Linux 4 : Red Hat SELinux Guide, 2005. [En ligne].
Available: http://www.centos.org/docs/4/pdf/rhel-selg-en.pdf. [Accs le 23 8 2012].

[62] D.F. Ferraiolo, J.F. Barkley and D.R. Kuhn, A role-based access control model and
reference implementation within a corporate internet, In ACM Transactions on Information

and System Security, vol. volume 1(2), 1999.
[63] R.K. Thomas and R.S. Sandhu, Discretionary access control in object-oriented databases :
Issues ans research directions, In 16th NIST-NCSC National Computer Security Conference,
1993.
[64] Fedora
project home
http://fedoraproject.org.
page
http://fedoraproject.org,
[En
ligne].
Available:
[65] S. Benferhat, K. Bouriche and M. Ouzarf, On the modeling of RedHat default security
policies in OrBac models, the International Symposium on Security in Collaboration

157
Technologies and Systems (SECOTS 2012), 21-25 May 2012.

[66] S. Ayed, N. Cuppens-Boulahia and F. Cuppens, An integrated model for access control and
information flow requirements. ASIAN'07, Doha, Quatar., pp. 111-125, 2007.

[67] D. Sutherland, A Model of Information, In processing of the 9th National Computer
Security Conference. National Bureau of Standards and National Computer Security Center,
pp. 175-183, September 1986.
[68] D. Kuhn, Mutual exclusion as a means of implementing separation of duty requirements in
role based access control systems. In 2nd ACM Workshop on Role-Based Access Control,
pages 2330. ACM Press,, 1997.
[69] D. Dubois and H. Prade, Necessity measures and the resolution principle. IEEE Trans. on
Systems, 17:909914,, IEEE Trans. on Systems, N 17, pp. 909-914, 1994.

[70] C. Yu Che-Fn and V. D. Gligor, A specification and verification method for preventing
denial of service. IEEE Transactions on Software Engineering,, IEEE Trans. Softw. Eng., p.
16(6):581592, june 1990.
[71] G. Bossu and P. Siegel, Saturation nonmonotonic reasoning and the closed-world
assumption., Artificial Intelligence, vol. 25 (1), p. 1363, 1985.

[72] Y. Shoham, Reasoning about change, In MIT Press, Cambridge, MA, 1988.
[73] S. Benferhat, K. Bouriche and M. Ouzarf, On the possibilistic handling of priorities in
access control models, the 7th Intelligent System and Knowledge Engineering (ISKE 2012),
15-17 December 2012.
[74] {PostgreSQL Global Development Group}, Postgres 9.0 Manual, [En ligne]. Available:
http://www.postgresql.org/docs/9.0/static/index.html. [Accs le 2010].
158

Thèse BOURICHE Khalid

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thèse BOURICHE Khalid

Uploaded by

Copyright:

Available Formats

______________________________________________________________________________

Salem Benferhat, Professeur, Universit dArtois, France

Centre de Recherche en Informatique de Lens CNRS UMR 8188

Le travail de cette thse se situe lintersection du domaine de lintelligence

Puis un grand merci M'hammed BOULAGOUAZ, Professeur de l'Enseignement

Table des matires

LES MODELES DE CONTROLE D'ACCES BASES SUR

CHAPITRE 5 .............................................................................................................................. 102

INTRODUCTION ............................................................................................................... 112

CHAPITRE 7 .............................................................................................................................. 127

la disponibilit : L'objectif de la disponibilit est de garantir l'accs un service ou des

Lintgrit : Lintgrit est la prvention dune modification non autorise de

La confidentialit : La confidentialit est la proprit quune information nest ni

L'authentification : consiste assurer l'identification de l'origine de l'information et que

Lautorisation : concerne le type d'activits ou d'informations qu'une personne est

La scurit des rseaux : utilise principalement les pare-feu[1]qui permettent de surveiller et

La cryptographie, considre comme la science du secret puisquelle permet l'anonymisation

(Local Area Networden anglais) : Rseau local.

mcanismes spcialiss. do la prsence de la cryptographie cl secrte, standard de

Le contrle daccs : consiste vrifier si un sujet (utilisateur, processus, etc.) demandant

Le premier objectif de cette thse est de confirmer la puissance expressive de ce modle

L'intgrit : Concerne la protection des donnes contre toute altration durant un

Le non rpudiation : exprime comme tant lintgrit de la source et de la destination,

Physique : Cette politique prcise un ensemble de procdures et de moyens qui protgent

1.3. Les politiques et les modles de contrle daccs

Matrice de contrle daccs : La matrice de contrle daccs (introduite par Butler

Tableau 1- Matrice de contrle daccs

Tableau 2-Exemple de table de possibilits

Table de possibilits (capability table) : Cest un vecteur de la matrice de contrle daccs

Le modle HRU, formalis par Harrison, Ruzzo et Ullmann[15], propose de modliser la

Lensemble des sujets S et lensemble des objets O ;

Enter r into M(s,o) Donner un droit r un sujet s sur un objet o

Enlever un droit r un sujet s sur un objet o

Crer un sujet s : Ajoute une ligne et une colonne

Ajoute une colonne la matrice M

Tableau 4-Actions lmentaires de la matrice dfinie par le modle HRU

Tableau 5-Exemple de matrice HRU

Il ne permet pas de prendre en compte la notion du moindre privilge.

La gestion et la maintenance de la matrice daccs revt un caractre fastidieux et

Le problme de protection est dcidable dans le cas dexcution dune commande ne

Les insuffisances du modle DAC

Les politiques multi-niveaux

Un niveau de scurit est form de deux composants : un niveau classification et un

Le niveau de classification : il sagit dun ensemble totalement ordonn, Supposons que

Lensemble de catgories : Lensemble des catgories dcrit les divers domaines de

n1 domine n2 (ou n1 n2)

L : un ensemble de niveaux de scurit avec un ordre partiel .

Le modle Bell et La Padula (BLP) a t dvelopp par David Bell et Leonard

C : dsigne une classification lintrieur de laquelle lobjet se trouve, elle indique la

un sujet qui a lhabilitation Confidentiel na pas le droit daccder en lecture un objet

Figure 1-La proprit simple de BLP

Un sujet qui a lhabilitation Confidentiel a le droit daccder en criture un objet qui a la

Figure 2-La proprit toile de BLP

Figure 3-Exemple de cheval de Troie

b. Le modle de la muraille de Chine

Figure 4-Le modle de la muraille de chine

Dans la proprit simpleSdsigne seulement un utilisateur (pas un processus).

l'objet O appartient la mme classe de donnes dj

ou, si l'objet O appartient une autre classe de conflits

et, si S na jamais crit dans un autre dataset que celui o

Le terme information aseptise ou information assainie dsigne une information

Un sujet qui a lhabilitation Confidentiel a le droit daccder en lecture un objet qui

Figure 5- La proprit simple de Biba

De la mme manire que la proprit simple ci-dessus, l'attribution des niveaux de