Couverture ElectroniqueS n°127

Pour répondre aux exigences de sécurité sur les appareils embarqués à ressources limitées, il faut installer une chaîne de confiance. Pour élaborer de telles solutions, une tendance est de s'appuyer sur l'utilisation de SELinux (Security enhanced Linux) afin, entre autres, de fournir les mécanismes MAC (Mandatory access control) nécessaires. Avec la présence toujours plus importante de Linux dans les appareils embarqués (téléphones mobiles, boîtiers de TV, appareils informatiques sans casques, équipements médicaux, etc.), il existe à l'heure actuelle une forte demande pour améliorer les exigences de sécurité de ces appareils en travaillant directement sur l'environnement du système d'exploitation.En effet, comme on peut aujourd'hui disposer d'une puissance informatique plus grande à un coût plus faible, développeurs et fabricants ont tendance à ajouter davantage de fonctions à des appareils auparavant inaptes à celles-ci ou bien qui n'étaient pas prévus pour cela (téléphones à puce, portables, systèmes de commandes médicaux complexes, appareils de navigation, etc.). La difficulté réside alors dans la manière de répondre aux exigences de sécurité d'un progiciel, qui dépend proportionnellement de sa complexité, sur un équipement de base comme un téléphone mobile (figure 1). La méthode de contrôle d'accès par défaut dans Linux, appelée DAC (Discretionary access control), est, dans ce cadre, considérée comme « insuffisante » pour les réalisations sensibles à la sécurité. Une situation qui a entraîné une demande croissante pour l'utilisation du mécanisme MAC (Mandatory access control ou contrôle d'accès obligatoire), proposé au sein de SELinux (voir encadré I), qui assure un « confinement effectif », c'est-à-dire un mécanisme permettant d'interdire à une application exploitée d'attaquer une autre application.Parallèlement, les approches de type HAS (Hardware assisted security) n'ont pas encore été suffisamment normalisées et sont encore considérées par l'industrie comme relativement immatures. Cependant, elles constituent un élément supplémentaire dans l'arsenal des outils utilisés par les architectes de sécurité, qui doivent trouver des solutions pour résoudre les problèmes comme la mise en place d'une base TCB (Trusted computing base ou base informatique sécurisée).Nous allons détailler, grâce à des aperçus architecturaux de haut niveau, les fondements de ce type d'approche fournissant les fonctions fondamentales et nécessaires pour assurer la sécurité et la fiabilité des services du système d'exploitation.Multinoyaux et virtualisationAu cours de ces dernières années la puissance de calcul incorporée dans les appareils embarqués s'est considérablement accrue, non seulement par l'ajout de fonctions à chaque noyau, mais aussi en augmentant le nombre des noyaux dans les architectures matérielles. Cette expansion a pour but de disposer d'une ressource matérielle dédiée pour chaque tâche de haut niveau, et donc de gérer plus facilement la conception du logiciel et sa réalisation par compartimentage matériel.Cette approche a suscité le développement récent des technologies de virtualisation dans le domaine embarqué. Il existe divers types de techniques de virtualisation (matériels et logiciels) assurant tous plusieurs « domaines d'hôte », chacun assurant un accès total à l'équipement sous-jacent, et par conception complètement indépendant des autres domaines d'hôte. Un élément fondamental de toute réalisation de virtualisation est une couche appelée « Hyperviseur » qui assure la médiation des interactions entre les domaines d'hôte, assurant l'accès aux ressources matérielles sous-jacentes pour les domaines d'hôte, et assurant la gestion nécessaire pendant le cycle de vie de chaque domaine d'hôte.Toute conception moderne, pour assurer une solution sécurisée dans l'espace embarqué, doit donc supposer qu'elle peut être contenue dans un domaine d'hôte virtualisé.A ce niveau, une digression est nécessaire. Pour décrire et expliquer les architectures Linux sécurisées, tirant parti de SELinux, nous avons sélectionné, côté matériel, l'architecture Arm qui propose notamment une fonction d'isolation de plusieurs environnements informatiques, appelée TrustZone. Cette technologie de sécurité introduite par Arm dans son noyau Arm 1176 assure, en effet, une isolation matérielle pour les environnements exécutables, et la divise en deux, l'une sécurisée et l'autre normale. Les applications sensibles sont exécutées dans un espace mémoire séparé qui n'est pas accessible aux applications normales.L'approche décrite dans cet article étudie la disponibilité de la technologie Arm TrustZone sur l'architecture matérielle sous-jacente, bien qu'il ne soit pas question ici d'analyser les piles de logiciels propriétaires placés sur l'équipement TrustZone, assurant des fonctions supplémentaires de sécurité pour les applications (*).A ce stade, nous sommes prêts à discuter de la machine virtuelle (VM) de chaque domaine, qui arbitrera les interactions entre les domaines et la machine virtuelle sous-jacente (figure 4). A partir de là, la vérification de l'intégrité des domaines se déroule parallèlement et suit le même chemin que celui représenté sur la figure 3.Un aspect important de cette architecture est le lien entre le mécanisme de contrôle d'accès au niveau des domaines au sein de la machine virtuelle et le mécanisme de contrôle d'accès, régissant chaque domaine au moment de l'exécution. Ce lien doit être bien défini et réalisé efficacement pour permettre une solution viable.Cette approche s'appuie sur des équipements de base fiables assurant la sécurité, et aussi fiables que le mécanisme les protégeant. L'approche réalise un mécanisme MAC s'appuyant sur SELinux embarqué et peut le faire dans un environnement virtualisé. Dans ce cas, on utilise les fonctions de sécurité disponibles dans les équipements (par exemple, équipement Trust-Zone) pour renforcer l'isolement entre les domaines d'hôte, via des zones séparées dédiées de mémoire pour différents processus existant dans chaque domaine. La gestion globale de la sécurité, comme les IPC (Inter process communication ou communication entre les processus) sécurisés de tels processus, est la responsabilité de machine virtuelle servant d'hyperviseur. Cette manière de faire assure une isolation matérielle entre les processus exécutés dans chaque domaine d'hôte, avec un mécanisme MAC très précis assuré par l'infrastructure SELinux. Chaque domaine d'hôte est vérifié initialement avant de l'appeler et, une fois que chaque domaine est en ligne, son intégrité est vérifiée par l'infrastructure SELinux.En raison des différences dans les exigences de sécurité au moment du démarrage et pendant l'exécution, tous les appareils embarqués ne nécessiteront probablement pas tous les éléments décrits dans cette approche. Cependant, cela n'indique pas une faiblesse de l'architecture, car les principaux aspects sécurité de l'approche pourraient être réalisés et validés de manière indépendante (ces aspects sont « couplés de manière lâche ».) Sur un système nécessitant et réalisant toutes les fonctions fournies dans cette architecture, une analyse complète doit donc être effectuée pour s'assurer qu'une politique de sécurité appropriée est en place permettant de déployer efficacement les fonctions SELinux. Parce qu'une politique inutilement complète et restrictive pourra diminuer les performances globales et augmentera la mémoire requise par le système.Dans ce cas de figure, l'exécution de l'hyperviseur est essentielle, car cette couche arbitre les interactions entre les processus dans chaque domaine d'hôte. Ainsi, un hyperviseur rapide et très performant est absolument nécessaire pour la réalisation satisfaisante de cette approche.(*) Il existe quelques tentatives de transférer SELinux ou des parties de celui-ci dans un appareil embarqué Arm, la plus importante ayant été effectuée par Russell Coker (www.coker.com.au/russell).I. - A propos de SELinuxSELinux, pour « Security enhanced Linux », a été développé aux Etats-Unis au sein de la NSA (National security agency).Devenu accessible sous forme de code source ouvert à partir de 2000, SELinux est basé sur l'architecture sécurisée Flask, qui signifie « Flux advanced security kernel ». L'objectif de cette architecture logicielle est de gérer de manière souple la politique sécurité et la propagation des droits d'accès.D'un point de vue technique, cette approche utilise la procédure « xattrs » pour les objets balisés et les décisions de sécurité, assure un mécanisme de MAC (Mandatory access control) très précis et réalise l'isolement via la mise en &oelig;uvre des « domaines de sécurité ». Par exemple, les ensembles « autorisations » et « opérations » définissent un domaine de sécurité (Read/Write permission : home_t files est un domaine sécurisé).SELinux permet notamment d'établir une politique de sécurité correcte en définissant les contextes de sécurité (spécification des autorisations d'objet) et les transitions de domaine (exécution d'une opération au nom d'un objet).II. - Des outils pour la gestion de la sécuritéSELinux est un ensemble complexe qui nécessite des outils de mise en &oelig;uvre appropriés. Ces derniers doivent notamment être capables de gérer l'infrastructure SELinux via le développement d'une politique sécurité personnalisée, de débogage et d'analyse de la politique à distance.Certes, SELinux inclut les mécanismes TE et RBAC. TE (Type enforcement) est un mécanisme pour faire appliquer les règles du domaine de sécurité et RBAC (Role-based access control) limite l'accès des utilisateurs aux domaines sécurisés Mais au-delà, il faut aussi disposer de fonctions pour administrer et gérer le Hardware security module (HSM) et le Trusted platform module (TPM). Enfin, les fonctions de refus de dépannage (SEtroubleshooter), de gestion et de définition de la politique (SLIDE), de gestion avancée de la politique (Bedrock) et de l'analyse des politiques (Apol) doivent faire partie de la panoplie des utilitaires à disposition des utilisateurs.III. - Remarques sur le code SELinuxLe code SELinux refuse toute opération par défaut. Il est possible de définir des contraintes et de limiter ce qui est permis par les règles d'autorisation.Par exemple, on peut autoriser l'accès à sysadm_r uniquement à partir du rôle staff_r.Quant au langage de la politique, il est relativement simple d'abord. Ainsi, permettre à sysadm_r, write d'avoir accès à /etc/shadow peut s'écrire : allow sysadm_r shadow_t : file write.On peut signaler aussi que les pénalités pour les performances sont directement proportionnelles au nombre des types et non fonction des objets sous contrôle.

On peut « sécuriser » Linux sur les systèmes embarqués

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

On peut « sécuriser » Linux sur les systèmes embarqués

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure