Protéger un système avec un outil tel que Blare signifie qu’il faut dans un premier temps définir une politique de sécurité. Dans le cas de Blare, cette politique est une politique de flux d’information. Elle identifie les informations à protéger et comment les protéger, c’est-à-dire la liste des conteneurs où elles ont le droit de se propager. Définir une politique de flux d’information pour Blare se résume en quatre étapes.
1. Identifier les informations sensibles à protéger.
2. Associer à chacune de ces informations un identifiant unique. 3. Identifier les conteneurs légaux pour ces informations. 4. Définir la valeur des ptags à associer à ces conteneurs.
Il existe deux approches pour définir la politique de sécurité. La première consiste à la calculer à partir d’une autre politique existante telle qu’une po- litique de contrôle d’accès. Dans [56], Geller et al. ont proposé un algorithme qui transforme une politique de contrôle d’accès mandataire App Armor en une politique de flux d’information Blare. Les politiques App Armor définissent des profils de programme limitant leur accès aux autres objets du système tels que les fichiers. L’algorithme proposé prend en entrée un ensemble de profils App Armor et donne en sortie leur équivalent en terme de politique Blare. Cette approche a le mérite d’être automatique et rapide mais elle ne permet pas d’ex- ploiter toute l’expressivité d’une politique Blare. Un exemple de ce manque d’expressivité est la restriction sur les mélanges d’information. Un conteneur a le droit d’accéder aux informations i et j mais n’a pas le droit de les mélanger, c’est-à-dire que le conteneur contient soit i soit j mais pas les deux en même temps. Le listing 3.1 présente une politique App Armor pour le programme apache. Cette politique autorise le programme à lire le contenu des fichiers apache2.confet index.php. La politique de flux qui peut être déduite de cette politique est que les données dans les deux fichiers ont tout deux le droit de se propager vers le programme apache. Cependant, le propriétaire du contenu de ces deux fichiers peut souhaiter que le contenu de ces fichiers ne se mélangent pas. Cette contrainte ne peut-être exprimée avec une politique App Armor et une politique de flux exprimant une telle restriction ne peut donc être calculée à partir d’une politique App Armor.
{/usr/bin/apache,
{(/etc/apache2.conf, w), (/etc/apache2.conf, r),
(/www/index.php,r), (/usr/bin/ftpd, px)} }
3.2. DÉFINITION D’UNE POLITIQUE DE FLUX D’INFORMATION 63 La deuxième approche consiste à définir manuellement la politique de flux d’information. Cette approche est plus longue car elle implique une analyse complète du système mais permet d’exploiter toute l’expressivité d’une politique Blare.
Construction manuelle d’une politique pour Android
Dans [16], nous avons proposé une politique de flux d’information pour le système Android. La politique a été construite à la main en se basant sur une analyse manuelle du système. Le but était de fournir une politique à taille réelle pour un système entier. Comme écrit précédemment, la définition d’une poli- tique de flux se fait en quatre étapes.
La première étape est l’identification des informations sensibles à surveiller. Nous avons construit la liste des informations sensibles à partir des données que nous avons jugées sensibles sur le système Android. Ces informations incluent les données liées à l’utilisateur (ex : liste de contact et données de géolocalisation) mais aussi celles liées aux applications (ex : code et paramètres de configuration). Les données sensibles ont été identifiées en analysant manuellement le contenu des fichiers sur le système et en prenant en compte celles qui sont protégées par le mécanisme de permission. Notre politique recense 150 informations sensibles mélangeant données non exécutées et code exécuté à l’intérieur des processus. Il existe encore plus d’information sur un système Android2mais nous avons jugé
cette quantité d’information à surveiller suffisante pour construire une politique de flux d’information pour tout un système.
La deuxième étape consiste à identifier les conteneurs d’information. La liste des fichiers et programmes installées sur un système Android est assez simple à construire. Grâce à la commande find, nous pouvons lister tous les fichiers du système. Quant aux applications, les applications livrées sous forme d’apk sont connues grâce à la commande pm et les applications natives sont stockées dans /system/binet /system/xbin. La liste des utilisateurs est elle par contre moins évidente à construire car contrairement à un système Linux standard, il n’existe pas de fichier /etc/passwd ni de fichier /etc/shadow. Android définit en dur un ensemble restreint d’utilisateur nécessaire au fonctionnement de base du système tels que root, radio et system. Puis pour chaque application non native installée sur le système, il associe un utilisateur unique. Pour établir la liste des utilisateurs associés aux applications, nous nous sommes basés sur le contenu des fichiers /data/system/packages.list ou /data/system/packages.xml. Ils recensent les informations liées aux applications installées sur le téléphone dont l’utilisateur qui leur associé.
Une fois les données sensibles et conteneur identifiés, nous avons ensuite construit la politique de flux. La politique de chaque programme a été construite en analysant ses sources pour comprendre à quelles informations il accède. La politique de chaque utilisateur a été obtenue en faisant l’union des politiques des programmes qu’il peut exécuter. Dans la plupart des cas, il n’y aura qu’un
Identifiant des informations 11 -44 10 6 -55 -39 3 9 37 -37 Fichiers calendar.db ˆ contacts2.db ˆ ˆ mms.db ˆ telephony.db ˆ TelephonyProvider.apk ˆ Programmes com.android.calendar ˆ ˆ com.android.pro- viders.contact ˆ ˆ ˆ com.android.pro- viders.telephony ˆ ˆ ˆ Utilisateurs 10024 ˆ ˆ 10004 ˆ ˆ ˆ ˆ 1001 ˆ ˆ ˆ
Table3.3 – Un extrait de la politique de flux d’information
seul programme car en dehors des utilisateurs système les autres utilisateurs n’exécuteront que l’application à laquelle ils ont été associés. La politique des fichiers a été construite à partir des données qu’elles contiennent lors de l’analyse et de la politique des programmes qui y accèdent. Si une donnée sensible a été trouvée dans un fichier, nous avons supposé que ce fichier avait le droit de contenir la donnée. À ces données s’ajoutent celles auxquelles les applications qui ont le droit d’écriture au fichier peuvent accéder. Nous avons supposé que toute application avait le droit de stocker les données contenues dans les fichiers auxquels l’application a un accès légal. Généralement, il s’agit des fichiers dans le répertoire local de l’application. Pour les 150 informations identifiées lors de la première étape, nous avons identifié 186 conteneurs d’information pouvant accéder à ces informations où les stocker. La politique contient donc 186 ptags. La politique finale a été représentée sous la forme d’une matrice dont un extrait est présentée dans le tableau 3.3. Le chemin complet des fichiers a été omis pour une meilleure lisibilité. Une croix à l’intersection d’une ligne et d’une colonne signifie que le conteneur correspondant à la ligne a le droit de stocker l’information correspondant à la ligne. L’ensemble des croix sur une ligne l détermine ainsi le contenu maximal autorisé pour le conteneur correspondant à l. L’utilisateur 10004 (avant dernière ligne) a par exemple le droit d’accéder aux informations identifiées par 6, 10, ´39 et ´55. Autrement dit, son ptag vaut tt´55, ´39, 6, 10uu.
Si la pertinence de la politique n’a pas été évaluée dans ce travail, le travail effectué a cependant permis de mettre en évidence deux points. Le premier est
3.3. KBLARE : SUIVI ET CONTRÔLE DE FLUX VIA LSM 65