Nous avons présenté dans ce chapitre les principaux modèles de contrôle d’ac- cès et leurs applications aux architectures orientées services. Le contrôle d’accès permet d’indiquer si un sujet est autorisé ou non à accéder à un objet et à son contenu. Cependant ce modèle de politique de sécurité ne permet pas de contrô- ler la dissémination d’une information. En effet une fois qu’un sujet a accédé au contenu d’un objet, il n’y a plus aucun contrôle sur ce que le sujet fait du contenu de l’objet.
Les modèles de contrôle d’accès permettent de définir une politique d’emploi des services au sein d’une entreprise ou d’une organisation. Cependant ils ne per- mettent pas à un utilisateur de définir une politique d’emploi des informations qu’il fournit à une orchestration de services. Afin de pouvoir contrôler la dissémination d’informations au sein d’une orchestration de services nous avons étudié les mo- dèles de politique de sécurité ainsi que les techniques permettant le contrôle des flux d’informations. Ces modèles sont présentés dans le chapitre suivant.
Chapitre 3
Contrôle de flux d’information
L’objectif du contrôle de flux d’information est de contrôler la diffusion de l’information au cours de l’exécution d’un programme ou d’un système. Une poli- tique de flux d’information définit les flux d’information autorisés ou interdits. Une violation de la politique de flux est détectée lorsqu’un utilisateur accède à tout ou partie d’une information à laquelle il ne devrait pas accéder selon cette politique.
Dans ce chapitre, nous présentons les principes généraux du contrôle de flux d’information, nous nous intéressons aux différentes politiques de flux qui per- mettent sa mise en place, puis nous décrivons les différents modes d’implémen- tations utilisés (en particulier les approches statiques et dynamiques). Nous pré- sentons enfin les principaux problèmes liés aux modifications des politiques de contrôle de flux.
3.1 Suivi des flux d’information
3.1.1 Flux d’information
Les flux d’information expriment une relation de dépendance entre des données sources et des données cibles. De manière générale il y a un flux d’information d’un objeta vers un objet b dès lors que l’information contenue dans b dépend de l’information contenue dansa. Certains des tous premiers travaux à s’intéresser à la notion de flux d’information sont ceux de Denning ([Den76, DD77]). L’auteur notea ⇒ b, le flux d’information d’un objet a vers un objet b.
Le suivi des flux d’information peut s’effectuer à plusieurs niveaux. Des ana- lyses des flux d’information ont été proposées tant pour les programmes [DD77], qu’au niveau des systèmes d’exploitation [ZMB03, EKV+05, KYB+07] ou des architectures de services [HV06, RM09].
3.1.2 Flux d’information au sein des programmes
Denning [Den76, DD77] s’intéresse aux flux d’information au sein des pro- grammes et en distingue en particulier deux types :
– Les flux explicites, un flux explicitex ⇒ y est généré d’un objet x vers un objety si ce flux est généré indépendamment de la valeur de x. Par exemple, les opérations d’affectation ou les entrées sorties sont à l’origine de flux explicites. Ainsi l’élément de programme suivant constitue un flux explicite des variablesx et y vers z :
z : = x+y ;
A la fin de l’exécution de ce programme, le contenu de la variablez dépend à la fois des informations dex et de celles de y et le flux x, y ⇒ z est effectué quelle que soit la valeur dex et de y.
– Les flux implicites, c’est à dire les informations passées à travers les struc- tures de contrôle d’un programme. Un fluxx ⇒ y est implicite si l’opération générant ce flux est conditionné par la valeur de x. Par exemple, suivant la valeur dex, une opération génère un flux explicite z ⇒ y, z pouvant être une constante. A l’issue de l’exécution de l’opération, la valeur dey dépend donc de la valeur dex et potentiellement de celle de z. L’élément de programme suivant constitue un flux implicite d’informationx ⇒ y si la variable y n’a pas été créée avant l’exécution de cet élément :
i f x=0 then y : = 1 ;
En effet une information surx est apportée par y grâce à l’affectation y := 1. Ainsi siy = 2 alors on sait que x 6= 0. On distingue en particulier :
– les flux implicites directs créés lorsque la variable y = 1 ce qui nous indique quex = 0,
– les flux implicites indirects créés pary lorsque x 6= 0, en effet dans ce cas y n’existe pas, mais sa non existence nous indique que x 6= 0.
3.1.3 Flux d’information dans un système d’exploitation
Un système d’exploitation assure une interface entre les processus (c’est à dire l’ensemble des programmes en cours d’exécution sur celui-ci) et la couche maté- rielle. Le suivi des flux d’information au sein d’un système d’exploitation permet de suivre les flux d’information générés par l’ensemble des applications du sys- tème. Le rôle du noyau du système d’exploitation est de gérer les ressources ma- térielles et de fournir aux programmes une interface uniforme pour l’accès à ces ressources. L’accès aux ressources est fourni par des fonctions primitives appelées appels système. Les appels systèmes permettent en particulier de contrôler l’ac- cès aux fichiers et à la mémoire, de contrôler les processus et les communications inter-processus. Le contrôle des flux d’information dans un système passe donc par l’étude des flux d’information créés par ces appels systèmes.
Les travaux de Bell et Lapadula [BL76] modélisent les flux d’information par les accès en lecture et en écriture. Par exemple, un flux d’information d’un conte- neur A vers un conteneur B est considéré si un programme accède en lecture au conteneur A et en écriture au conteneur B. Une partie du contenu de B provient alors potentiellement de A.
3.1 Suivi des flux d’information 25
Plusieurs travaux permettant de contrôler les flux d’information au niveau du système d’exploitation ont été proposés. Zimmerman [ZMB03] propose par exemple Blare, une surcouche du système Linux permettant de suivre les flux d’information intervenant lors des appels systèmes. Les auteurs de Flume [KYB+07] proposent une autre surcouche du système Linux permettant le suivi dynamique des flux d’in- formation. D’autres travaux se sont intéressés à développer de nouveaux systèmes d’exploitation permettant nativement le suivi dynamique de flux d’information comme par exemple les systèmes Asbestos [EKV+05] ou Histar [ZBWKM06].
La plupart des modèles proposés ([ZMB03, EKV+05, KYB+07]) considèrent les processus comme des boîtes noires (toutes les sorties dépendent de toutes les entrées). Les flux d’information considérés sont ceux qui interviennent entre les processus et les conteneurs d’information (en particulier fichiers et espaces mé- moire).
Cependant ce type d’approche considère des conteneurs d’information de forte granularité et adaptés au niveau du système d’exploitation (fichier, page mémoire, etc.). Le système n’a donc pas accès aux flux internes des applications entre conte- neurs de faible granularité (variable, champs d’objets, etc.) et est amené à sur- approximer les flux d’information. Certains travaux comme [Hie08] ont cherché à lier une analyse au niveau du système d’exploitation à une analyse au niveau des programmes afin de prendre en compte le maximum de flux d’information.
3.1.4 Flux d’information dans les orchestrations de service
Au niveau des architectures orientées services [HV06, RM09], les approches proposées sont à mi-chemin entre les approches système et les approches pro- gramme. Elles considèrent en effet le plus souvent les orchestrations de services. Elles considèrent les flux d’information au sein des orchestrations de services comme au sein d’un programme interagissant avec d’autres services qui sont alors vus comme des appels de fonction. Nous retrouvons alors les flux décrits par Den- ning au sein des programmes, c’est à dire les flux explicites (lors des appels de services ou des affectations de variables par exemple) et les flux implicites (pro- duits par les boucles et les conditionnelles).
Les auteurs de [HV06] présentent deux problèmes spécifiques aux architectures orientées services.
Un premier problème est posé par la nature dynamique des architectures orien- tées services. En effet le lien vers le service effectivement exécuté peut n’être ef- fectué qu’au cours de l’exécution d’une orchestration de services. Le service est d’abord recherché dans un annuaire avant d’être effectivement exécuté. L’informa- tion sur le flux d’information effectivement exécuté n’est alors disponible qu’au moment de l’exécution.
Le second problème est lié aux différentes entités impliquées dans une architec- ture orientée service. Le contrôle de flux d’information ne doit en effet pas seule- ment s’effectuer au sein de l’orchestration de services, mais doit aussi prendre en compte les flux générés par l’invocation de services externes. En effet, le résultat
d’une invocation de service dépend à la fois des données utilisées par l’orchestra- tion pour accéder à ce service et des données internes au service.