analyse complète du système pour identifier les informations sensibles et leurs conteneurs légaux. Le deuxième point est le nombre d’information sensible sur le système. Contrairement à ce que les permissions Android pourraient laisser croire, il peut y avoir un nombre assez conséquent d’information sensible sur le système. La politique que nous avons construite recense 150 informations mais il y a encore plus d’information que cela dans un système.
3.3
KBlare : suivi et contrôle de flux via LSM
Le cœur de Blare a été développée en tant que module de sécurité Linux. Il réside dans le noyau et est appelé KBlare. Dans le reste du document, nous désignons par KBlare l’implémentation de Blare dans le noyau et Blare tout l’environnement d’exécution Blare (KBlare plus les outils en espace utilisateur lié à Blare). Les flux d’information au niveau du système se font via les inter- actions entre les objets du système et plus précisément via les appels système effectués par les processus. Pour contrôler les flux d’information, KBlare inter- cepte ainsi les appels système en utilisant les hooks LSM [103, 102]. LSM est un framework de sécurité dans le noyau utilisé pour implémenter les modules de sécurité Linux. Les hooks sont des appels aux modules de sécurité du noyau. Ils sont placés dans le flux d’exécution des appels système afin que les modules de sécurité puisse intercepter et contrôler ces appels. Pour intercepter un appel système, un module de sécurité enregistre une fonction à associer au hook cor- respondant à l’appel système. À chaque fois que ce hook est atteint, le noyau appelle la fonction enregistrée afin que le module de sécurité effectue le contrôle souhaité.
La figure 3.3 illustre le fonctionnement général de LSM. Lors d’un appel système, le noyau vérifie si l’accès demandé est autorisé pour le processus ef- fectuant l’appel. Il commence par vérifier la conformité avec la politique DAC du système. Ensuite, il donne la main à LSM qui lui demande au module de sécurité actif3 s’il autorise ou non l’accès demandé. Cette étape correspond au
moment où un hook est atteint dans le flux de traitement de l’appel système. La fonction enregistrée au hook est ainsi appelée et statue si l’accès est autorisé. Lorsqu’un processus fait un appel système, KBlare intercepte l’appel, calcule le flux correspondant, met à jour les tags des objets modifiés et contrôle la légalité du flux observé. KBlare se contente cependant de détecter les intrusions mais ne les prévient pas. Même en cas de violation de la politique de flux d’information, il autorise le noyau à continuer le traitement de l’appel système.
Le tableau 3.4 liste les hooks utilisés par KBlare dont l’opération corres- pondante peut engendrer des flux d’information. La première colonne liste les hooks, le deuxième les opérations interceptées via le hook et la dernière colonne les types de flux que KBlare peut observer. D’autres hooks sont utilisés pour le fonctionnement interne de KBlare mais les opérations correspondantes n’in- duisent aucun flux d’information.
process Syscall #n Security module DAC LSM User space Kernel space exec syscall authorize?
3.3. KBLARE : SUIVI ET CONTRÔLE DE FLUX VIA LSM 67
Hook Opération Flux possible observé
file_permission Lecture/écriture à un fi- chier ouvert
Entre le processus et le fichier accédé
file_mmap Chargement en mé-
moire du contenu d’un fichier
Du fichier vers le pro- cessus
inode_permission Accès à un i-node Entre un pipe et un pro- cessus
bprm_set_creds Exécution d’une appli-
cation native Du fichier contenantl’application vers le processus
socket_sock_rcv_skb Réception d’un paquet réseau
De paquet reçu vers le processus
socket_sendmsg Envoi d’un message
dans un socket réseau
Du processus vers le so- cket et le paquet socket_recvmsg Réception d’un message
via un socket
Du socket vers le pro- cessus
unix_may_send Envoi d’un message via un socket UNIX
Du processus vers le so- cket UNIX
msg_queue_msgrcv Réception d’un message via une file de message
Du processus vers le message envoyé
msg_queue_msgsnd Envoi d’un message dans une file de mes- sage
Du message reçu vers le processus destina- taire du message
Table3.4 – Liste des hooks LSM utilisés par KBlare pouvant engendrer un flux d’information
Stockage des tags
KBlare représente les tags des objets du système avec des structures conte- nant l’itag, le ptag et le xptag associés aux objets. En dehors des hooks, LSM a également modifié les structures représentant les objets du système pour ajou- ter un champ appelé security. Ce champ est un pointeur générique destiné à être utilisé par les modules de sécurité. KBlare utilise ce champ pour stocker le pointeur vers la structure représentant les tags.
Les structures représentant l’ensemble des tags existent uniquement en mé- moire et n’existent donc que le temps d’un cycle d’exécution du système. Afin de stocker de manière persistante les tags associés aux fichiers, KBlare stocke également leurs tags dans les attributs étendus des fichiers. Les attributs étendus sont des zone de mémoire sur le disque qui sont utilisées par les systèmes de fichier pour stocker des méta-données liées aux fichiers.
KBlare contrôle les flux d’information en interceptant les appels système et pour intercepter les appels système il utilise les hooks LSM. Ces appels per- mettent les interactions entre les objets du système : accès aux fichiers, exécution de code natif et communication entre processus. Le noyau d’Android est basé sur celui de Linux mais contient des fonctionnalités en plus. Dans la section suivante, nous présentons comment nous avons modifié KBlare afin de prendre en compte les fonctionnalités spécifiques à Android.