Brevet FR3120455A1 — publié le 20220909

Procédé et module d’installation d’un programme de mitigation dans le noyau d’un équipement informatique. Ce procédé installe un programme de mitigation (PG k ) dans le noyau (KER) d’un équipement informatique (EQ) pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger (F1) s’exécutant dans un espace utilisateur (USR) de cet équipement informatique (EQ). Il comporte : - une étape (F10) d’envoi d’une requête (REQ) comportant un identifiant unique (ID CVEk ) de ladite vulnérabilité à un serveur de sécurisation (SRV SEC ) ; - une étape (F20) d’obtention, en réponse à la requête (REQ) d’un fichier (ID Fk ) de description dudit programme (PG k ) ; - une étape (F40, F50) d’obtention d’un code objet (PG O k ) du programme de mitigation (PG k ) identifié dans ledit fichier de description (ID Fk ) ; - une étape (F60) d’édition de lien pour résoudre au moins un symbole d’un code objet (PG O k ) afin de générer un code exécutable (PG E k ) dudit programme de mitigation (PG k ) spécifique audit équipement (EQ) ; et - une étape (F70) d’installation du code exécutable (PG E K ) dans le noyau (KER) dudit équipement, ledit équipement (EQ) comportant des moyens pour s’assurer que ledit programme de mitigation ne mitige ladite vulnérabilité que pour ladite fonction à protéger (F1). Fig. 2 Procédé et module d’installation d’un programme de mitigation dans le noyau d’un équipement informatique. L’invention se rapporte au domaine général de la sécurisation des logiciels informatiques. L’invention vise plus particulièrement un procédé pour installer, dans le noyau d’un équipement informatique, un programme configuré pour mitiger une vulnérabilité donnée susceptible d’affecter le comportement d’un logiciel s’exécutant dans l’espace utilisateur de cet équipement. On rappelle que lorsqu’un logiciel présente une vulnérabilité, la mitigation ne vise pas à corriger ce logiciel qui continue à s’exécuter normalement, mais à bloquer les effets de la vulnérabilité. Par exemple, si un logiciel présente une faille de sécurité lorsqu’il fait un appel système à une fonction d’envoi de paquets, une mitigation de cette vulnérabilité peut consister à bloquer le processus d’envoi de paquets. La mitigation ne supprime pas la vulnérabilité mais elle la rend inexploitable. Dans le domaine de la sécurité informatique, les failles de sécurité sont répertoriées dans une liste publique accessible à l’adresse https://cve.mitre.org/, chaque vulnérabilité référencée dans la liste étant identifiée par un identifiant unique CVE (pour Common Vulnerabilities and Exposures en anglais). Des milliers d’identifiants CVE sont émis chaque année, et un logiciel complexe peut cumuler des centaines de CVE. La gestion des CVE pour maintenir la sécurité d’un équipement informatique peut donc s’avérer excessivement complexe. L’invention vise à faciliter l’installation d’un programme dans le noyau d’un équipement informatique pour mitiger une vulnérabilité impactant un logiciel s’exécutant sur cet équipement et réalisant une fonction à protéger. Plus précisément, et selon un premier aspect, l’invention concerne un procédé d’installation d’un programme de mitigation dans le noyau d’un équipement informatique pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger s’exécutant dans un espace utilisateur dudit équipement informatique, ce procédé comportant : - une étape d’envoi d’une requête comportant un identifiant unique de ladite vulnérabilité à un serveur de sécurisation ; - une étape d’obtention, en réponse à la requête, d’un fichier de description dudit programme ; - une étape d’obtention d’un code objet du programme de mitigation identifié dans ledit fichier de description ; - une étape d’édition de lien pour résoudre au moins un symbole du code objet afin de générer un code exécutable du programme de mitigation spécifique audit équipement ; et - une étape d’installation du code exécutable dans le noyau dudit équipement, ledit équipement comportant des moyens pour assurer que ledit programme de mitigation ne mitige ladite vulnérabilité que pour ladite fonction à protéger. Corrélativement, l’invention concerne un module d’installation d’un programme de mitigation dans le noyau d’un équipement informatique pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger s’exécutant dans un espace utilisateur dudit équipement informatique, ce module comportant : - un sous-module d’envoi d’une requête comportant un identifiant unique de ladite vulnérabilité à un serveur de sécurisation ; - un sous-module d’obtention, en réponse à la requête d’un fichier de description dudit programme ; - un sous-module d’obtention d’un code objet du programme de mitigation identifié dans ledit fichier de description ; - un sous-module d’édition de lien pour résoudre au moins un symbole du code objet afin de générer un code exécutable du programme de mitigation spécifique audit équipement ; et - un sous-module d’installation du code exécutable dans le noyau dudit équipement, ledit équipement comportant des moyens pour assurer que ledit programme de mitigation ne mitige ladite vulnérabilité que pour ladite fonction à protéger. Ainsi, en premier lieu, l’invention propose un mécanisme de distribution de programmes de mitigation destinés à être installés dans les noyaux d’équipements informatiques. En ce sens, le serveur de sécurisation proposé par l’invention peut être considéré comme une plateforme de distribution (en anglais « store ») de programmes de mitigation. Il est important de noter que le programme de mitigation est chargé dans le noyau et non pas dans un module noyau, à savoir un module isolé du noyau, et dédié à des fonctions spécifiques. Il n’est pas nécessaire de redémarrer le noyau pour que le programme de mitigation soit effectif. Conformément à l’invention, le programme de mitigation chargé dans le noyau est un programme exécutable. Il ne s’agit pas d’une simple signature ou d’un simple ensemble de règles. De façon très avantageuse, l’invention propose de télécharger le programme de mitigation approprié lorsqu’une vulnérabilité affectant un logiciel s’exécutant sur l’équipement informatique a été détectée, et d’installer automatiquement ce programme dans le noyau de l’équipement pour mitiger cette vulnérabilité pour le logiciel concerné, et uniquement pour celui-ci. De façon connue de l’homme du métier, un programme de mitigation est un exemple de politique de sécurité particulier traitant des corrections de mitigation. De façon très avantageuse, le programme de mitigation peut être chargé sans droit privilégié d’administration. Cette caractéristique est particulièrement avantageuse car les modules LSMs (pour « Linux Security Module ») imposent que les politiques de sécurité soient mises en place par une entité de l’espace utilisateur ayant des droits d’administration. De façon particulièrement avantageuse, les programmes de mitigation peuvent être chargés y compris « à chaud », c’est-à-dire pendant l’exécution du logiciel vulnérable. Dans un mode particulier de réalisation, le procédé d’installation selon l’invention comporte : - une étape de téléchargement d’un code source dudit programme de mitigation à partir d’une adresse comprise dans ledit fichier de description ; et - une étape de compilation dudit code source pour obtenir ledit code objet. Dans un mode particulier de réalisation, le code source est 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 la mise en place de programmes de mitigation sans compromettre la sécurité du système, y compris après l’initialisation du logiciel réalisant la fonction à protéger. Ceci permet de bloquer, après l’initialisation du logiciel à protéger, des comportements qu’il est nécessaire d’autoriser pour l’initialisation du logiciel. Dans un mode particulier de réalisation, le procédé d’installation comporte une étape de téléchargement dudit code objet à partir d’une adresse comprise dans ledit fichier de description. Dans un mode particulier de réalisation, le fichier de description du programme de mitigation comporte l’identifiant d’au moins une fonction de support pouvant être appelée par le programme de mitigation lorsqu’il est exécuté par un processeur dudit équipement. Ce mode de réalisation permet de palier les limitations intrinsèques du langage eBPF. 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, et en particulier par un programme de mitigation, pour réaliser des traitements critiques comme les accès aux structures noyau pour le code eBPF. Elles sont externes aux programmes de mitigation et doivent être chargées dans le noyau par une entité de l’espace utilisateur bénéficiant de droits d’administration. 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 de politiques élaborées sans compromettre la sécurité du système et avec des surcoûts en performance faibles. Dans un mode particulier de réalisation, le procédé d’installation comporte, avant ladite étape d’édition de lien, une étape de vérification que ladite au moins une fonction de support est installée dans ledit noyau. Dans un mode particulier de réalisation, cette étape de vérification comporte la vérification d’un haché de ladite fonction de support compris dans ledit fichier de description. Ce mode de réalisation permet de s’assurer, avant l’installation du programme de mitigation dans le noyau, que toutes les fonctions de support nécessaires sont bien présentes. Cela évite d’installer des programmes de mitigation inopérants et renforce encore le mécanisme de sécurisation. Dans un mode particulier de réalisation, le code source du programme de mitigation comporte une fonction statique pour appeler ladite fonction de support, l’appel à ladite fonction statique étant remplacé par un appel à une fonction dynamique au cours de ladite étape d’édition de lien. Dans un mode particulier de réalisation, ladite étape d’édition de lien utilise un fichier d’en-tête configuré pour permettre la substitution d’un identifiant unique obtenu à partir de l’identifiant de la fonction de support par un index représentatif de l’emplacement de la fonction de support dans le noyau de l’équipement. Dans un mode particulier de réalisation, cet identifiant unique comporte un haché de la fonction de support. Dans un mode particulier de réalisation, le procédé d’installation comporte : - une étape d’enregistrement dudit programme de mitigation en tant que politique de sécurité dans un espace de nommage du noyau dédié à la gestion de la sécurité, cet espace de nommage étant associé à au moins un processus de la fonction à protéger, et - ledit noyau met en œuvre un procédé de sécurisation pour sécuriser un appel système déclenché par un processus courant dudit espace utilisateur avant d’exécuter au moins une opération, typiquement une opération LSM (Linux Security Module) déclenchée par ledit au moins un appel système, ledit procédé de sécurisation comportant : - une étape d’obtention d’au moins un espace de nommage du noyau dédié à la gestion de sécurité associé audit processus courant ; - une étape pour déterminer si ledit au moins un espace de nommage comporte une politique de sécurité ; et - une étape d’exécution de ladite politique de sécurité. Corrélativement, l’invention concerne un équipement comportant un espace utilisateur, un noyau et un module tel que mentionné précédemment pour installer un programme de mitigation dans le noyau pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger s’exécutant dans l’espace utilisateur, cet équipement comportant : - un module d’enregistrement dudit programme de mitigation en tant que politique de sécurité dans un espace de nommage du noyau dédié à la gestion de sécurité, cet espace de nommage étant associé à au moins un processus de ladite fonction à protéger ; - des moyens dudit noyau pour sécuriser au moins un appel système déclenché par un processus courant dudit espace utilisateur avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système, lesdits moyens étant configurés pour : - obtenir au moins un espace de nommage du noyau dédié à la gestion de sécurité associé audit processus courant ; - déterminer si ledit au moins un espace de nommage comporte une politique de sécurité ; et - exécuter ladite politique de sécurité. La protection d’un appel système peut plus particulièrement consister à 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 », ... Ce mode de réalisation de 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 »). 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. Dans ce mode de réalisation, le programme de mitigation est associé à un espace de nommage dédié à la gestion de la sécurité associé à une opération susceptible d’être déclenchée par un appel système d’un processus de la fonction logicielle vulnérable. Dans un mode de réalisation de l’invention, 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 programme de mitigation avant d’exécuter au moins une opération déclenchée par l’appel système. Dans un mode de réalisation, le procédé de sécurisation 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 œuvre pour chacun de ces espaces de nommage ancêtres, un traitement identique à celui mis en œuvre 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 de 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. De façon avantageuse, un programme de mitigation ne peut pas être désactivé ou modifié 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. Le procédé d’installation est mis en œuvre par un programme 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 œuvre dans un équipement informatique ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre 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 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 selon l'invention 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 représente un système comportant un module d’installation conforme à un mode particulier de réalisation ; la représente sous forme d’ordinogramme les principales étapes d’un procédé d’installation conforme à un mode particulier de réalisation de l’invention ; la représente un fichier de description d’un programme de mitigation pouvant être utilisé dans un mode particulier de réalisation ; la représente un fichier d’en-tête pouvant être utilisé dans un mode particulier de réalisation ; la représente une table de processus pouvant être utilisée dans un mode particulier de réalisation ; la représente une table de contrôle pouvant être utilisée dans un mode particulier de réalisation de l’invention ; la représente sous forme d’ordinogramme les principales étapes d’un procédé de sécurisation pouvant être mis en œuvre dans un mode particulier de réalisation ; et la représente l’architecture fonctionnelle d’un module d’installation conforme à un mode particulier de réalisation de l’invention. Description détaillée de plusieurs modes de réalisation particuliers La représente un équipement informatique EQ d’un utilisateur, par exemple un serveur. Dans l’exemple de réalisation décrit ici, cet équipement EQ 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, des moyens de communication 13 et une mémoire réinscriptible non volatile, par exemple un disque dur 14. L’équipement EQ est configuré pour pouvoir communiquer avec un serveur de sécurisation SERV SEC via un réseau de communication NET. Ce serveur de sécurisation SERV SEC comporte une base de données BD comportant un ensemble d’identifiants CVE de vulnérabilités et en association avec chacun de ces identifiants de vulnérabilité ID CVEi , l’identifiant ID Fi d’un fichier de description d’un programme PG i configuré pour s’exécuter dans le noyau (en anglais « kernel ») d’un équipement et pour mettre en œuvre une politique de sécurité apte à mitiger la vulnérabilité d’identifiant ID CVEi . Pour plus de simplicité, les programmes PG i sont ci-après appelés « programmes de mitigation PG i » ou « programmes de mitigation de la vulnérabilité ID CVEi ». Les programmes de mitigation PG i peuvent être téléchargés par l’équipement EQ auprès du serveur de sécurisation SERV SEC . Un identifiant ID CVEi de vulnérabilité est par exemple de la forme CVE-AAAA-IIII, où AAAA est l'année de publication et IIII un numéro unique. Dans le mode de réalisation décrit ici, les programmes de mitigation PG i téléchargeables auprès du serveur de sécurisation SERV SEC sont des fichiers sources en langage eBPF, notés PG S i . Dans un autre mode de réalisation décrit ici, les programmes de mitigation PG i téléchargeables auprès du serveur de sécurisation SERV SEC sont des fichiers objets notés PG O i obtenus par compilation de fichiers sources PG S i en langage eBPF. Dans le mode de réalisation décrit ici, les fichiers de description sont au format JSON (en anglais « Java Script Object Notation »). Dans l’exemple de réalisation décrit ici, le fichier de description ID Fi d’un programme de mitigation PGi comporte : - dans un champ « ID VUL », l’identifiant ID CVEi de la vulnérabilité que ce programme peut mitiger ; et - dans une structure « META_PG » des métadonnées du programme de mitigation PG i . Dans le mode de réalisation décrit ici, les métadonnées du programme de mitigation PG i comportent : - une métadonnée « NP » correspondant au nom de ce programme PG ; et - au moins une métadonnée « HK » correspondant à un point de déclenchement (en anglais « hook ») de ce programme. Dans le mode de réalisation décrit ici, un programme de mitigation PG i peut faire appel à au moins une fonction de support (ou dépendance, en anglais « helper ») HLP i,j . Dans l’exemple de réalisation décrit ici, lorsqu’un programme PG i fait appel à au moins une fonction de support HLP i,j : - le fichier de description ID Fi comporte, dans une structure « META_HLP » des métadonnées de cette fonction de support HLP i,j ; et - ces fonctions de support HLP i,j peuvent être téléchargées auprès du serveur de sécurisation SERV SEC. Dans le mode de réalisation décrit ici, les métadonnées META_HLP d’une fonction de support HLP i,j comportent : - une métadonnée « NH » correspondant au nom de cette fonction de support ; - une métadonnée « HSH » correspondant à un haché de cette fonction de support ; et - une métadonnée « EP » correspondant à un point d’entrée de la fonction. L’équipement EQ 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). L’espace utilisateur USR comporte un module d’installation MINST conforme à l’invention. Ce module d’installation est configuré pour mettre en œuvre un procédé d’installation conforme à l’invention et dont les principales étapes sont représentées sous forme d’ordinogramme à la . Dans l’exemple décrit ici, l’espace utilisateur USR comporte : - un processus p0() et deux conteneurs C1, C2 associés à des droits de niveau utilisateur ; et - un outil d’administration ADM associé à des droits de niveau administrateur. Dans la suite de la description, on considère une fonction logicielle F1 installée dans le container C1 de l’espace utilisateur USR. Dans l’exemple décrit ici, cette fonction logicielle F1 met en œuvre un unique processus p1 qui appelle : - un appel système open() d’ouverture de fichier ; et - un appel système send() d’envoi de paquets. On considère dans cet exemple : - que l’appel système open() d’ouverture de fichier génère lors de son exécution, une opération oper_open() ; - que l’appel système send() d’envoi de paquets génère lors de son exécution, une opération oper_send() ; et que - les opérations oper_open() d’ouverture de fichier et oper_send() d’envoi de paquets sont des opérations sensibles au sens des Modules de Sécurité Linux (LSM). Le noyau KER comporte un gestionnaire d’appel système GAS qui référence l’implémentation de ces appels système. Dans la suite de la description, on considère qu’il a été déterminé que la fonction F1 était vulnérable et que cette vulnérabilité possède l’identifiant unique ID CVEk . Au cours d’une étape F10 du procédé d’installation, le module d’installation MINST envoie une requête REQ au serveur SRV SEC , cette requête REQ comportant l’identifiant de vulnérabilité ID CVEk . Au cours d’une étape F20, le module d’installation MINST reçoit, en réponse à la requête REQ, le fichier de description dont l’identifiant ID Fk est associé à l’identifiant de vulnérabilité ID CVEk dans la base de données BD. Ce fichier de description ID Fk est représenté à la . Dans l’exemple de réalisation décrit ici, le fichier de description ID Fk comporte : - dans le champ « ID VUL », l’identifiant ID CVEk de la vulnérabilité; - dans la structure « META_PG », les métadonnées d’un programme PG k de mitigation de la vulnérabilité ID CVEk ; et - dans la structure « META_HLP » les métadonnées de deux fonctions de support HLPk1 et HLPk2 appelées par le programme PG k . Dans l’exemple de la , les métadonnées META_PG du programme de mitigation PG k comportent : - la métadonnée « NP » correspondant au nom PG k de ce programme ; et - la métadonnée « HK » correspondant au point de déclenchement du programme PG k constitué ici par l’appel système d’ouverture de fichier open. Dans l’exemple de la , les métadonnées META_HLP de la fonction de support HLPk1 comportent : - la métadonnée « NH » correspondant au nom HLPk1 de cette fonction de support ; - la métadonnée « HSH » comprenant un haché « a0…65f » de cette fonction de support ; et - la métadonnée « EP » correspondant à un point d’entrée DYNFUN dans cette fonction de support, par exemple 4. Dans l’exemple de la , les métadonnées META_HLP de la fonction de support HLPk2 comportent : - la métadonnée « NH » correspondant au nom HLPk2 de cette fonction de support - la métadonnée « HSH » comprenant un haché « c7…409 » de cette fonction de support ; et - la métadonnée « EP » correspondant à un point d’entrée DYNFUN dans cette fonction de support ; par exemple 2. Au cours d’une étape F30, le module d’installation MINST vérifie si les fonctions de support HLPk1 et HLPk2 nécessaires à l’exécution du programme de mitigation PG k et identifiées dans le fichier de description ID Fk reçu à l’étape E20 sont déjà installées dans le noyau KER. Dans le mode de réalisation décrit ici, le module de vérification MINST effectue cette vérification à travers une interface noyau du noyau KER. Cette opération peut être réalisée en interrogeant un système de fichier virtuel, par exemple similaire au système Sysfs connu de l’homme du métier et décrit en particulier dans le document https://fr.wikipedia.org/wiki/Sysfs. En pratique, des fonctions de support génériques susceptibles d’être appelées par de nombreux programmes de mitigation peuvent être préinstallées dans le noyau KER. Dans l’exemple de réalisation décrit ici, les fonctions de support HLPk1 et HLPk2 sont déjà installées dans le noyau KER et le résultat du test F30 est positif. Au cours d’une étape F40, le module d’installation MINST télécharge le programme de mitigation PG k identifié dans le fichier de description ID Fk reçu à l’étape F20. Dans le mode de réalisation décrit ici, ce téléchargement s’effectue auprès du serveur de sécurisation SRV SEC . Dans le mode de réalisation décrit ici, ce programme (noté PG S k ) est téléchargé en code source au format eBPF. Au cours d’une étape F50, le module d’installation MINST compile le programme de mitigation PG k . Au cours d’une étape F60, le programme de mitigation PG k est lié avec un fichier d’en-tête HDF selon un mécanisme d’édition de liens (en anglais « link ») connu de l’homme du métier, pour obtenir un programme de mitigation exécutable PG E k . Dans le mode de réalisation décrit ici, ce fichier d’en-tête HDF est mémorisé dans la mémoire non volatile réinscriptible 14. Ce fichier d’en-tête HDF est mis à jour à chaque fois qu’une fonction de support HLPk1 et HLPk2 est installée dans le noyau KER. La illustre un exemple de fichier d’en-tête HDF en supposant que seules les fonctions de support HLPk1 et HLPk2 sont installées dans le noyau KER et que la fonction HLPk1 a été installée avant la fonction HLPk2. Dans l’exemple décrit ici, le fichier d’en-tête HDF comporte : - une première ligne L1 ajoutée au moment de l’installation de la fonction de support HLPk1 dans le noyau KER ; et - une deuxième ligne L2 ajoutée au moment de l’installation de la fonction de support HLPk2. Chaque ligne L1, L2 comporte : - la chaîne de caractère « #define __ID_ », concaténée - au nom de la fonction de support, c’est-à-dire à la chaîne de caractères « HLPk1 », « HLPk2 », concaténé - au caractère « _ », concaténé - au haché de la fonction de support, à savoir dans cet exemple « a0…65f » pour la ligne L1 et « c7…409 » pour la ligne L2, concaténé - à la chaîne de caractères « __ », concaténé - à un numéro correspondant à un index de position de la fonction de support dans la mémoire du noyau KER, 0 pour la ligne L1 et 1 pour la ligne L2. Le fichier d’en-tête HDF comporte, après l’ensemble des lignes L1, L2, … correspondantes à chacune des fonctions de support installées dans le noyau KER, une ligne : # define fnsup_stat(fs_id, h, pe_id, arg) fnsup_dyn(__ID_##fs_id##_##h##__, pe_id, arg) L’homme du métier du logiciel comprend ainsi que si, par exemple, le fichier de mitigation PG k , comporte dans son code source l’instruction fnsup_stat(HLPk1, a0…65f, 4, arg), l’étape E60 d’édition de lien traduit cette instruction : - dans un premier temps en fnsup_dyn(__ID_HLPk1_a0…65f__, 4, arg), - puis dans un deuxième temps, en fnsup_dyn(0, 4, arg), car dans l’exemple de la , en ligne L1, __ID_HLPk1_a0…65f__ est défini à 0 où 4 correspond au point d’entrée à appeler dans la fonction support HLPk1. La forme exécutable du programme de mitigation PG k , en binaire, est mémorisée dans la mémoire non volatile 14 de l’équipement EQ pour installation dans une zone ZPS du noyau KER au cours d’une étape F70 décrite ultérieurement. Dans le mode de réalisation décrit ici, la fonction fnsup_stat est une fonction statique qui agit comme un proxy pour appeler les fonctions de support HLP i, j installées dans le noyau KER. Dans le mode de réalisation décrit ici, cette fonction comporte trois paramètres : - un identifiant de la fonction support fs_id, valorisé à « 0 » dans cet exemple ; - un point d’entrée pe_id dans la fonction support, valorisé à 4 dans cet exemple ; et - des arguments valorisés ici à arg. Conformément à ce mode de réalisation de l’invention, lorsque les programmes de mitigation sont chargés dans le noyau (étape F70 décrite ultérieurement), un espace mémoire leur est réservé, et l’adresse de cet espace mémoire est associé à l’identifiant fs_id de fonction de support dans une table TB du noyau KER. Dans l’exemple de la , la table TB du noyau KER illustre la situation dans laquelle le programme de mitigation PGk est installé à l’adresse @PGk, avec un identifiant de fonction de support valorisé à 0 de sorte que l’exécution de l’instruction fnsup_dyn(0, 4, arg) déclenche l’exécution du programme PGk au point d’entrée 4, avec les arguments arg. De retour à l’étape F30, s’il s’avère qu’au moins une fonction de support HLPk1 et HLPk2 identifiée dans le fichier de description n’est pas installée dans le noyau KER, le résultat du test F30 est négatif, et cette fonction de support doit être téléchargée (étape H10) auprès du serveur SRV SEC et installée (étape H20) dans la zone ZPS du noyau KER. Dans le mode de réalisation décrit ici, les fonctions de support sont téléchargées en code objet et destinées à être linkées avec le code objet du programme de mitigation. Ces étapes de téléchargement sont effectuées par l’administrateur de l’équipement EQ ou par un module de l’espace utilisateur USR bénéficiant de droits administrateur. Une fois que toutes les fonctions de support nécessaires au programme de mitigation PG k sont installées dans le noyau KER, ce fichier peut être compilé (étape F50), linké (étape F60) et chargé à son tour dans le noyau. Dans la variante de réalisation décrite précédemment, le programme de mitigation est téléchargé en code source. En variante, le programme de mitigation PGk est téléchargé sous forme de code objet (noté PGOk) et l’étape F50 de compilation n’est pas nécessaire. Dans un mode de réalisation de cette variante, la compilation du programme de mitigation en code source utilise le fichier de description IFFk de la , et génère en plus du code objet PGOk, un tableau comportant une case pour chaque fonction de support appelée par ce programme de mitigation. La kième case de ce tableau est réservée pour contenir l’identifiant fs_id de la kième fonction de support prise dans l’ordre du fichier de description IDFk. Ce tableau est téléchargé en même temps que le code objet PGOk, au cours de l’étape F40. Au moment de l’édition de liens (étape F60), chaque case k du tableau est remplie avec l’identifiant HLPk,1 de la kième fonction de support. Il est important de rappeler que dans cet exemple, le programme de mitigation PG k vise à mitiger la vulnérabilité de la fonction F1 uniquement et plus précisément à bloquer les effets de l’appel système d’ouverture de fichier open() par le processus p1() de cette fonction F1. A cet effet, et dans le mode de réalisation décrit ici, l’invention met en œuvre le procédé de sécurisation décrit dans le document [1]. Nous rappelons que dans cet exemple l’espace utilisateur USR comporte un processus p0(), la fonction logicielle F1 dans le container C1 et une autre fonction logicielle F2 dans le container C2. Autrement dit, et en particulier, l’appel système de la fonction open() par un processus p2() de la fonction F2 ne doit pas être mitigé par le programme de mitigation PG k . Dans le mode de réalisation décrit ici, les processus de l’espace utilisateur USR sont isolés grâce au mécanisme connu d’espaces de nommage. De façon connue, le système d’exploitation Linux propose 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 décrit ici : - le processus p0 est associé respectivement à des espaces de nommage différents ENNETWORK0 (pour l’espace Network), ENIPC0 (pour IPC), ENIPD0 (pour PID), ENUser0 (pour User) ; - les processus du conteneur C1, en l’occurrence le processus p1(), sont associés à des espaces de nommage différents ENNETWORK1, ENIPC1, ENIPD1, ENUser1 ; 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. Dans l’exemple décrit ici, le processus p2() appelle, comme le processus p1(), l’appel système open() d’ouverture de fichier et l’appel système send() d’envoi de paquets. Dans l’exemple de la , le processus p0() ne fait pas appel aux appels système open(), send(). Conformément au mécanisme décrit dans le document [1], les processus p0(), p1() et p2() sont également associés à un espace de nommage ENSECURE dédié à la gestion de la sécurité. Dans le mode de réalisation décrit ici, le processus p0() est associé à l’espace de nommage de gestion de la sécurité ENSECURE0, le container C1 est associé à l’espace de nommage de gestion de la sécurité ENSECURE1 et le container C2 est associé à l’espace de nommage de gestion de la sécurité ENSECURE2. La représente une table TABPID des processus 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 son cycle de vie comme son identifiant PID, ses drapeaux (flags en anglais), sa pile, et un champ nsproxy qui comporte des pointeurs vers les espaces de nommage. En particulier, le champ nsproxy comporte un pointeur ENSECURE vers l’espace de nommage dédié à la gestion de la sécurité associé à ce processus. Cet espace de nommage définit une structure de données qui comprend notamment la politique de sécurité, par exemple la politique de mitigation. 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 C1 et C2 pointent vers l’espace de nommage ENSECURE0 du processus p0. 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é ou de mitigation par un conteneur. Dans l’exemple de réalisation décrit ici, on suppose qu’initialement les processus n’ont défini aucune politique de sécurité ni de mitigation. On se place maintenant dans le contexte dans lequel le programme de mitigation PG k qui vient d’être généré pour mitiger la vulnérabilité ID CVEk de la fonction F1, par compilation et édition de liens au cours des étapes F50 et F60. Le programme de mitigation PG k stocké dans la mémoire non volatile 14 doit être chargé dans la zone ZPS de politiques de sécurité du noyau KER. De façon très avantageuse, le chargement d’une politique de sécurité, et en particulier d’un programme de mitigation, 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 module d’installation MINST comporte des instructions load_ps() pour charger (étape F70) un programme de mitigation sous forme d’un fichier eBPF compilé sous forme binaire dans la zone ZPS du noyau KER. Cette fonction load_ps() consiste à ouvrir le fichier eBPF compris dans la mémoire non volatile 14 et à le copier vers une interface avec le noyau KER. Comme décrit précédemment, cette étape comprend l’allocation d’un espace mémoire dans la zone ZPS pour cette fonction de mitigation, et l’association de l’adresse de cet espace mémoire avec un identifiant fs_id de fonction de support dans une table TB du noyau KER. Dans le mode de réalisation décrit ici, cette écriture dans l’interface noyau déclenche un événement pour stocker le programme de mitigation dans l’espace de nommage du processus protégé par ce programme de mitigation, à savoir le processus p1() dans cet exemple. 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 gestion de sécurité Linux LSM1 et éventuellement au moins un autre module de sécurité LSM2, par exemple, un module SELinux ou un module AppAmor. 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 . 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 représente sous forme d’ordinogramme les principales étapes d’un procédé mis en œuvre 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. L’infrastructure ICS détermine si l’opération sensible OPS est répertoriée dans la table TABCTR. 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, par exemple SELinux et un module AppAmor. Lorsque le processus p1() de la fonction F1 appelle l’appel système open() d’ouverture de fichier, l’infrastructure ICS détermine que cette opération sensible est répertoriée dans la table TABCTR et elle déclenche l’exécution du module de sécurité LSM1 au cours d’une étape E20. 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. Il s’agit en l’occurrence du processus p1(). 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. C’est le cas si l’appel système open() d’ouverture de fichier a été appelé par le processus p1(), mais ce n’est pas le cas si cet appel système open() a été appelé par le processus p2(). Si c’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, le programme de mitigation PG k est exécuté et l’appel système open() d’ouverture de fichier est bloqué. Le module de sécurité LSM1 enregistre ce blocage dans un fichier de log FLOG du noyau KER au cours d’une étape E70 et envoie un résultat négatif RET à l’infrastructure de sécurité ICS. Ce fichier de log FLOG peut être analysé par l’administrateur au moyen de l’outil d’administration ADM. Dans le mode de réalisation décrit ici, une politique de sécurité 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. 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é ICS 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 ou 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. Dans l’exemple décrit précédemment, le procédé de sécurisation décrit dans le document [1] a été utilisé pour installer le programme de mitigation PG k de sorte qu’il ne mitige que la vulnérabilité CVE k de la fonction F1. D’autres méthodes peuvent être envisagées. Une première méthode consiste à appliquer des politiques programmables eBPF par hiérarchie de processus, ces politiques étant appliquées via le framework Landlock LSM au niveau module de sécurité Linux (LSM) comme décrit au chapitre 4 du document https://tel.archives-ouvertes.fr/tel-01762144/document. Une seconde méthode consiste à appliquer au niveau appel système des politiques sous forme de programme cBPF applicables à l’aide d’un module de sécurité Seccomp-BPF. Dans les deux cas, les politiques sont stockées dans des structures dédiées du noyau. Elles identifient un processus ou une hiérarchie de processus (par pid, numéro d’inode de l’exécutable, …) et sont appelées lors d’événements particuliers (appels systèmes, opération LSM, …) La représente l’architecture fonctionnelle d’un module MINST d’installation d’un programme de mitigation dans le noyau d’un équipement, conforme à un mode particulier de réalisation de l’invention. Il comporte : - un sous-module MF10 pour envoyer une requête comportant un identifiant unique d’une vulnérabilité à un serveur de sécurisation ; - un sous-module MF20 d’obtention, en réponse à cette requête, d’un fichier de description du programme de mitigation ; - un sous-module MF30 pour vérifier si une fonction de support identifiée dans un fichier de description est enregistrée dans le noyau ; - un sous-module MF40 de téléchargement d’un programme de mitigation en code source ou en code objet, - un sous-module MF50 de compilation ; - un sous-module MF60 d’édition de lien ; et - un sous-module MF70 d’installation du code exécutable du programme de mitigation dans le noyau de l’équipement. [1] : Snappy : Programmable Kernel-Level Policies for Containers, Maxime Bélair, Sylvie Laniepce, Jean-Marc Menaud, Mars 2021, ACM ISBN 978-1-4503-8104-8/21/03 Procédé d’installation d’un programme de mitigation (PG k ) dans le noyau (KER) d’un équipement informatique (EQ) pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger (F1) s’exécutant dans un espace utilisateur (USR) dudit équipement informatique (EQ), ce procédé comportant : - une étape (F10) d’envoi d’une requête (REQ) comportant un identifiant unique (ID CVEk ) de ladite vulnérabilité à un serveur de sécurisation (SRV SEC ) ; - une étape (F20) d’obtention, en réponse à la requête (REQ) d’un fichier (ID Fk ) de description dudit programme (PG k ) ; - une étape (F40, F50) d’obtention d’un code objet (PG O k ) du programme de mitigation (PG k ) identifié dans ledit fichier de description (ID Fk ) ; - une étape (F60) d’édition de lien pour résoudre au moins un symbole du code objet (PG O k ) afin de générer un code exécutable (PG E k ) dudit programme de mitigation (PG k ) spécifique audit équipement (EQ) ; et - une étape (F70) d’installation du code exécutable (PG E K ) dans le noyau (KER) dudit équipement, ledit équipement (EQ) comportant des moyens pour assurer que ledit programme de mitigation ne mitige ladite vulnérabilité que pour ladite fonction à protéger (F1). Procédé d’installation selon la revendication 1, caractérisé en ce qu’il comporte : - une étape (F40) de téléchargement d’un code source (PG S k ) dudit programme de mitigation à partir d’une adresse comprise dans ledit fichier de description (ID Fk ) ; et - une étape (F50) de compilation dudit code source (PG S k ) pour obtenir ledit code objet (PG O k ). Procédé selon la revendication 2 dans lequel le code source est un programme en langage eBPF. Procédé d’installation selon la revendication 1, caractérisé en ce qu’il comporte une étape (F40) de téléchargement dudit code objet (PG O k ) à partir d’une adresse comprise dans ledit fichier de description (ID Fk ). Procédé d’installation selon l’une quelconque des revendications 1 à 4 dans lequel ledit fichier de description (ID Fk ) comporte l’identifiant d’au moins une fonction de support (HLP i, j ) pouvant être appelée par ledit programme de mitigation (PG k ) lorsqu’il est exécuté par un processeur (10) dudit équipement. Procédé d’installation selon la revendication 5 caractérisé en ce qu’il comporte, avant ladite étape (F60) d’édition de lien, une étape (F30) de vérification que ladite au moins une fonction de support est installée dans ledit noyau (KER). Procédé d’installation selon la revendication 6 dans lequel ladite étape (F30) de vérification comporte la vérification d’un haché (HSH) de ladite fonction de support (HLP i, j ) compris dans ledit fichier de description (ID Fk ). Procédé d’installation selon l’une quelconque des revendications 5 à 7 dans lequel le code source (PG S k ) du programme de mitigation (PG k ) comporte une fonction statique (fnsup_stat) pour appeler ladite fonction de support (HLP i, j ), l’appel à ladite fonction statique (fnsup_stat) étant remplacé par un appel à une fonction dynamique (fnsup_dyn) au cours de ladite étape (F60) d’édition de lien. Procédé d’installation selon l’une quelconque des revendications 5 à 8 dans lequel ladite étape (F60) d’édition de lien utilise un fichier d’en-tête (HDF) configuré pour permettre la substitution d’un identifiant unique obtenu à partir de l’identifiant de la fonction de support (HLP i, j ) par un index représentatif de l’emplacement de la fonction de support (HLP i, j ) dans le noyau de l’équipement. Procédé d’installation selon la revendication 9 dans lequel ledit identifiant unique comporte un haché de la fonction de support (HLP i, j ). Procédé d’installation selon l’une quelconque des revendications 1 à 10, ledit procédé comportant : - une étape (F70) d’enregistrement dudit programme de mitigation (PG k ) en tant que politique de sécurité dans un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité, cet espace de nommage (ENSECURE1) étant associé à au moins un processus (p1) de ladite fonction à protéger (F1), et - ledit noyau (KER) met en œuvre un procédé de sécurisation pour sécuriser un appel système déclenché par un processus courant (p1) dudit espace utilisateur (USR) avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système, ledit procédé de sécurisation comportant : - une étape (E30) d’obtention d’au moins un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité associé audit processus courant (p1) ; - une étape (E40) pour déterminer si ledit au moins un espace de nommage (ENSECURE1) comporte une politique de sécurité ; et - une étape (E50) d’exécution de ladite politique de sécurité. Module (MINST) d’installation d’un programme de mitigation (PG k ) dans le noyau (KER) d’un équipement informatique (EQ) pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger (F1) s’exécutant dans un espace utilisateur (USR) dudit équipement informatique (EQ), ce module comportant : - un sous-module (MF10) d’envoi d’une requête (REQ) comportant un identifiant unique (ID CVEk ) de ladite vulnérabilité à un serveur de sécurisation (SRV SEC ) ; - un sous-module (MF20) d’obtention, en réponse à la requête (REQ) d’un fichier (ID Fk ) de description dudit programme (PG k ) ; - un sous-module (MF40, MF50) d’obtention d’un code objet (PG O k ) du programme de mitigation (PG k ) identifié dans ledit fichier de description (ID Fk ) ; - un sous-module (MF60) d’édition de lien pour résoudre au moins un symbole du code objet (PG O k ) afin de générer un code exécutable (PG E k ) dudit programme de mitigation (PG k ) spécifique audit équipement (EQ) ; et - un sous-module (MF70) d’installation du code exécutable (PG E K ) dans le noyau (KER) dudit équipement, ledit équipement (EQ) comportant des moyens pour assurer que ledit programme de mitigation ne mitige ladite vulnérabilité que pour ladite fonction à protéger (F1). Equipement (EQ) comportant un espace utilisateur (USR), un noyau (KER) et un module (MINST) selon la revendication 12 pour installer un programme de mitigation (PG k ) dans le noyau (KER) pour mitiger une vulnérabilité susceptible d’affecter une fonction à protéger (F1) s’exécutant dans l’espace utilisateur (USR), cet équipement comportant : - un module (MF70) d’enregistrement dudit programme de mitigation (PG k ) en tant que politique de sécurité dans un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité, cet espace de nommage (ENSECURE1) étant associé à au moins un processus (p1) de ladite fonction à protéger (F1), - des moyens (GAS, ICS, LSM1) dudit noyau (KER) pour sécuriser au moins un appel système déclenché par un processus courant (p1) dudit espace utilisateur (USR) avant d’exécuter au moins une opération déclenchée par ledit au moins un appel système, lesdits moyens étant configurés pour : - obtenir (E30) au moins un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité associé audit processus courant (p1) ; - déterminer (E40) si ledit au moins un espace de nommage (ENSECURE1) comporte une politique de sécurité ; et - exécuter ladite politique de sécurité. .