______________________________________________________________________________ ________________________________________________________ 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 Gestion de l'incertitude et codage des politiques de scurit dans les systmes decontrle daccs THSE Doctorat de lUniversit dArtoiset de lUniversit Sidi Mohammed Ben Abdellah Spcialit Informatique par Khalid BOURICHE Composition du jury Directeurs de thse :Salem Benferhat, Professeur, Universit dArtois, France MohamedOuzaref,Professeur,FSTdeFs-UniversitUSMBA, Maroc Rapporteurs :Zied Elouedi, Professeur, ISG Tunis - Universit de Tunis, Tunisie Stphane Loiseau, Professeur, Universit dAngers, France MohammedMeknassi,Professeur,FacultdessciencesDharEl Mahraz de Fs - Universit USMBA, Maroc Examinateurs :HussainBenazza,Professeur,ENSAMdeMekns-Universit Moulay Ismail, Maroc Invit :Mohammed Boulmalf, Professeur, UIR de Rabat, Maroc 2 3 Rsum de la thse Letravaildecettethsesesituelintersectiondudomainedelintelligence artificielleetdudomainedelascuritinformatique.Cettethseadeux objectifs principaux:lepremierestdeconfirmerlapuissanceexpressivedumodle OrBAC,enparticulierparrapportauxpolitiquesdescuritpardfaututilisesdans SELinux.LedeuximeobjectifestdtendrecemodleOrBAC,enintgrantleconcept de priorit qui sera reprsent dans le cadre de la thorie des possibilits. Danslapremirepartiedelathse,nouspassonsenrevueetanalysonsles diffrentsmodlesducontrledaccsexistants,ycomprisceuxutilissdansles systmesSELinux.Enparticulier,nousprsentonslemodleOrBACquioffreune reprsentation compacte et flexible des politiques de scurit.Dansladeuximepartiedelathse,nousproposonsunemodlisationdes politiquesdescuritpardfaut,utilisesparSELinux,danslemodleOrBAC.Nous montronsquechaqueconceptutilisdanslapolitiquedescuritSELinux(type,rle, etc.)possdeunecontrepartienaturelledanslemodleOrBAC.Cettemodlisation, 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 delincertitudedanslesmodlesdecontrledaccs.Nousavonsutilislathoriedes possibilitsquioffreuncadrenaturel,qualitatifetordinalpourreprsenteretraisonner aveclesrglesincertaines.NousproposonsuneextensiondumodleOrBACeny introduisantuneentitappeleprioritauniveaudechaquerelation.Lentitpriorit 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 pourdterminerlavaleurdelaprioritdechaquerelationconcrtepartirdespriorits des relations abstraites correspondantes. 4 Remerciements Cetravailderecherchesinscritdanslecadredunethseencotutelleentreluniversit dArtois (Lens/France)et luniversit Sidi Mohammed Ben Abdellah (Fs/Maroc).Enprambulecettethse,jetienstoutdabordexprimermavivereconnaissance enversMonsieurSalemBENFERHAT,moncodirecteurdethsectfranais,quima accompagntoutaulongdelaralisationdecetravail.Ilaconsacrdesonprcieuxtempsen maccueillantenFranceetensedplaantauMarocetenmeprodiguantdutilesconseilsqui montnormmentaidbienraliseretstructurermontravail.Aucoursdemesmoments difficiles,ilafaitpreuvedunegrandedisponibilitainsiquunehautequalitdeses interventionsetsecours,etsansquicettethseneseraitpascequelleest.Merciinfiniment MonsieurSalemBENFERHAT,votrerigueurautravailseraitunexemplepourmoi.Toutema reconnaissanceetmagratitudepourlaboutissementdeplusdetroisansdetravailsousvotre direction clairvoyante. Je te souhaite une trs bonne sant. JetiensremerciersincrementMonsieurMohamedOUZARF,qui,entantque codirecteurdethsectmarocain,s'esttoujoursmontrl'couteettrscollaboratiftoutau long de la ralisation de cette thse, ainsi pour l'aide et le temps qu'il a bien voulu me consacrer notammentsurleplanadministratif.MonsieurMohamedOUZARFmaencadraucoursdes 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.JexprimetoutemagratitudeMonsieur,Professeur,pourmavoirfaitleprivilgede prsider le jury lors de ma soutenance de thse. Que Monsieur Zied Elouedi Professeur lISG Universit de Tunis, et Monsieur Stphane LoiseauProfesseurl'UniversitdAngers,trouventicilexpressiondemessincres remerciements davoir accept dvaluer ce travail. JadressemesvifsremerciementsMonsieurMohammedMEKNASSIprofesseurla facultdessciencesDharElMahrazdeFsetMonsieurHussainBENAZZAprofesseur lENSAMdeMeknsetlundemesanciensprofesseurslaFSTdeFs.Jesuistrs reconnaissant quils aient accept (respectivement) de rapporter et dexaminer ma thse. MesremerciementsvontencoreMohammedBOULMALEFprofesseurlUniversit InternationaledeRabatquiarapidementacceptdtreparmilejury,saprsenceentrenous honorera sans doute la sance. Un grand merci Monsieur Mohammed BOULMALEF. 5 PuisungrandmerciM'hammedBOULAGOUAZ,Professeurdel'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 quelecontratdecotutelleaittabli.MerciMonsieurM'hammedBOULAGOUAZ,cestun 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. Jesouhaiteadressermesremerciementslesplussincrestousceuxquim'ontapport leur aide et qui ont contribu de prs ou de loin l'laboration de ce travail. Ilyadespersonnesdetrsgrandeimportancedansmavie,ilsagitdemafemme 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.Mesremerciementsvontaussitousmesamis,quilssoientauMaroc,enFranceou Qubec,etjesaisquilssontnombreux.Vousmavezsolidementtoussoutenuparvotre encouragement,Jeciteaupassage :SaidiRachid,BENNANIMohamedAli,SaidZahnoune, StitouMohamed,RachidChaib,ZeglamaSaid,ELGaouziKhalid,YoussefSelmouniZerhouni et Chafik Hadigui. Tous ceux qui restent dont les noms ne figurent pas sur cette liste et qui mont soutenu dune manire ou duneautre sachent que leurapport moral napas t sous-estim. Je vousadressetousmessentimentsdereconnaissancerenouvele.Jediraisdonctoutlemonde que mes amis constituent ma grande force de russite. Enfin et surtout, un grand merci ALLAH qui m'a toujours aid. 6 Table des matiresINTRODUCTION .......................................................................................................................... 9 PLAN DU MEMOIRE ................................................................................................................. 13 CHAPITRE 1 ................................................................................................................................ 15 MODELES ET POLITIQUES DE CONTROLE D'ACCES ................................................... 15 1.1.INTRODUCTION ................................................................................................................. 15 1.2.POLITIQUE DE SECURITE ................................................................................................... 16 1.3.LES POLITIQUES ET LES MODELES DE CONTROLE DACCES ................................................ 17 1.3.1.CONTROLE DACCES DISCRETIONNAIRE (DAC) ............................................................ 17 1.3.2.CONTROLE DACCES MANDATAIRE (MAC) ................................................................... 21 1.3.3.LE CONTROLE D'ACCES BASE SUR LES ROLES (RBAC) .................................................. 31 1.4.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 MODELETE ............................................................................................... 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 7 LES MODELES DE CONTROLE D'ACCES BASES SUR L'ORGANISATION (ORBAC) ........................................................................................................................................ 66 3.1.INTRODUCTION ................................................................................................................. 66 3.2.LEMENTS D'ORBAC ........................................................................................................ 66 3.2.1.NIVEAU ABSTRAIT ......................................................................................................... 67 3.2.2.ROLE ............................................................................................................................. 68 3.2.3.VUE .............................................................................................................................. 68 3.2.4.ACTIVITE ...................................................................................................................... 68 3.2.5.CONTEXTE .................................................................................................................... 69 3.2.6.NIVEAU CONCRET ......................................................................................................... 71 3.3.RELATIONS ENTRE LES ENTITES ABSTRAITES ET LES ENTITES CONCRETES ........................ 73 3.3.1.RELATION EMPOWER .................................................................................................... 73 3.3.2.RELATION USE .............................................................................................................. 74 3.3.3.RELATION CONSIDER .................................................................................................... 74 3.4.LANGAGE DE FORMALISME DU MODELE ORBAC .............................................................. 75 3.5.HIERARCHIES DANS ORBAC ............................................................................................. 75 3.5.1.HIERARCHIE DES ROLES ................................................................................................ 75 3.5.2.HIERARCHIE DES ACTIVITES .......................................................................................... 76 3.5.3.HIERARCHIE DES VUES .................................................................................................. 76 3.5.4.HIERARCHIE DES ORGANISATIONS ................................................................................. 77 3.6.CONTRAINTES ................................................................................................................... 78 3.7.MOTORBAC ...................................................................................................................... 79 3.7.1.HISTORIQUE ET ARCHITECTURE DE MOTORBAC .......................................................... 79 3.7.2.MODULES DE MOTORBAC ........................................................................................... 80 3.8.CONCLUSION .................................................................................................................... 85 CHAPITRE 4 ................................................................................................................................ 86 CODAGE EN MODELE ORBAC DE LA POLITIQUE DE SECURITE PAR DEFAUT DE SELINUX. ...................................................................................................................................... 86 4.1.INTRODUCTION ................................................................................................................. 86 4.2.FICHIERS ET REPERTOIRES LIES A LA POLITIQUE DE SECURITE DEFAUT ............................. 87 4.2.1.LE FICHIER DE CONFIGURATION DE LA POLITIQUE DE SECURITE PAR DEFAUT ................ 87 4.2.2.CONTEXTE DE CONNEXION PAR DEFAUT ASSOCIES AUX UTILISATEURS ......................... 88 4.2.3.CONTEXTE PAR DEFAUT ASSOCIE AUX FICHIERS ET REPERTOIRES ................................. 88 4.3.PARAMETRES DE LA POLITIQUE DE SECURITE SELINUX ..................................................... 90 4.4.ENCODAGE EN MODELE ORBAC DE LA POLITIQUE DE SECURITE DEFAUTSELINUX .......... 91 4.4.1.LES ENTITES DE LA RELATION EMPLOY ......................................................................... 91 4.4.2.LA RELATION CONSIDER ............................................................................................... 93 4.4.3.LA RELATION USES ....................................................................................................... 93 4.4.4.LA RELATION ABSTRAITE : PERMISSION ........................................................................ 94 4.4.5.LA RELATION CONCRETE IS_PERMITTED ....................................................................... 96 4.5.EXEMPLE DILLUSTRATION ............................................................................................... 97 4.6.CONCLUSION .................................................................................................................. 101 8 CHAPITRE 5 .............................................................................................................................. 102 CODAGE DES REGLES DE TRANSITION SELINUXEN 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.INTRODUCTION ............................................................................................................... 112 6.2.LA LOGIQUE POSSIBILISTE .............................................................................................. 113 6.2.1.DISTRIBUTIONS DE POSSIBILITES ................................................................................. 113 6.2.2.BASES POSSIBILISTES .................................................................................................. 114 6.3.AJOUT DES PRIORITES AU MODELE ORBAC .................................................................... 118 6.3.1.ORGANISATION ........................................................................................................... 118 6.3.2.SUJETS ET ROLES ......................................................................................................... 118 6.3.3.OBJETS ET VUES .......................................................................................................... 119 6.3.4.LES ACTIONS ET ACTIVITES ......................................................................................... 119 6.3.5.CONTEXTES................................................................................................................. 120 6.4.PRIORISER LES AUTORISATIONS ABSTRAITES ET CONCRETES. ......................................... 120 6.4.1.MODE DE COMBINAISON PESSIMISTE: .......................................................................... 122 6.4.2.MODE DE COMBINAISON OPTIMISTE: ........................................................................... 122 6.4.3.MODE DE COMBINAISON ACTUALISE .......................................................................... 122 6.5.EXEMPLE DILLUSTRATION ............................................................................................. 123 6.6.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 CONCLUSIONET PERSPECTIVES .................................................................................... 147 BIBLIOGRAPHIE ..................................................................................................................... 153 9 INTRODUCTION Lesystmedinformation(SI)etlesdonnessensiblesduneorganisation,reprsententson capitalessentiel,quilconvientdeprotgercontrelesaccsnonautoriss.Lesspcialistesde scurit des systmes dinformation (SSI) sont confronts des enjeux descurit. Ils doivent, lafois,avoiruneapprocheglobaleduSIetuneconnaissanceapprofondiedusystme dexploitation ainsi que les applications installes.Eneffet,plusieurspossibilitsdetechniquesontoffertesaujourdhuilaidedela gnralisationdelaconnexionInternet,lutilisationintensivedessystmesetapplicatifs communicantsetlacomplexitdesarchitectures.Cespossibilitsintroduisentaussidesrisques 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 lascuritd'unsystmed'information(SSI),enplusontrouvelecasdespersonnes malintentionnes quiarriventsinfiltrerenexploitantunevulnrabilitdusystmepour semparer dinformations sensibles aux quelles elle ne sont pas censes avoir accs. Un autre cas frquentconcernelesprogrammesmalveillants(lesvirus,chevauxdeTroie,etc.)quisont dveloppspournuireunsystme,voiremmemodifieroucollectersesdonnespourles rutiliser des fins malveillantes. Dunemaniregnrale,LaSSIconsisteassurerluniqueutilisationdesressources systmesd'uneorganisationdanslecadreprvu.Elleestvalueparplusieurspropritset 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 :Lintgritestlaprventiondunemodificationnonautorisede linformation norme ISO 7498-2 (ISO90).-Laconfidentialit :Laconfidentialitestlapropritquuneinformationnestni disponible ni divulgue aux personnes, composantes ou processus non autoriss norme ISO 7498-2 (ISO90). 10 -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 etque seules les personnes autorises aient accs aux ressources;D'autrescaractristiquessontgalementutilisespeuventsajoutercellesprcites,tels que : -Lautorisation:concerneletyped'activitsoud'informationsqu'unepersonneest autorise effectuer ou y accder; -Latraabilit :garantitquelesaccsettentativesd'accsauxlmentsconsidrssont auditset que ces traces sont conserves dans des journaux exploitables.Cescritressontgnralementassurspardestechniquesetmcanismesquiportent 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 fonctionsdefiltragequinelaissentpasserquelespaquetsenprovenancedesadresses (IP+numrodeport)autorises,etseproccupentleplussouventdelarsolutiondes problmesdeconfidentialitetd'intgritdesdonnesquitransitent.Danscecontexte,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. -Ladtectiondintrusions :utilisedesoutilsquicompltentlesfonctionsdupare-feuen reprant,dunepartlesintrussurlesportslaisssouvertsetdautrepartlesrequtes malintentionnes.ilexistedeuxtypesdesystmededtectionsdintrusions(ouIDSpour Intrusion Dtection System) : les IDS bass rseau et les IDS bass hte. Ces deux catgories d'IDSemploientgnralementdeuxprincipesdedtectionsavoirl'approche comportementale(oudtectiond'anomalies)etl'approchebasesurlaconnaissance(oula 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 donnlieudemultiplesusagesetapplications.Lesconceptsdelacryptographieontt laborspourpermettrelamiseaupoint,puislamiseenuvreduncertainnombrede

1(Local Area Networden anglais) : Rseau local. 2(Wide Area Networden anglais) : Rseau tendu. 11 mcanismesspcialiss.dolaprsencedelacryptographieclsecrte,standardde chiffrement AES, systmes cryptographiques cl publique (RSA, El Gamal, ECC, etc.), des codes dauthentification, des systmes de partage de secret, des procds didentification, des signaturesnumriquesetdecryptographiedynamiqueetautantdedomaines,despcialistes et dusages. -Lecontrledaccs :consistevrifiersiunsujet(utilisateur,processus,etc.)demandant d'accder une ressource (fichier, mmoire, etc.) possde suffisamment le droitpour le faire. Lecontrle daccs est bas sur une politique de contrle daccs quiest spcialise pour la gestiondespermissions[2].Lapolitiquedecontrledaccseststructureselonunmodle quiestresponsabledelaprisededcision(accordourefus)dunedemandedaccs.Les modlestraditionnelsdecontrledaccssont :lecontrledaccsparmandat(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 decontrledaccsbasssurlesrles(Rle-BasedAccessControl-RBAC)[5][6][7],une politiqueRBACest,dunepartunensembledaffectationdesutilisateursdesrleset dautrepartunensembledattributionsdespermissionscesdesrlesetparlasuite,une demande daccs dun sujet uneressource estaccorde sil joue un rle auquelest associ ce privilge. Plusieurs modles se sont inspirs de RBAC pour, soit organiser des politiques aumoyendeconceptssupplmentaires(parexemple,quipe,tche,organisation)pour amliorerleurpouvoirexpressifetleurflexibilit:lecontrledaccsbassurlquipe (Team-Based Access Control -TMAC)[8], contrle d'accs bas sur des tches (Task-based AuthorizationControls-TBAC)[9]etlecontrledaccsbassurlorganisation (Organisation-Based Access Control - OrBAC)[10]. Soit de ltendre en ajoutant par exemple, des contraintes temporelles, spatiales ou gographiques). Laprsentethsesintresseessentiellementauxtechniquesdecontrledaccs,etplus prcismentaumodleOrBAC[10],quipermetdabstrairelesentits :sujet,actionetobjet respectivementenrle,activitetvueetcedanslecadredunemmeorganisation.Ceconcept permetderduirelenombrederglesdescuritetdesimplifiergalementlatchede ladministrateur. 12 Lepremierobjectifdecettethseestdeconfirmerlapuissanceexpressivedecemodle 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 lorigineOrBAC a t propos pour rpondre aux exigences des politiques de scurit dans les domaines de soins de sant. Nous avonschoisiSELinux(SecurityEnhancedLinux)puisquilreprsenteunedessolutionsde scuritlesplusutilis,enplusilutiliseplusquunmodledecontrled'accs(RBAC,MLS, DTE, etc.) dans les systmes d'exploitation Linux.LedeuximeobjectifestdeproposeruneextensiondumodleOrBACenintgrantle concept de priorit qui peut tre associ avec lesrgles de la politique descurit. Ces priorits sontreprsentesdanslecadredelathoriedespossibilits[7][10][11].Nousavonspropos diffrentesrglesd'agrgationpourdriverlesprioritsassociesauxpermissionsconcrtes partir des rgles prioritaires des permissions abstraites. 13 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 contrled'accsdanslessystmesd'information.Ilfaitlepointsurlesdiffrentespolitiquesde contrled'accsainsiquesurleursmodlespropossdanslalittrature.Nousdcrivonsles limites de chaque modle de contrle d'accs.Lechapitre2intitulLasolutiondescuritSELinux,estuneprsentationdeSELinux (Security-Enhanced Linux) comme solution de scurit des systmes Linux. Il constitue travers cesparagraphesunedmystificationdeplusieursconceptsSELinuxetmetenrelieflesdivers 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 dansSELinux, les plus importants des travaux de recherches qui ont t proposs. Le chapitre 3 prsente lemodle de contrle d'accs OrBAC, ce modle est centr sur la notiond'organisation,cequipermetdereprsenterunepolitiquedescuritquidiffred'une organisation une autre. Nous avons utilis un langage issu de la logique du premier ordre pour reprsenterlesdiffrentesentitsetrelationsdumodleOrBAC.Ainsiquelecodagedes hirarchiesetdescontraintes.Lesexemplesdillustrationsontgnralementfournisenrelation 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 niveauorganisationnel. Le chapitre 4 intitul Codage en modle OrBAC de la politique de scurit par dfaut de SELinuxcommencepardonnerquelquesbrvesdescriptionsdeconceptsprincipauxutilisspar unepolitiquedescuritSELinuxpardfauttelsque:lecontexte,lerle,detype,etc.Nous montronsensuitequechaqueconceptdanslapolitiquedescuritSELinuxpossdeson correspondant naturel dans le modle OrBAC ce qui confirme la puissance expressive du systme OrBAC. Nous avons utilis la distributionFedora 14et Red Hat 4, pour illustrer notre encodage. LeChapitre5estconsacrlaprsentationdestransitionsdetypesenSELinuxet lattribution dun type (resp. domaine) par dfaut un objet (resp. processus). Il traite en outre le casdunetransitiondedomainepartirdunergledescurit,cecasestillustrtravers 14 lexempledechangementdemotdepassedanslesystmeLinux.Lebutdecechapitreestde 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 cadredelathoriedespossibilits,nousabordonslafaondontlaquellelesprioritssont ajoutes aux diffrentesentits abstraites du modle OrBAC. Nous avonsgalement proposdes rglesd'agrgationpourdriverlesprioritsassociesauxpermissionsconcrtespartirdes rgles prioritaires des permissions abstraites.Lechapitre7proposeuneimplmentationdenoscontributionssousformedun programmedveloppenDelphi7grantunebasededonnescreenParadox,plusieurs images cran sont captures lors de limplmentation de lexemple dillustration. Enfin,laconclusionrsumelesdiffrentschapitresainsiquelescontributionsetdonne quelques perspectives pour les futurs travaux lis au sujet de cette thse. 15 Chapitre 1 Modles et politiques de contrle d'accs 1.1. Introduction Lascuritdessystmesinformatiquesestunvritabletravail,quiconsistesassurer quelesressourcesmatriellesoulogiciellesd'uneorganisationnepeuventtre,enaucuncas, employesendehorsduncadreprvuetdfinilavance.Ellevisegnralementtrois principaux objectifs :L'intgrit:Concernelaprotectiondesdonnescontretoutealtrationdurantun traitement ou une communication (de manire accidentelle ou intentionnelle). Laconfidentialit :consisteassurerlaprotectiondel'informationchangecontreles divulgations non autorises. Ladisponibilit:permetdemaintenirlebonfonctionnementdusystmeenfournissant 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 commelintgrit de la source, elle consiste sassurerqueseuleslespersonnesautorisesaientaccsauxressources.Plusieurs systmes de contrles daccs utilisent des techniques (Exemple : lidentifiant et le mot de passedunutilisateur,cartebiomtrique)quipermettentd'accderdesressources uniquement aux personnes autorises. Lenonrpudiation :exprimecommetantlintgritdelasourceetdeladestination, elleassurequ'unepersonnenepuissenieravoireffectuunetransactionetquechaque transaction est imputable un acteur.Toutdponddonc,dusystmedinformationscuriser,pourchoisirtelleoutelle techniquedescurit.Lacryptographieestgnralementutilisepourassurerlintgrit,la confidentialitetlanon-rpudiation.Aveclecontrledaccs,onsintressepluttgarantir deuxpropritsfondamentales:laconfidentialitetlintgritdesinformationscontenuesdans unsystmedinformation.Cecincessitequechaqueaccsuneressourcesoitcontrlet autoris. Le systme dont on veut protger les ressourcesdoit disposer de plusieurs mcanismes de contrle daccs et ce afin de permettre dy implanter des politiques de scurit (concernant la confidentialitetlintgrit).Lecontrledaccsfonctionnesurlesmodlesutilisantlesentits de modlisation suivantes : Sujet : est une entitactive, elle inclut toujours les utilisateurs du systme et souvent les processusencoursd'excutionpourlecomptedesutilisateurs.Danscecontexte,un utilisateurestsoitunepersonnephysiqueconnueparlesystmeinformatiqueet enregistrecommeutilisateur,soitunserveur,soitunesortedepersonnemorale reprsentantdesfonctionsdeserviceautomatiquetellesqueleserveurdimpression,le serveur de base de donnes, le serveur de messagerie, etc.Objet :estuneentitpassive,unconteneurdinformation,surlequelunsujetpeut effectueruneaction(lesfichiers,socketsdecommunication,priphriquesmatriels, etc.); 16 Action:ellereprsentelesmoyenspermettantauxsujetsdemanipulerlesobjetsdu systme. Le prsent Chapitre se prsente sous forme de plusieurs sections : dans la premire section nousprsentonsdunemaniregnralelascuritdessystmesd'information.Lasectionqui 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 :Unepolitiquedescuritestlensembledeslois,rglesetpratiquesqui rgissentlafaondontlinformationsensibleetlesautresressourcessontgres,protgeset distribues lintrieur dun systme spcifique3. Unepolitiquedescuritseconstruitendfinissantlespropritssatisfaireparle systme,etentablissantunschmadautorisationquidoitavoir,enprincipe,unepolitique cohrente. La politique de scurit prend en compte les aspects organisationnels et techniques qui dfinissentcommentlesutilisateurspeuventmanipulerl'information.Lespropritsdescurit peuvent tre dfinies en fonction de la confidentialit, lintgrit et la disponibilit (Cf. 1.1). Ledveloppementdunepolitiquedescuritpeuttreralisdanstroisdirections 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 lesaccsphysiquesauxmatrielsinformatiquesetdecommunication(gardiens,codes, badges, ...). Administrative:cettepolitiquedfinitunensembledeprocduresetmoyensquitraite tout ce qui ressort de la scurit dun point de vue organisationnel au sein de lentreprise. Lastructuredelorganigrammeainsiquelarpartitiondestches(sparationdes environnements de dveloppement, dindustrialisation et de production des applicatifs) en fontpartie.Lespropritsdescuritrecherchesvisent,parexemple,limiterles 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.Servicedauthentification:Sassurerquelidentitdusujetestbiencellequil prtend tre. c.Servicedautorisation:Dterminersilesujetauthentifipeuteffectuerlaction dsire sur lobjet spcifi. Lecontrledaccsspcifiequipeutaccderquoietdansquellecirconstance, lautorisationconsisteadministreretexaminerlesdroitsdaccs,enfonctiondes 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.

3Dfinition dITSE : Information Technology Security Evaluation riteria, standard pour la scurit des systmes d'information. 17 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 tredfinicommeunformalisme,souventmathmatique,quiconsistevrifiersiunsujet (utilisateur,processus)demandantd'accderunobjet(ressource,autresujet...)possdeles droits ncessaires pour le faire. Le contrle d'accs permet donc de limiter l'accs des sujets aux objets,ilapourbutprincipaldeprotgerlesdonnesetlesressourcesdusystmecontrela rvlationetlamodificationnonautorisestoutenassurantleurdisponibilitauxutilisateurs 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. Lesschmasdautorisationdespolitiquesdescuritsontclasssentroisgrandes 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,RuzzoandUllmann)[15],BLP(BelletLapadula)[16]etOrBAC(Organization-based 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).Cecisupposelutilisationdunemthodeformelledeconstructiondesrglesduschma dautorisation, partir dune spcification formelle des objectifs de scurit. 1.3.1.Contrle daccs discrtionnaire (DAC) Lecontrledaccsdiscrtionnaire(DiscretionaryAccessControl-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. Cetypedemcanismeestutilisdanslessystmesdexploitationtraditionnels:Unix,Linux, WindowsetMacintosh,ilestimplmentgnralementavecdeslistesdecontrledaccs (Access Control Lists - ACL) (Cf.Tableau 1). LesmodlesDACquenousprsentonsdanscettesectionsont ceuxquisebasentsurla matrice de contrle daccs: le modle de Lampson et le modle de Harrison Ruzzo Ullman. 1.3.1.1.Modle de Lampson Matricedecontrledaccs:Lamatricedecontrledaccs(introduiteparButler Lampsonen1971[4])estunematricedeuxdimensionsreprsentant,pourchaquesujet,les actionsquilpeuteffectuersurchaqueobjet.Ilsagitdoncdunereprsentationnaturelledes 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 18 unensemblededroitsd'accsquiconstituentl'ensembledesoprationsquelesujet(i)peut raliser sur l'objet (j). Laconstructiondunetellematricencessitel'identificationetlecontrledesobjets 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/Objeto1ojoN s1 Lecture criture Excution Pas daccs s2LectureLecture siLecture sM Pas daccs 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 chaquefoisqu'unsujetestintroduit(ouunobjetestcr)danslesystme,touslesdroits d'accsaccordsdevronttreenregistrs.Parconsquent,lamisejourd'unepolitiquede scurit exprime par ce modle est fastidieuse, do lutilisation de deux vecteurs: s2o1 : Lectureo2 : Pas daccsoN: Lecture Tableau 2-Exemple de table de possibilits 19 o2 s1 : Lecture s2 : Pas daccs sM : criture Tableau 3-Exemple d'ACL Tabledepossibilits(capabilitytable):Cestunvecteurdelamatricedecontrledaccs 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, ilreprsentel'ensembledessujetsayantdesdroitsd'accssurl'objetconsidravecpour chaque sujet l'ensembledes actions quece sujetpeut raliser sur l'objet,cest une technique utilis pour les routeurs. (Cf. Tableau 3). AnoterquelemodledeLampsonassociauxDAC,nepermetpasdexprimer 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 remplirtoutelescellulesdesobjetssetrouvantlammelignequelesujet.Lemodlede Lampsonatprogressivementamliorpourdonnernaissancedautresmodlestelsquele 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 ; UnematricedecontrledaccsPso avecsS,oOetPso A(ensemblededroits daccs). LensembledesdroitsgnriquesR=(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 subjectetcreate objectpourlacrationdenouveauxsujetset objets et enfin destroy subject et destroy object pour la destruction de sujets et objets (Cf. Tableau 4).Encequiconcernelaprotection,lescommandesdelensembleConttouslamme forme,ellessontconstruitespartirdesoprationsprimitivesci-dessusetprennentcomme argumentdessujetsetdesobjets.Ellesprennentenparamtresunelistedesujetsetobjets,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).

4Kerberos est un protocole d'authentification rseau qui repose sur un mcanisme de cls secrtes (chiffrement symtrique) et l'utilisation de tickets. 20 Primitives utilises par les rgles Significations Gestion de la matrice Enter r into M(s,o)Donner un droit r un sujet s sur un objet o Delete r from M(s,o) Enlever un droit r un sujet s sur un objet o Gestion des sujets Create subject s Crer un sujet s : Ajoute une ligne et une colonne la matrice M car le sujet s est aussi un objet Destory subject sDtruire un sujet s Gestion des objets Create object o Ajoute une colonne la matrice M Destory object oDtruire un objet o (possible si ce nest pas un sujet) 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 actionssontreprsentesparlensemble{r,w,x},lesPermissionsreprsentessousforme dACL: et. 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 : s1s2o1o2 s1rwxrw- s2r-xr-- 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) SiwriteP(s1,o1):vrificationdelaprsencedudroitw danslacelluleP(s1,o1)dansnotreexemple(1erexemple)ce droit existe bien, puisque P(s1,o1)=rwx. AlorsMettrewritedansP(s2,o1) (c'est--direqueP(s2,o1) passera de la valeur r-x la valeur rwx). OutreslesinsuffisancesdumodledeLampson,lemodleHRUprsenteleslimites suivantes : Il ne permet pas de reprsenter les rgles de dpendance du contexte. 21 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. Larductiondelatailledelamatriceenconstituantdesgroupesd'utilisateurs nesttoujourspasunebonnesolution,puisquunsujetpeutappartenirplusieurs groupes. Complexit du problme de protection du modle HRU : Le problme de protection est indcidable (dans le cas gnral) : Si nous appliquons une squencedecommandelamatricedaccs,nousnesommespassrsquundroit particulier soit mis dans une cellule oil ne se trouvait pas auparavant. Leproblmedeprotectionestdcidabledanslecasdexcutiondunecommandene 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 chevauxdeTroie5[16].Eneffetlapolitiquediscrtionnairesebasesurlaconfiancetotale attribueauxsujetsquisexcutentauxcomptesdesutilisateursetauxutilisateurseux-mmes. Desmanipulationsmaladroitesoumalveillantesprovoquentdesabusdepouvoirrendantla politiquevulnrable.Eneffet,ilsuffitquunseulutilisateurcommetteuneerreurpourquela politiqueglobaledescuritsoitcompromise.Deplus,ilsepeutquunutilisateurnonautoris, reoiveunecopiedunobjettransmisparunutilisateurautorislelire,cettesituationestune 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) Lecontrled'accsobligatoire(MAC)[14]estgnralementdfiniparoppositionau contrled'accsdiscrtionnaire(DAC),sonobjectifestdimposerunepolitiquenonmodifiable parlesutilisateursfinauxdanslebutdegarantirlasretdusystmeafindepallierauxdivers problmes dus aux fuites d'informations et la vulnrabilit aux chevaux de Troie [16]. Anderson[17]proposedutiliserunMoniteurdeRfrence(ReferenceMonitor)pour contrlerlesaccsentresujetsetobjets.Lamatricecorrespondantetantfixe,ildevientalors possibledegarantirquedesdroitsdaccsconsidrscritiquesoudangereuxnepourronttre donns ou obtenus par erreur. Ce concept de Moniteurde Rfrence est au cur de la dfinition ducontrledaccsmandatairequiestplusrigideetplussrquelecontrledaccs discrtionnaire. Lesfuitesdinformationsetletransfertillgalsontcontrsparlesrglesdespolitiques MAC,quicontrlentlesflotsdinformations.Cespolitiquessontgnralementdespolitiques multi-niveaux bases sur la notion de treillis6 et qui consiste en une classification des sujets et des objets impose par une autorit centrale.

5Un 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". 6Un treillis est un ensemble E muni dune loi (partiellement ordonn) tel que : x, y E, inf{x,y} et sup{x,y} existent. 22 1.3.2.1.Les politiques multi-niveaux Dans un environnement multiutilisateur, les donnes et les informations qui circulent dans lesystmedinformationpeuventtrerangesdansdiffrentsniveauxdesensibilit.Eneffet, 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 placedessolutions(decontrledaccs)desortequeseulscertainssujetspeuventtrefiltrs pour accder ces informations.Exemple:dansuneentreprise,lessalairesetlesprimesdesemployspeuventtre 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 delemploy,sonadresseetc.nelesontpas.ettequalificationvarieduneentrepriseune 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. Lesmodlesdescuritmulti-niveaux[18]permettentd'viterladivulgationnon 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. Lespolitiquesmulti-niveauxclassentlessujetsetlesobjetsavecdiffrentsdegrsde sensibilit ou niveau de scurit lesquels constituent un ensemble partiellement ordonn par une relation de dominance, note: Unniveaudescuritestformdedeuxcomposants:unniveauclassificationetun 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. Lensembledecatgories:Lensembledescatgoriesdcritlesdiversdomainesde linformation.Parexempledanslessystmesmilitairescetensemblepeutcontenirles catgories : nuclaire et arme, dans les systmes commerciaux les catgories sont pluttfinancier,administratif,etc.Larelationentrelesensemblesdecatgoriesestl'inclusion ensembliste : tantdonnedeuxniveauxdescurit(n1)et(n2)telsque(n1)(respectivement(n2))est dfiniparsaclassification(c1)(respectivement(c2))etsonensembledecatgories(C1) (respectivement (C2)) La relation de dominance estdfinie comme suit :23 n1 domine n2(ou n1 n2)si et seulement si : le niveau de classificationc1 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). Lensembledesniveauxdescuritmunidelarelationdordrepartiel()possdeune borneinfrieureetunebornesuprieure.Lastructuredecetensembleformeuntreillis. Lutilisation ainsi que la smantique de la classification dpendent de lobjectif vis, c'est--dire : veut-on prserver la confidentialit ou lintgrit des donnes?Nousallonsprsenterdespolitiquesmulti-niveauxbasessurlaconfidentialit(Bell-LaPadula) 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,lamatricedecontrledaccsquiassocieunensemblededroitsdaccschaque couple (s, o) S O. a.Le modle Bell et LaPadula (BLP)LemodleBelletLaPadula(BLP)atdveloppparDavidBelletLeonard LaPadula[16] pour le Dpartement de la Dfense Amricain (Departement of Defense - DoD), il utilisedesconceptsmathmatiquesfondssurlanotiondetreillisafindedfinirl'tatdela scurit d'un systme. Commepourlespolitiquesmulti-niveaux,lemodleBelletLaPadula(BLP)estun 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 unutilisateurnonhabilitlaconnatre.Ceniveaureprsentedoncuneclassificationdes sujets dans un ensemble totalement ordonn, exemple :{non-classifi, confidentiel, secret, Top-secret} C:dsigneuneclassificationlintrieurdelaquellelobjetsetrouve,elleindiquela sensibilitdel'informationcontenuedansl'objet,c'est--direlesrisquespotentielsqui pourraient rsulter de la rvlation non autorise de cette information.Pourvitertouteambigit,nousnetenonspasenconsidrationl'ensembledes 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. Pourmaintenirlaconfidentialit,desrestrictionssontimposersurlesoprationsde lectureet dcriture, quipermettent de transfrerdes informations. Ces restrictions se traduisent par les deux principes suivants : lapropritsimpleNoReadUp:Cestuneinterdictionexplicitedetoutelectureenhaut. Cettepropritassurequunsujetsnepeutlireunobjetoquesileniveaudescuritdes domineceluideo(unsujetnedoitpassemparerdesinformationsquineluisontpas autorises). La figure 1. ci-dessous indique les niveaux de scurit attribus aux objets et aux sujets, par consquent, les rgles suivantes sont suscites : 24 unsujetquialhabilitationConfidentielnapasledroitdaccderenlectureunobjet quialaclassificationTop-Secret,carleniveaudescuritconfidentielestinfrieurau niveau de scurit Top-Secret. un sujet qui a lhabilitation Top-Secreta le droit daccder en lecture un objet qui a la classificationConfidentielparcequeleniveaudescuritConfidentielestinfrieurau niveau de scurit Top-Secret. unsujetquialhabilitationSecretaledroitdaccderenlectureunobjetquiala classification Secret car le mme niveau de scurit est attribu au sujet et lobjet. Figure 1-La proprit simple de BLP laproprittoileNoWriteDown:cestuneinterdictiondetoutecritureenbas,cette propritassurequilnyauraitpasdefuitedinformationdunobjetversunautreobjetde classificationinfrieure.pourcelaunsujetsnepeutmodifierunobjetoquesileniveau courant de scurit de s est domin par celui de o (un sujet ne doit pas rvler des secrets). DelammemanirequelapropritsimpledeBPL,laFigure2ci-dessousindiqueles 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 scuritConfidentielest infrieur au niveau de scurit Top-Secret.UnsujetquialhabilitationTop-Secretnapasledroitdaccderencritureunobjet quialaclassificationConfidentielcarleniveaudescuritConfidentielestinfrieurau niveau de scurit Top-Secret.UnsujetquialhabilitationSecretaledroitdaccderencritureunobjetquiala classification Secret car le mme niveau de scurit est attribu au sujet et lobjet. 25 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 lecopiersurunautrefichierdeclassificationinfrieureetquipourraittreluparunutilisateur 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 sujetayantunehabilitationhcesobjetssevoientattribueruneclassificationgale lhabilitationh,dounecroissanceautomatiquedesclassifications.Lesobjetsenquestion 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. 26 b.Le modle de la muraille de Chine LemodledelamurailledeChine(theChineseWall-CW)atproposdans[19]par BrewerandNash.IlsuitlesmmesprincipesquelemodleBelletLaPadula(destinla propritdeconfidentialit)saufquilestdfinipourledomainecommercial.Sonbutestde rsoudreleproblmedeconflitsdintrtsrelisauxactivitsdeconsultationlintrieurdes institutions(banques,tablissementsfinancires)etparconsquentdeprvenirlesflux d'informationsquimnentdesconflits.Parexemple,ilyauraitunconflitdintrtsiun 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.Lebasniveau :Ceniveaucomprendleslmentsindividuelsdinformation,chacun concernantunesimplesocit.Lesinformationsauxquellesondemandeaccssont stockes dans des fichiers, appels aussi objets. 2.Leniveauintermdiaire :touslesobjetsconcernantlesdonnesd'unemmecompagnie sontgroupsdansunensemblededonnesdecompagnie(enanglaiscompany dataset). 3.Lehautniveau :lesensemblesdedonnesdescompagniesenconflit(exemple,les donnesconcernantdeuxcompagniesencomptitionouenconcurrence)sontgroups ensembles. Chaque groupe est appel une classe de conflit dintrt (en anglaisconflict 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 desaccsquelessujetsontdjtablissurlesdonnessuiteparexempledesconsultations. Pourcela,onprocdelintroductiondunematriceNquicontientlhistoriquedesaccs prcdemment effectus, il sagit en fait de placer les sujets et les objets respectivement en ligne etencolonnedelamatriceN.pourchaquecasedeNontrouveunboolenquiindiquesiun accsadjeulieupourlecouple(sujet,objet)correspondant.Cemodleimposeunergle simpleetuneproprittoile[19]pourinterdirel'accsauxobjetsappartenantdesensembles conflictuels. La permission daccs un objet O est accorde pour un sujet7S seulement si :

7Dans la proprit simpleSdsigne seulement un utilisateur (pas un processus). 27 La proprit simple : l'objetOappartientlammeclassededonnesdj accde par le sujet S( l'intrieur de la muraille)ou,sil'objetOappartientuneautreclassedeconflits dintrtcompltementdiffrentlaquelleSnajamais accd. La proprit toile : si S peut lire O et, si S na jamais crit dans un autre datasetque celui o il essaie dcrire. Letermeinformationaseptiseouinformationassainiedsigneuneinformation dissimuledemanirecequilsoitimpossiblededcouvriroudereprerlacompagnie laquelle cette information appartient.La rgle proprit toileprvient principalement quun utilisateur lise des donnes dune compagnieetlescrivedansunfichierduneautrecompagnie,cequiprovoqueraitunefuite dinformation. Limites du modle de la muraille de Chine:Bien que le modle rsolve le problme de conflit dintrt, il souffredune limite concernant le blocagedusystmelorsdelapplicationdesdeuxpropritssimpleettoile.Eneffet,ondoit tenirenconsidrationlescontraintesimposantausystmed'avoirunnombred'utilisateurs suprieur ou gal au nombre maximal des ensembles des donnes conflictuels[19]. c.Le modle Biba LesfaiblessesdumodledeBell-LaPadulaqui nes'intressequedelaconfidentialitet neprendpasencomptel'intgritdesdonnes,ontpoussBiba[20]deproposer(en1977)une politiquedualecelledeBelletLapadula,appellemodled'intgritdeBiba,quipermetde garantirquaucunsujetdeniveauinfrieurnepuissemodifierindirectementdesobjets appartenant un niveau suprieur. ToutcommelemodleBLP,lemodledeBibaestdfinipardeuxproprits:la propritsimpleetlaproprittoile.Cesdeuxpropritsdoiventtresatisfaitespourassurer lintgrit des donnes : la proprit simpleNo Read down : Un sujet ne peut accder en lecture un objet que si le niveaudeclassificationdel'objetdomineceluidusujet.D'unefaonsimilairequepourle modledeBLP,lattributiondeniveauxdescuritauxobjetsetauxsujetscommeindiqu 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 quialaclassificationConfidentielparcequeleniveaudescuritConfidentielest infrieur au niveau de scurit Top-Secret.UnsujetquialhabilitationSecretaledroitdaccderenlectureunobjetquiala classificationSecretparcequelemmeniveaudescuritestattribuausujetet lobjet. 28 Figure 5- La proprit simple de Biba LaproprittoileNo Writeup:Unsujetnepeutaccderencritureunobjetquesile niveau de classification courant du sujet domine celui de l'objet. Plus formellement : La proprit simple se traduit par :(s, o, read)hab(s) Secret >Unclassified. Lesvaleursduchamp categories constituentunensembledlmentsnonordonns. 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 quesiondisposesuffisammentdesensibilitetquonestautorisaccderaucompartiment dmarqu par la catgorie de lobjet. 50 Lacombinaisonentreunesensibilitavecunensembledecatgoriesconstitueleniveau 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] CecontextesignifiequelidentitSELinuxuser_uestmisdanslerlesystem_rqui estconfindansletypesystem_t. user_u possdeleniveaudescurits0:c0.c16 cest--dire de sensibilit s0 et est cloisonner dans le compartimentc0.c16.Ilestpossibledexprimerlescontraintessurlesniveauxdescuritduncontextepour lesquellesMLSetMCSsontactivs.Pourcela,SELinuxutiliselesmotsclsmlsconstrainet mlsvalidatetrans pour dfinir deux types de contraintes, en voici deuxexemples : Exemple 1:mlsconstrain file write ( l1 domby l2 ); Cettecontrainte,obligequetoutprocessusquitentedcriredansunfichierdeniveau 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)); Lacontraintemlsvalidatetranspeuttreutiliselorsquunobjetsolliciteun changementdesonniveaudescurit,lExemple2montrequenotrecontrainteexigequun 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) champssparsparlecaractre:(deuxpoints).Chaquechampspcifieuncomposantdu contextedescurit,savoir:l'utilisateur,lerle,letypeetleniveaudecefichierouce 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.OnpeututiliserAussilacommandechconpourchangerlecontextedunfichier. 51 SELinuxgarantitquelecontextedescuritdunfichierresteratoujourslemme,mmeaprs 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 lequelleprocessusestexcut,unsujetconservesonidentittoutaulongdesasessioncequi permetlimputabilit(latraabilit)desactionssurlesystmemmeaprslexcutiondela commandesu (ou sudo). Toutefois, il peut y avoir des exceptions la rgle de persistance des identits SELinux, et ce dans les deux cas suivantes : Laffectationdelidentitinitialedunutilisateur:authentificationpardesprocessus comme : login, ssh, gdm. Lexcution dun processus sous une autre identit: utilisation de la commande cron. Pourcontrlerlidentitdesutilisateurs,SELinuxutilisesaproprebasededonneset 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. DanslamajoritdesdistributionsLinux,SElinuxattribuechaqueutilisateur(ou processus) une des identits prdfinies dans la politique de scurit (Cf. 1), ces identits sont fourni comme suit :root:estlidentitSELinuxquonobtientquandonseconnectesurlaconsoleentant quutilisateur Linux : root.system_u : est lidentit SELinux par dfaut des processus excuts durant la phase de dmarrage. user_u:estlidentitSELinuxobtenuepardfautpourunutilisateurconnectsurle systme. Remarque:chaquedistributionpeutajouterdesidentitsspcifiques,Eneffet,parexemplela distribution Gentoo ajoute deux autres identits : staff_u et sysadm_u. 2.4.1.2.Rle Lerledelutilisateurestlasecondecomposanteducontextedescurit,ilestliau modleRBAC.LapolitiquedescuritSELinuxdfinitunensemblederlesainsiqueles utilisateurs qui ont accs ces rles, chaque rle reprsente un ensemble de types grer.Quandunutilisateurseconnecteets'authentifieauprsdusystmeilsetrouve,un instantdonn,dansunrleparmiunensembledeceuxquiluisontautoriss.Ilpeutgalement 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 desobjets,engnral,ilexistecinqrlesdontquatresontexplicitementprdfinis: system_r, user_r, staff_r et sysadm_r. 52 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 SELinuxRlesDescription system_usystem_r Pourlesprocessussystmes(non-interactifs). Ne devrait pas tre attribue un utilisateur. user_uuser_r Pourlesutilisateurssansprivilge.La correspondance par dfaut. staff_ustaff_r, sysadm_r Pourlesadministrateurssystmesquise connectentgalementpourexcuterdes tches d'utilisateur normal.sysadm_usysadm_r Pourlesadministrateurssystmesquine fontqueseconnecterpourexcuterdes tchesadministratives.Ilestsuggrde ne pas utiliser cette identit. rootstaff_r, sysadm_r Identitspcialepourroot.Lesautres utilisateursdevraientpluttutiliser 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. UntypeSELinuxmlangedessujetsetdesobjetsayantlesmmesautorisations.Les processusdunmmedomaineetlesobjetsdunmmetypesonttraitsdefaonidentiques. SELinuxsebaseessentiellementpourlaprisededcisiondaccssurllmenttype(ou domaine)quiconfinelesprocessusdansdessandboxeslesquelsempchentl'escaladedes privilges en offrant un environnement contrl. Une politique de scurit SELinux peut tre dfinie seulement avec quelques utilisateurs et rles,maisdesdizainesvoiremmedescentainesdetypes,cequijustifieleursimportances. Pourdesraisonsdesimplicitonutiliselanotiondattributpourconstruiredesensemblesde typesafindoctroyer,parexempledesautorisationsgroupesoudediffrencierentrelestypes et/ou les domaines. Les attributs sont donc utiliss pour mieux grer les politiques complexes. 53 Laccs dun processus un fichier se fait seulement lorsque le serveur de scurit trouve unergledetypeallow(oudontauditouauditallow)quidonnelapermissionau domainesourcedavoiraccsautypeselonloprationdsire.Ilenestdemmelorsquun processus veut excuter une opration impliquant un autre processus, ou le processus lui-mme.LapolitiquedescuritreprsentelecurdeSELinux,ellespcifielesrglesdansun environnement dimplmentation des modles TE et RBAC, et elle est crite par un langage conu spcialement pour crire les politiques de scurit. LapolitiquedescuritSELinuxdfinitlesdiversesrglesquinoncentcommentles domaines peuvent accder aux types. Par dfaut, et hormis celles qui sont explicitement permises parunergledescuritapproprie,touteslesoprationssontrefusespuisauditesdansle rpertoire/var/log/messages(casdesdistributions :RedHatetFedora)ou /var/log/audit,gnralementlavaleurdelavariabledenvironnement:$AUDIT_LOG indique lemplacement des fichiers de journalisation des dcision de refus daccs. Ladministrateurdelapolitiquedescuritpeutladfinirenmodifiantlesfichiersde scuritexistant,telestlecasdesdistributionsFedoraetRedHatquiproposentdespolitiques 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. Danslesparagraphessuivantsnousallonsexpliquercommentlapolitiqueestcharge 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 contextesdescurit(identit:rle:type)pourchaqueobjetetchaquesujetetdautrepartles autorisationsdaccsetdetransitiondesdomainesauxtypes.SELinuxpermettraverssa politiquedescurit,derestreindrelavisibilitdunprocessussurlensembledusystmeetde ses objets.2.4.2.Fichiers et rpertoires lis la politique de scurit Avantdnumrerlesdiffrentsfichiersetrpertoiresquiconstituentlapolitiquede scuritdployepardesdistributionsdeLinux,ilestrappelerqueSELinuxestinstallet activpardfautsouslesdistributions :Fedora,CentOSetRedHat.Cependantlepackagede SELinuxnestpasinstallsurdautresdistributionscommeGentoo.Letableausuivantmontre lemplacement des rpertoires source de SELinux pour quelques distributions : DistributionRpertoire source (directory-policy) Debian /etc/selinux Fedora /etc/security/selinux/src/policy RedHat /etc/selinux Tableau 10-Rpertoires source de quelques distributions Le rpertoire directory-policyde chaque distribution contient le fichier config et les sous-rpertoires : strict et targeted. directory-policy /config : dsigne le fichier de configuration par dfaut de lapolitiquedescurit.Ilcontientdeuxvariablesd'environnement:SELINUXet SELINUXTYPEquidterminentletypedelapolitiquedescuritappliquer.La premirevariable(savoirSELINUX)peutavoirlesvaleurssuivantes:Enforcing, permissive ou disabled :54 enforcing La politique de scurit de SELinux est applique. PermissiveLesystmeSELinuxmetdesmessagesd'avertissementsmais n'applique pas la politique (utile pour le dbogage) ou la rsolution de problmes. Enmodepermissif,touslesrefusserontjournalissainsilessujetsseronten mesuredepoursuivredesactionsqui,enmodeenforcing,seraientparcontre 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. StrictLaprotectionSELinuxesttotaleetce,pourtouslesdmons.Les contextesdescuritsontdfinispourtouslessujetsetobjetsettouteactionest 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:dsignelerpertoiredelapolitiquedite cible, on y trouve la politique source et la politique binaire : directory-policy /targeted/policy/cesous-rpertoire contient le fichier binaire de la politique de scurit : policy.NO (cas de RHL4). directory-policy /targeted/src/policy/cesous-rpertoire contient les fichiers sources de la politique de scurit. directory-policy /targeted/contexts/cesous-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,ilestutilispourlacommunicationentrelenoyauetlesutilisateurs (processus), ou pour changer les flags tels que la politiques boolennes ou pour basculer entrelesmodespermissiveetenforcing,ilpeutenfinservirpourtrouverl'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 SELinuxjoueungrandrleaucoursdespremirestapesdudmarragedusystme.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, prdfinieest assignau processus initial.Les SIDInitiaux sont utiliss pour l'amorage avant que la politique soit charge. 55 Leprocessus/sbin/initmontelapartition/proc/,etchercheensuiteletypeselinuxfs 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 vialeparamtrededmarrageselinux=0,ousilefichier directory-policy /config spcifiequeleparamtreSELINUX=disabled,lesystmeest donc dmarr par le processus du boot sans SELinux. Au mme temps, init dfinit ltat enforcing si cette valeur est diffrente de celle du paramtreSELINUXdufichier directory-policy /config.Celasurvient lorsquunparamtreestpassaucoursduprocessusdedmarrage,tellesque enforcing=0 ouenforcing=1.Lenoyaunappliqueaucunepolitiquejusqu'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,initconsulteensuitelefichierdirectory-policy/config pour voir quelle politique est actuellement applique par SELinux (exemple : targeted), puis recharge le fichier associ: directory-policy /targeted/policy/policy..Sila politiquebinairenestpassupporteparlenoyau,initvatenterdechargerlaversion prcdente toute en assurant la compatibilit des versions. Lapolitiqueestmaintenantentirementchargedanslenoyau.LesSIDinitiauxsont ensuite mapps des contextes de scurit dans la politique telle quelle est dfinie dans lefichier: directory-policy/targeted/src/policy/initial_sid_contexts.Danslecas dunepolitiquecibletargeted,lenouveaudomaineest: user_u:system_r:unconfined_t.parlasuitelenoyaupeutcommencer rcuprer dynamiquement des contextes de scurit partir du serveur de scurit dans le noyau. initsauto-excuteafinqu'ilpuissetablirunetransitionversunautredomaine, vidementsiunergledelapolitiquelautorise.Pourlapolitiquecibletargeted,le processusinitrestedansledomaineunconfined_tpuisquilnyaaucune transition dfinie dans la politique. init poursuit normalement le processus de dmarrage. 2.4.4.Systmes de fichiers et attributs tendus. SELinuxutiliselesattributstendusxattr:extendedattributespourstockerdes tiquettes de scurit sur chaque fichier. Ces attributs tendus ncessitent l'utilisation de systmes defichiersext2,ext3etJFS.LesystmedefichiersXFSestgalementsupportmais prsentedeslimitescommeloccupationd'espacedisquequiralentitparlasuitelesystme 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 : 56 Systmes de fichiersDescription ext2 est un systme de fichiers qui ne journalise pas les mtadonnes, c'est--dire que le systme prend un tempsconsidrable pour la vrification du systme de fichier lors de la phase de dmarrage. ext3 Est un systme de fichier trsfiable, stableet performant,cestla version journalise du systme de fichiers ext2, il minimise le temps dattente lors dun dmarrage du systme. JFS Estlesystmedefichiersjournalishautesperformances d'IBM.C'estunsystmerapideetsravecdebonnes performances dans diverses configurations.ReiserFS ToutcommeleJFS,ReiserFSestunsystmedefichiers journalisquiprsentedetrsbonnesperformances,ilest apparemmentmoinsmaintenuquelesautressystmesde 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,maisavecunegranderestriction:touslesfichiersdumontageaurontle 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 modleTE Les dclarationsTE (Type Enforcement) sont les principales composantesde 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. Lesattributspeuventtreutilisslorsdeladclarationd'untypeetpeuventtreassocisun nombrequelconquedetypes.Lesattributspeuventtreutilisslorsdelaspcificationdes permissionssurlestypes,ondclarelesattributsdanslefichierdedclarationdirectory-policy/targeted/src/policy/attrib.te de la faon suivante :attribute Nom_Attribut; Exemple : attribute domain1 ; Cetexemplereprsenteladclarationdunattributquipeuttreutilis pourdsignerun 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 typespcifieunnomprincipalpourletype,unensemblefacultatifd'aliaspourletype,etun

14vfat est ue etesio des sstes de fichies de tpe FAT de Micosoft ui peet lutilisatio de noms de fichiers longs 15ISO9660estunenormedel'OrganisationInternationaledeNormalisation,quidfinitlesystmedefichiersutilissurles CDROM. 57 ensemblefacultatifd'attributspourletype.Lasyntaxed'unedclarationdetypeestla 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.Pourlesprocessus,letypesourceestprocessetletypecibleestletypede l'excutable.Silatransitionestsurdesobjets,letypesourceestledomaineduprocessusde 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 nouveauxfichiersetdesprocessusestcalculeenfonctiondescontextesdeleursparents.Pour lesfichiers,celasignifiequ'ilsrecevrontletypedurpertoireparent.Pourlesnouveaux processus,celasignifiequ'ilsserontexcutsdanslemmedomainequeceluiduprocessusde cration. 2.4.5.4.Transition de domaine Danstoutcequisuit,lanotiondetransitiondedomaineestillustretraversdeux exemples,Lunconcernelatransitiondedomaineaudmarragetandisquelautretraitela transitiondedomainelorsdelexcutionduneapplication,elleseraillustre par le programme de changement de mot de passe: a.Transitions des domaines au dmarrage AudmarragedunemachineLinuxdontSELinuxestinstalletestactiv,chaque processusnouvellementcresevoitattribuerundomaineappropri,commenantparle domainedelancementkernel_t duprocessus 1jusquauxdomainesdesprocessusdu login.LaFigure23[32]prsenteundiagrammequimontrelestransitionsdedomaineau dmarragedusystme.Ilfaitressortirlesnomsdestypes/domainesetdesmacrosutiliss pour mettre en uvre les transitions.SELinux utilise le langage des macros appel m4 pour l'criture des rgles de politique rutilisables.Celafacilitelardactionetparlasuitelagestiondelapolitiquedescurit. 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. 58 kernel_t lanceinit,enlemettanteninit_t(letypedufichierdanslequelon 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. Laconsolelanceleprocessusdesaisiedelogin/(motdepasse)dansledomaine local_login_t (ou login_t) Lorsquunutilisateurseconnecte,sonshellseraplacdansuser_t(ou unconfined_t)lasuitedunetransitiondedomaineenclenchepar local_login_t (ou login_t). Touslesdmonslancsparinitrcsontplacsdansleurdomainepardesrglesde transition de type appropries. Figure 23-Transition de type au dmarrage[32] b.Transition de domaine lors de lexcution dune application Latransitiondedomainependantlexcutionduneapplicationestillustreparla procduredechangement,parunutilisateurdusystme,desonmotdepasse.Laditetransition 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. LasolutionclassiquedeLinux :Unprocessustournegnralementaveclesmmes 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) neseconformentpascettergleetsontexcutsaveclespermissionsdupropritairedela commande.59 Unutilisateurordinairenepeutpaschangersonmotdepasseenditantdirectementle 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 aufichiershadowsurlequelIln'yaquelerootquipossdelespermissionsdelectureet d'criture. Bienquecettetechniqueaitrsolubeaucoupdeproblme,ellepossdelerisquede compromettrelascuritdetoutlesystmepuisqueleprocessusquiexcutelacommande 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 quiestluiaussilapropritduroot (Cf.Listing1),peuttremodifiparnimporte 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 denelaisseraucunprocessuslemodifiersaufsiltournedansledomainepasswd_t,cetype doittreautoris,explicitementparunergledelapolitiquedescurit,modifierdansles fichiers ayant le type shadow_t. Lorsquun utilisateur ordinaire se connecte au systme, son processus Shell tourne dans le domaineunconfined_t(domainedesprocessusutilisateursordinaire).SELinuxassure, traversunergledetransition,lechangementdudomaineuser_t dushellversledomaine passwd_t du processus excutant la commandepasswd.Lide de latransition 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:Le domaine dans lequel le Shell de lutilisateur sexcute. passwd_t:Le domaine o le programme des mots passe tourne. shadow_t:Le type de fichier des mots de passe comme : /etc/shadow. passwd_exec_t :Le type du fichier excutable (la commande)passwd. Lesdomainesettypesci-dessussontutilisspardesrglesdelapolitiquedescurit (Type Enforcement), de la faon suivante: La premire rgle : allow unconfined_t passwd_exec_t : file {getattr execute}; 60 Cette rgle permet au shell, qui tourne dans le domaine unconfined_t de lutilisateur sollicitantlechangementdesonmotdepasse,dexcuter(etparconsquentdinitierunappel systme execve()) la commande passwd qui possde le type passwd_exec_t. Le shell consulte lesautorisations 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; Pourcettergle,lesexcutablesdetypepasswd_exec_tserventdepointd'entre pourletypepasswd_t.Etquandunprocessusmarquunconfined_tlanceunfichierde type passwd_exec_t, le processus cr possdefinalement le typepasswd_t.Il s'agit d'un contrledescuritpuissantquigarantitquuniquementleprogrammedemotdepassepuisse tre excut dans le domaine passwd_t du moment o : Seul le fichier excutable passwd est tiquet avecpasswd_exec_t. letypepasswd_testleseulquialapermissionentrypointservantdepoint d'entre au type passwd_exec_t. Onpeutentrerdanspasswd_tseulementavecuneapplicationdetype passwd_exec_t,laquellenepeutqu'excuterdeslibrairiespermises(lib_t)etne peut pas dmarrer d'autres applications. La troisime rgle :allow unconfined_t passwd_t : process transition; Ilsagitdunergledescuritallow utilisantlapermissiontransitionquiest 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:allowpasswd_tshadow_t:file{ioclreadwritecreate getattr setattr lock relabelfrom relabelto append unlink link rename}; Celasignifiequeseulslesprocessustournantdansledomainepasswd_tpuissent excuterlesoprations :{iocl,read,write,create,getattr,setattr, lock, relabelfrom, relabelto, append, unlink, link, rename}surles fichiersdetypeshadow_t,cequiveutdirequeseulpasswd_tpeutcriredans shadow_t. En cas gnral passwd_t ne peut crire que dans shadow_t et etc_t. La rgle principale :type_transition unconfined_tpasswd_exec_t : processpasswd_t; 61 Cettergleestintroduitepoursupporterlestransitionsquiseproduisentpardfaut,elle sappellelargledetransitiondetype :type_transition,ellespcifielestransitionspar dfaut qui devrait se produire si aucune transition explicite nest prsente. Gnralementlesrglestype_transitionsontdfiniespardesmacrosquiles combinentavecunensemblederglesTE(dansnotreexemple,ilsagitdesrgles susmentionnes). Danscetexemple,largletype_transitionindiqueque,pardfautetlorsdun appelsystmeexecve(),sileprocessusappelantestdetypeunconfined_t etletypedu fichierexcutableestpasswd_exec_t,unetransitiondedomaineversunnouveaudomaine 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,lequelaintgrlespropritsdesapprochesexistantesdesapplicationsspcifiques. RBAC est devenu le plus dominant des modles de contrle d'accs. En effet,Il a t considr commeunealternativeaumodleMAC(MandatoryAccessControl)etaumodleDAC (Discretionary Access Control). 2.5.1.2.Les modles constituant RBAC En1996,Ravietal.ontintroduitdans[7]unFrameworkpourlesmodlesRBACqui intgrent les fonctionnalits suivantes : RBAC0atdfinicommetantlemodledebase,dfinietraverslesutilisateurs,les rles et les autorisations.RBAC1comprendRBAC0maisincorporedeshirarchiescommeunerelationd'ordre partiel entre les rles.RBAC2intgregalementRBAC0,maisajoutedescontraintes.RBAC1etRBAC2sont indpendants les uns des autres, de telle sorte quun systme peut mettre implmenter un sans lautre. RBAC3estunmodlequirassemblepleinementlespropritsdeRBAC,incorporant RBAC0,RBAC1,etRBAC2.RBAC3estquivalentaumodle[24],l'exceptionde RBAC3quipermetunehirarchied'ordrepartielalorsquelemodle[24]dfinitla hirarchie comme un arbre enracin.Entermesorientsobjet,lemodle[7]peuttre considrcommeincorporantl'hritage multiple alors que [24] utilise l'hritage unique. 62 2.5.1.3.Logiquede description: modlisation de la hirarchie des rles Zhaoetal.[33]montrentcommentutiliserlaLogiquededescriptionpourmodliserla hirarchiedesrles,despermissionsetsessionsquiluisontassocis.Ellenecouvrepasles autrestypesdecontrlesdescurittrouvsdansSELinux,maisdfinitunestructurepourla 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]sinspirede[33]pourmontrercommentformaliserlesmodlesde contrlesd'accsutilisparSELinuxeninvoquantdesrequtestraversunlangageappel: {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 unecouche RBAC, lemodle MLSyest galement implment dune faon optionnelle. SELinux spcifie laccs bass sur les rles en terme de TE, Cependant, le but de RBAC dan