L'invention se rapporte au domaine général de la sécurisation des programmes informatiques et plus particulièrement à celui de la sécurisation des appels système d'un noyau par les processus d'une pile logicielle s'exécutant dans un espace utilisateur.

Dans ce document, la protection d'un appel système consiste plus particulièrement à protéger les accès (lecture/création/modification/suppression...) aux ressources sensibles du noyau (inodes, fichiers, ...) qui peuvent être déclenchés dans le code de l'appel système depuis l'espace utilisateur par exemple pour gérer les opérations sensibles d'ouverture d'un fichier, d'envoi d'un paquet, de création d'un « inode », ...

Plus précisément, cette protection consiste à vérifier, juste avant l'accès à ces ressources sensibles, si l'accès peut être validé.

L'invention trouve une application privilégiée mais non limitative dans les environnements de type Linux.

Dans l'état actuel de la technique, l'infrastructure LSM (Linux Security Module) est le moyen standard d'améliorer la sécurité d'une pile logicielle dans un environnement Linux, et en particulier l'accès aux ressources sensibles du noyau. Elle permet de mettre en place sous forme de modules de sécurité Linux des politiques de sécurité additionnelles au contrôle d'accès discrétionnaire (Discretionary Access Control - DAC) que sont en particulier :

- le contrôle d'accès obligatoire (Mandatory Access Control - MAC), notamment proposé par le module AppArmor ;

- le contrôle d'accès à base de rôle (Role-Based Access Control - RBAC), notamment proposé par le module SELinux ; et

- le contrôle d'intégrité, notamment proposé par le module IMA.

De façon connue de l'homme du métier, ces politiques sont appliquées au niveau noyau dans des « hooks » (primitives permettant aux modules LSM d'exécuter des « bouts de codes » arbitraires lors d'opérations sensibles (ouverture de fichier, réception de paquet réseau, ...)).

Il existe aujourd'hui des modules LSM qui permettent de définir et d'appliquer des politiques de sécurité différentiées pour différentes piles logicielles en espace utilisateur. Cependant, ces modules sont difficiles à maintenir car ils intègrent à la fois la politique de sécurité elle-même et sa mise en oeuvre. De plus, ces modules LSM appliquent des politiques de sécurité par processus ou par hiérarchie de processus. Dans ce cas, il est possible qu'une élévation de privilège se produise. Par exemple, un processus peut avoir des droits supérieurs à ceux du processus qui a demandé sa création car il hérite des droits du processus qui l'a créé. Ce dernier n'est pas dans la hiérarchie de processus de celui qui a demandé la création lorsque la création de processus se fait à travers un autre processus avec qui le processus demandeur n'a pas de lien de parenté. Dans ce cas, les politiques du processus demandeur ne sont pas appliquées au processus créé, ce qui n'est pas souhaitable sur le plan de la sécurité.

Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.

Plus précisément, et selon un premier aspect, l'invention concerne un procédé de sécurisation d'au moins un appel système déclenché par un processus courant d'un espace utilisateur d'un système logiciel. Ce procédé est mis en oeuvre par un noyau du système logiciel avant d'exécuter au moins une opération déclenchée par ledit au moins un appel système et comporte :

- une étape d'obtention d'au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus courant;

- une étape pour déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone du noyau ;

- une étape d'exécution de la politique de sécurité ; et

- une étape de traitement de l'appel système en fonction d'un résultat de cette exécution.

Ainsi, et d'une façon générale, l'invention propose un mécanisme permettant à un processus ou à un ensemble de processus de l'espace utilisateur de définir ses propres politiques de sécurité à mettre en oeuvre par le noyau.

L'invention trouve une application privilégiée dans l'environnement Linux mais peut être appliquée à tout système d'exploitation offrant un mécanisme d'isolation des ressources par espace de nommage (en anglais « Namespace »). En effet, l'invention propose de définir un nouvel espace de nommage dédié à la gestion de sécurité et de définir les politiques de sécurité dans ces espaces de nommage.

Contrairement aux modules LSM de l'état de la technique, ce mécanisme de sécurisation propose d'associer les politiques de sécurité à un espace de nommage du noyau au lieu d'intégrer la politique au module LSM lui-même. Cette caractéristique permet fort avantageusement de bénéficier de tous les mécanismes de gestion des espaces de nommage du noyau.

Selon un deuxième aspect, l'invention concerne un procédé de mise en place d'une politique de sécurité, ce procédé étant mis en oeuvre par une pile logicielle d'un espace utilisateur d'un système logiciel pour sécuriser au moins un appel système susceptible d'être déclenché par un processus de la pile logicielle. Ce procédé comporte une étape de chargement de la politique de sécurité dans une zone du noyau dudit système, ladite politique de sécurité étant associée à un espace de nommage dédié à la gestion de sécurité associé à une opération susceptible d'être déclenchée par ledit au moins un appel système de ce processus. Ainsi, et de façon très avantageuse, la politique de sécurité peut être chargée par la pile logicielle dans le noyau, y compris quand celle-ci ne bénéficie pas de droits privilégiés d'administration. Cette caractéristique est particulièrement avantageuse car les modules LSMs de l'état actuel de la technique imposent que les politiques soient mises en place par une entité de l'espace utilisateur ayant des droits d'administration.

L'invention vise aussi un dispositif comportant un espace utilisateur et un noyau, l'espace utilisateur comportant au moins un processus apte à déclencher au moins un appel système du noyau. Ce dispositif est caractérisé en ce que :

- le noyau comporte une infrastructure de contrôle de sécurité et un module de sécurité, cette infrastructure étant configurée pour exécuter le module de sécurité avant d'exécuter au moins une opération déclenchée par l'appel système;

- ledit module de sécurité étant configuré pour :

- obtenir au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus;

- déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à l'opération et enregistrée dans une zone dudit noyau ; et

- exécuter ladite au moins une politique de sécurité.

Dans un mode de réalisation, le procédé (ou le dispositif) de sécurisation d'au moins un appel système détermine si l'espace de nommage du processus courant comporte au moins un ancêtre. Si c'est le cas, le procédé (ou le dispositif) met en oeuvre pour chacun de ces espaces de nommage ancêtre, un traitement identique à celui mis en oeuvre pour l'espace de nommage associé au processus courant.

Plus précisément, dans ce mode de réalisation, le procédé comporte :

- une étape d'obtention du ou des espaces de nommage dédié(s) à la gestion de sécurité et ancêtre(s) de l'espace nommage du processus courant ;

- une étape pour déterminer si ce ou ces espace(s) de nommage comporte(nt) une politique de sécurité associée à l'opération et enregistrée dans une zone du noyau ;

- une étape d'exécution de cette politique de sécurité ; et

- une étape de traitement de l'appel système en fonction d'un résultat de cette exécution.

Dans un mode de réalisation du procédé de mise en place d'une politique de sécurité proposé, la pile logicielle est un conteneur et le chargement de la politique de sécurité est défini par une instruction d'un fichier de configuration du conteneur. Ce fichier de configuration peut par exemple être conforme à aux spécifications définies par l'OCI (Open Container Initiative) ou un fichier de type Dockerfile. On rappelle qu'un fichier de type Dockerfile est un fichier texte qui comporte les commandes nécessaires à la génération de l'image d'un conteneur.

De façon particulièrement avantageuse, les politiques de sécurité peuvent être chargées par la pile logicielle ou par le conteneur « à chaud », c'est-à-dire pendant l'exécution du conteneur.

Ainsi, l'opération déclenchée par un appel système du processus courant entraîne l'exécution de la ou les politique(s) de sécurité associée(s) à cette opération dans l'espace de nommage de ce processus, mais aussi dans les espaces de nommage ancêtres de l'espace de nommage de ce processus, s'ils existent.

Ainsi, et en particulier, les processus d'un conteneur héritent des politiques de sécurité définies dans les espaces de nommage ancêtres. Le processus sur lequel la politique de sécurité s'applique ne peut avoir des droits supérieurs à ceux définis par la ou les politiques de sécurité définies dans les espaces de nommage ancêtres.

En ce sens, il peut être dit que le procédé proposé permet d'empiler des politiques de sécurité personnalisées pour les processus d'un espace de nommage.

Dans un mode de réalisation particulier, la pile logicielle ou le conteneur de l'espace utilisateur construit un code exécutable qui contient ses propres politiques de sécurité applicables à des opérations particulières (ouverture de fichier, réception de paquet réseau, ...). Ce code peut être chargé à l'exécution (c'est-à-dire dynamiquement) à travers une interface système vers le noyau. Il est alors exécuté par le noyau quand ces opérations (ou événements) se produisent pour un processus appartenant à ce conteneur. Puisque ce code n'est pas forcément exécuté par un processus de confiance (potentiellement malveillant), il ne doit pas être en mesure d'interférer avec le reste du système ou le noyau. Ainsi, les politiques de sécurité ne sont appliquées que si elles se réfèrent bien au conteneur à l'origine de la politique applicable à l'évènement.

De façon avantageuse, puisqu'il est possible qu'une pile logicielle soit compromise, une politique de sécurité ne peut pas être désactivée ou modifiée depuis l'espace utilisateur, en particulier par une pile logicielle ou un conteneur appartenant à un espace de nommage pour lequel cette politique a été définie.

Dans un mode de réalisation particulier, le procédé de sécurisation proposé comporte une étape de suppression d'au moins une politique de sécurité par le noyau si cette politique de sécurité n'est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif de l'espace utilisateur.

Dans un mode de réalisation particulier, le procédé de sécurisation proposé comporte une étape pour déterminer si l'appel système est associé à une opération sensible et le procédé de sécurisation n'est mis en oeuvre que pour les opérations sensibles (ouverture de fichier, envoi de paquet, exécution d'une fonction, ...). Cette détermination peut notamment être effectuée par le gestionnaire d'appels système du noyau. Dans un mode de réalisation du procédé de sécurisation proposé, l'étape de traitement consiste à exécuter l'opération si le résultat de l'exécution de ladite au moins une politique de sécurité ne détecte aucun problème de sécurité et à déclencher une action de sécurité si le résultat de l'exécution de ladite au moins une dite politique de sécurité détecte au moins un problème de sécurité.

Dans un mode de réalisation du procédé de sécurisation proposé, l'action de sécurité comporte la destruction du processus courant.

Dans un mode de réalisation du procédé de sécurisation proposé, une politique de sécurité est un fichier en langage binaire obtenu par compilation d'un programme en langage eBPF (pour « Extended Berkeley Packet Filter »).

De façon connue, ce langage est volontairement limité en termes de fonctionnalités (pas de boucle, pas d'arithmétique de pointeur, pas d'accès direct aux structures noyau, ...) mais possède de fortes propriétés de sécurité de sorte qu'il est inapte à attaquer le reste du système.

Cette caractéristique permet avantageusement d'empêcher les attaques critiques, par exemple pour récupérer des informations, modifier l'intégrité ou la disponibilité du reste du système.

La technique proposée permet ainsi à une pile logicielle de mettre en place des politiques de sécurité sans compromettre la sécurité du système. Elle permet en particulier l'application de politiques durcies après l'initialisation de la pile logicielle pour bloquer ultérieurement des comportements qui ne seraient acceptables qu'à l'initialisation.

Les possibilités offertes par le langage eBPF étant limitées, dans un mode de réalisation du procédé de mise en place d'une politique de sécurité proposé, au moins une politique de sécurité appelle au moins une fonction de support externe à cette politique et chargée dans une zone dédiée du noyau par une entité de l'espace utilisateur bénéficiant de droits d'administration.

Ces fonctions de support (en anglais « helpers ») peuvent être chargées « à chaud », c'est à dire pendant l'exécution du noyau. Elles peuvent être appelées par une politique de sécurité eBPF pour réaliser des traitements critiques comme les accès aux structures noyau pour le code eBPF. Ces fonctions support ne peuvent être écrites que par une entité bénéficiant de droits d'administration et ne sont pas soumises aux limitations liées au vérifieur eBPF.

Ce mode de réalisation particulier permet, en déportant les accès critiques et les traitements complexes vers les fonctions support, la mise en place par les conteneurs de politiques élaborées sans compromettre la sécurité du système et avec des surcoûts en performance faibles.

Dans un mode de réalisation particulier, au moins une fonction de support est une fonction dynamique exécutable indépendamment de sa position, cette fonction dynamique étant appelée par une fonction de support statique compilée avec le noyau et appelée par la politique de sécurité. Pour plus de renseignements sur la notion de code indépendant de sa position (en anglais « position independent code »), l'homme du métier peut se reporter au document disponible à l'adresse https://fr.qwe.wiki/wiki/Position-independent_code.

Dans un mode de réalisation particulier, le procédé de mise en place d'une politique de sécurité proposé comporte une étape d'analyse d'un fichier journal (plus connu sous le terme logs) comportant au moins un résultat d'exécution d'une politique de sécurité exécutée par un procédé de sécurisation tel que mentionné ci-dessus.

Le procédé de sécurisation et le procédé de mise en place d'une politique de sécurité proposés sont mis en oeuvre par des programmes d'ordinateur.

Par conséquent, l'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un dispositif ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en oeuvre d'un procédé tel que décrit ci-dessus.

Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.

L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.

D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.

Le programme d'ordinateur proposé peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés tels que décrits précédemment.

D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente un dispositif conforme à un mode particulier de réalisation et les principales étapes d'un procédé de mise en place d'une politique de sécurité conforme à un mode particulier de réalisation ;

- la figure 2 représente une table de processus pouvant être utilisée dans un mode particulier de réalisation ;

- la figure 3 représente une table de contrôle pouvant être utilisée dans un mode particulier de réalisation ;

- la figure 4 représente sous forme d'ordinogramme les principales étapes d'un procédé de sécurisation conforme à un mode particulier de réalisation.

La figure 1 représente un dispositif 100 conforme à l'invention. Dans l'exemple de réalisation décrit ici, ce dispositif 100 a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, et des moyens de communication 13.

Ce dispositif comporte un système logiciel SYS, ce système comportant un noyau ou système d'exploitation KER, et un espace utilisateur USR. Dans le mode de réalisation décrit ici, le système d'exploitation KER est de type Linux (marque déposée).

Dans le mode de réalisation décrit ici, l'espace utilisateur USR comporte un processus p0(), deux piles logicielles de type conteneur Cl, C2 et un outil d'administration ADM. Le processus p0() et les piles logicielles Cl, C2 sont associées à des droits de niveau utilisateur et l'outil d'administration ADM à des droits de niveau administrateur.

Dans l'exemple de réalisation décrit ici, les piles logicielles Cl, C2 de l'espace utilisateur USR sont des conteneurs, chacun comportant un ensemble de processus isolés du reste du système logiciel SYS.

Dans cet exemple, la création des conteneurs Cl et C2 est demandée par le processus p0().

On rappelle que les processus de l'espace utilisateur USR peuvent être isolés grâce au mécanisme connu d'espaces de nommage. De façon connue, le système d'exploitation Linux propose dans l'état actuel de la technique, plusieurs espaces de nommage (par exemple : Network, IPC, PID, User)... qui peuvent être utilisés pour isoler des processus dans un mécanisme dans lequel on définit des ensembles de processus, de sorte que les processus d'un ensemble donné ne puissent pas voir les ressources utilisées par un autre ensemble de processus.

Dans l'exemple de la figure 1:

- le processus pO est associé respectivement à des espaces de nommage ENNETWORKO (pour l'espace Network), ENIPC0 (pour IPC), ENPID0 (pour PID), ENUserO (pour User) ... ;

- les processus du conteneur Cl, en l'occurrence le processus pl(), sont associés à des espaces de nommage différents ENNETWORK1, ENIPC1, ENIPD1, ENUserl; et - les processus du conteneur C2, en l'occurrence le processus p2(), sont associés à des espaces de nommage différents ENNETWORK2, ENIPC2, ENIPD2, ENUser2.

Certains processus du système SYS peuvent faire appel à des fonctions système du noyau KER. Le noyau KER comporte un gestionnaire d'appel système GAS dans lequel sont implémentés ces appels système.

L'invention propose un mécanisme de gestion de sécurité pour sécuriser les appels système déclenchant des opérations sensibles au sens des Modules de Sécurité Linux (LSM).

Dans le mode de réalisation décrit ici, on considère que les opérations oper_open() d'ouverture de fichier, oper_send() d'envoi de paquets et oper_exec() d'exécution de fonction sont des opérations sensibles.

Dans l'exemple de la figure 1 le processus pl du conteneur Cl et le processus p2 du conteneur C2 appellent :

- l'appel système open() d'ouverture de fichier qui génère lors de son exécution, l'opération sensible oper_open(); et

- l'appel système send() d'envoi de paquets qui génère lors de son exécution, l'opération sensible oper_send().

Dans l'exemple de la figure 1, le processus pO ne fait pas appel aux appels système open() send(), exec().

Dans le mode de réalisation décrit ici, l'invention propose d'utiliser un nouvel espace de nommage ENSECURE dédié à la gestion de la sécurité.

Par exemple, le processus pO est associé à l'espace de nommage de gestion de la sécurité ENSECUREO, le conteneur Cl est associé à l'espace de nommage de gestion de la sécurité ENSECURE1 et le conteneur C2 est associé à l'espace de nommage ENSECURE2.

La figure 2 représente en détail une table TABPID des processus pO, pl et p2 mémorisée dans le noyau KER. Dans le noyau KER, un processus est constitué d'une structure comportant plusieurs champs permettant de gérer le cycle de vie du processus comme son identifiant de processus PID, ses drapeaux (flags en anglais), sa pile ...

Dans l'espace noyau, on peut récupérer la structure de données correspondant au processus courant à l'aide de l'instruction current (voir étape E30, figure 4).

Cette structure comporte également un champ nsproxy qui comporte des pointeurs vers les espaces de nommage. Conformément à ce mode de réalisation particulier, ce champ nsproxy comporte un pointeur ENSECURE vers l'espace de nommage dédié à la gestion de la sécurité associé au processus. Cet espace de nommage définit une structure de données qui comprend notamment la politique de sécurité définie en langage eBPF. Dans le mode de réalisation décrit ici, ces structures sont enregistrées dans une zone de politiques de sécurité ZPS du noyau KER. L'espace de nommage ENSECURE d'un processus comporte un lien vers l'espace de nommage ENSECURE du parent de l'espace de nommage de ce processus. Dans l'exemple décrit ici, ENSECURE1 et ENSECURE2 associés respectivement aux conteneurs Cl et C2 pointent vers l'espace de nommage ENSECUREO du processus pO.

Les espaces de nommage ENSECURE forment donc un arbre.

De façon connue de l'homme du métier un processus peut changer d'espace de nommage pour rejoindre l'espace de nommage d'un de ses processus fils, par exemple en utilisant la commande unshare().

Depuis l'espace utilisateur USR, il est possible d'accéder à l'identifiant d'un espace de nommage mais il n'est pas possible de modifier sa structure. Cette caractéristique permet avantageusement d'empêcher toute modification ou désactivation d'une politique de sécurité par un conteneur.

Dans l'exemple de réalisation décrit ici, on suppose que le processus p0() a défini une politique de sécurité PSOFpO pour sécuriser les appels à l'opération sensible d'ouverture de fichier oper_open(). On suppose qu'il n'a pas défini de politique de sécurité pour sécuriser les appels à l'opération sensible d'envoi de paquet sur le réseau oper_send().

Dans le mode de réalisation décrit ici, les processus d'un conteneur héritent des politiques de sécurité définies par tous ses espaces de nommage ENSECURE ancêtres.

Dans l'exemple de réalisation décrit ici, on suppose que le conteneur Cl a défini sa propre politique de sécurité PSOFC1 pour sécuriser les appels par ses processus, en l'occurrence pl(), à l'opération sensible d'ouverture de fichier oper_open(), en complément de la politique PSOFpO définie par le processus p0().

On suppose que le conteneur Cl a défini une politique de sécurité PSTPC1 pour sécuriser les appels par ses processus, en l'occurrence pl(), à l'opération sensible d'envoi de paquet oper_send().

On suppose que le conteneur C2 n'a défini aucune politique de sécurité propre. Le processus p2() de ce conteneur hérite de la politique de sécurité PSOFpO définie par le processus p0() pour sécuriser ses appels à l'opération sensible d'ouverture de fichier. Mais il ne définit aucune fonction de sécurité pour vérifier l'opération sensible d'envoi de paquet.

Dans le mode de réalisation décrit ici, chacune des politiques de sécurité PSOFpO, PSOFC1, PSTPC1 est définie par une fonction logicielle en langage eBPF compilée en binaire. Ces politiques de sécurité sont enregistrées dans la mémoire morte 12 du dispositif 100 et destinées à être chargées dans la zone ZPS de politiques de sécurité du noyau KER.

Ce chargement (étape F10) peut se faire de différentes façons.

Dans le mode de réalisation décrit ici, la mémoire morte 12 comporte un fichier de configuration de type OCI (Open Container Initiative) pour chaque conteneur, à savoir un fichier de configuration FOCIC1 pour le conteneur Cl et un fichier de configuration FOCIC2 pour le conteneur C2. De façon connue, la configuration OCI d'un conteneur est spécifiée sous le nom config.json et détaille les caractéristiques du conteneur à créer. Ce fichier de configuration précise notamment les fichiers que doit contenir le conteneur, ses interfaces système, ses espaces de nommage, ...

Dans le mode de réalisation décrit ici, le fichier de configuration OCI d'un conteneur comporte des instructions pour que le conteneur charge ses politiques de sécurité dans la zone ZPS de politiques de sécurité du noyau KER.

Quand un conteneur est créé, par exemple Cl, les politiques de sécurité PSOFC1 et PCTPC1 du conteneur Cl sont copiées de la mémoire morte 12 dans une mémoire Ml du conteneur Cl. Une fois que le conteneur Cl est construit, il est exécuté et à l'exécution, les politiques de sécurité sont transférées de la mémoire Ml, dans la zone ZPS du noyau.

L'écriture manuelle de fichier de configuration OCI peut néanmoins s'avérer complexe, et dans un autre mode de réalisation de l'invention, le chargement de la politique de sécurité d'un conteneur dans le noyau KER est définie par une instruction d'une méthode de construction de conteneur de plus haut niveau, par exemple de la méthode Dockerfile.

Par ailleurs, le chargement d'une politique de sécurité propre à un conteneur dans la mémoire du noyau peut être effectué à tout moment du cycle de vie du conteneur, pas seulement à son initialisation. Dans le mode de réalisation décrit ici, le code du conteneur Cl comporte également des instructions load_ps() permettant de charger une politique de sécurité sous forme d'un fichier eBPF compilé sous forme binaire dans la zone ZPS de politiques de sécurité du noyau KER. Ce mode de réalisation particulier permet en particulier de charger une nouvelle politique de sécurité qui va être appliquée après le démarrage du conteneur Cl. Cette fonction load_ps() consiste à ouvrir le fichier eBPF compris dans la mémoire morte 12 et à le copier vers une interface avec le noyau KER.

Dans le mode de réalisation décrit ici, le noyau KER comporte une infrastructure de contrôle de sécurité ICS de gestion des Modules de sécurité Linux, un module de sécurité Linux LSM1 conforme à l'invention et éventuellement au moins un autre module de sécurité LSM2, par exemple, un module SELinux ou un module AppAmor tels que mentionnés précédemment.

Dans l'exemple de réalisation décrit ici, le noyau KER comporte une table de contrôle TABCTR qui définit, pour chaque opération sensible OPS (ouverture de fichier, envoi de paquet sur le réseau, ...) si le module de sécurité LSM1 veut contrôler ou non ces opérations sensibles. Cette table TABCTR est représentée à la figure 3.

Dans l'exemple de vérification décrit ici, on suppose que le module de sécurité LSM1 ne souhaite vérifier que l'opération sensible d'ouverture de fichiers.

La figure 4 représente sous forme d'ordinogramme les principales étapes d'un procédé de sécurisation conforme à un mode particulier de réalisation. Dans le mode de réalisation décrit ici, ce procédé est mis en oeuvre par le gestionnaire d'appel système GAS, l'infrastructure de contrôle de sécurité ICS (en anglais framework LSM) et par le module de sécurité LSM1. Dans l'exemple de réalisation décrit ici, le gestionnaire d'appel système GAS détermine, au cours d'une étape E10, si un appel système déclenché par un processus de l'espace utilisateur doit réaliser une opération sensible. Si c'est le cas, il déclenche l'infrastructure de contrôle de sécurité ICS du noyau KER.

Si l'infrastructure ICS détermine que l'opération sensible OPS répertoriée dans la table TABCTR est supervisée par le module de sécurité LSM1, l'infrastructure ICS déclenche l'exécution du module de sécurité LSM1 au cours d'une étape E20.

Dans l'exemple de réalisation décrit ici, si un processus souhaite réaliser l'opération sensible envoyer un paquet (oper_send()) ou exécuter un nouveau processus en espace utilisateur (oper_exec()) par appel à la fonction exec(), comme ces opérations sensibles ne sont pas vérifiées par le module de sécurité LSM1, le résultat de l'étape de détermination est négatif. Ces opérations peuvent néanmoins être vérifiées par le module de sécurité LSM2, hors contexte de l'invention, par exemple SELinux et un module AppAmor.

Au cours d'une étape E30, le module de sécurité LSM1 détermine l'espace de nommage associé au processus courant à l'origine de cet appel. Il utilise pour cela le processus courant de la table des processus TABPID.

Le module de sécurité LSM1 exécute ensuite une boucle pour exécuter les politiques de l'espace de nommage du processus courant liées à cette opération sensible. Dans un mode de réalisation particulier, le module de sécurité LSM1 exécute ensuite une boucle pour exécuter les politiques de ses espaces de nommage ancêtres s'ils existent.

Au cours d'une étape E40 le module de sécurité LSM1 détermine si l'espace de nommage courant a défini une ou plusieurs politiques de sécurité pour vérifier la validité de l'opération sensible.

Si tel est le cas, le module de sécurité concerné LSM1 exécute au cours d'une étape E50 la ou les politiques de sécurité définies dans l'espace de nommage dédié à la gestion de sécurité ENSECURE du processus courant pour cette opération sensible.

En l'espèce, au cours de la première itération, la politique de sécurité PSOFC1 est exécutée. Cette politique de sécurité renvoie un résultat RET de cette exécution au module de sécurité LSM1.

Dans le mode de réalisation décrit ici, une politique de sécurité, et en particulier la politique de sécurité PSOFC1, renvoie un résultat RET négatif si elle détecte un problème de sécurité (traduisant par exemple un comportement malveillant ou anormal) et un résultat positif si elle ne détecte aucun problème de sécurité.

Si cette valeur RET est positive, le module de sécurité détermine, s'il existe, l'espace de nommage parent de l'espace de nommage du processus courant (étape E60) et la boucle se répète.

En l'espèce, au cours de la deuxième itération la politique de sécurité PSOFpO de l'espace de nommage ENSECUREO du processus pO est exécutée. Si une politique de sécurité renvoie un résultat RET négatif, le module de sécurité enregistre ce résultat dans un fichier de log FLOG du noyau KER au cours d'une étape E70 et envoie ce résultat négatif RET à l'infrastructure de sécurité ICS. Ce fichier de log FLOG peut être analysé (étape F30) par l'administrateur au moyen de l'outil d'administration ADM.

Lorsque toutes les politiques de sécurité de toute l'arborescence d'espaces de nommages ont été exécutées avec un résultat RET positif, le module de sécurité LSM1 envoie un résultat positif RET à l'infrastructure de sécurité ICS (test E90).

Dans le mode de réalisation décrit ici, si l'infrastructure de sécurité RET reçoit un résultat RET positif, elle ne déclenche pas d'action particulière et l'appel système est exécuté, sauf si une action est déclenchée par un autre module de sécurité LSM2, par exemple, un module SELinux et un module AppAmor.

Dans le mode de réalisation décrit ici, si l'infrastructure de sécurité RET reçoit un résultat RET négatif, l'infrastructure de contrôle ICS déclenche une action de sécurité AS au cours d'une étape E80. Cette action peut consister à détruire le processus à l'origine de l'appel et à lever une alerte dans le fichier de log FLOG.

Dans le mode de réalisation décrit ici, lorsqu'aucun processus ne reste dans un espace de nommage dédié à la gestion de sécurité, cet espace de nommage est détruit automatiquement par le noyau. Cette opération détruit les politiques de sécurité associées à ces espaces de nommage.

Par exemple, dans l'exemple de réalisation décrit ici, dès lors que le processus pl meurt, il n'y a plus dans le système SYS de processus dont l'espace de nommage dédié à la gestion de sécurité est ENSECURE1 si bien que les politiques de sécurité PSOFC1 et PSTPC1 peuvent être détruites.

Dans le mode de réalisation décrit ici, si une politique de sécurité n'est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif de l'espace utilisateur, cette politique de sécurité est supprimée par le noyau.

Conformément à l'invention, les politiques de sécurité en langage eBPF compilé peuvent appeler des fonctions du noyau KER externes à ces politiques, pour mettre en oeuvre des opérations critiques qui ne peuvent pas l'être directement par la politique de sécurité en langage eBPF elle-même. De telles fonctions sont connues de l'homme du métier sous le nom de fonctions de support eBPF (en anglais « Helper eBPF »).

Dans un mode particulier de mise en oeuvre de l'invention, une telle fonction de support FSUP peut être écrite par un administrateur, par exemple en langage C, puis compilée comme un module noyau classique avec GCC (en anglais « GNU Compiler Collection »).

Dans le mode de réalisation décrit ici, ce code exécutable est transformé pour pouvoir être exécuté indépendamment de sa position selon le mécanisme PIC (Position Independent Code) connu de l'homme du métier. Ces fonctions de support FSUP dynamiques peuvent être chargées (étape F20) dans une zone dédiée du noyau KER sans interrompre l'exécution du noyau.

Une fois chargées dans le noyau, ces fonctions de support dynamiques FSUP peuvent être appelées par le code eBPF d'une politique de sécurité à l'aide d'une unique fonction de support statique FSUPSTAT.