EP4302213A1 - Procede et module d'installation d'un programme de mitigation dans le noyau d'un equipement informatique - Google Patents

Procede et module d'installation d'un programme de mitigation dans le noyau d'un equipement informatique

Info

Publication number
EP4302213A1
EP4302213A1 EP22710693.7A EP22710693A EP4302213A1 EP 4302213 A1 EP4302213 A1 EP 4302213A1 EP 22710693 A EP22710693 A EP 22710693A EP 4302213 A1 EP4302213 A1 EP 4302213A1
Authority
EP
European Patent Office
Prior art keywords
kernel
program
pgk
ker
function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22710693.7A
Other languages
German (de)
English (en)
Inventor
Maxime BELAIR
Sylvie Laniepce
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4302213A1 publication Critical patent/EP4302213A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software

Definitions

  • the invention relates to the general field of securing computer software.
  • the invention relates more particularly to a method for installing, in the kernel of a piece of computer equipment, a program configured to mitigate a given vulnerability likely to affect the behavior of software running in the user space of this piece of equipment.
  • a mitigation of this vulnerability can consist in blocking the packet sending process. Mitigation does not remove the vulnerability but it makes it unexploitable.
  • Managing CVEs to maintain the security of IT equipment can therefore be overly complex.
  • the invention aims to facilitate the installation of a program in the kernel of computer equipment to mitigate a vulnerability impacting software running on this equipment and performing a function to be protected.
  • the invention relates to a method for installing a mitigation program in the kernel of computer equipment to mitigate a vulnerability likely to affect a function to be protected running in a space user of said computer equipment, this method comprising:
  • the invention relates to a module for installing a mitigation program in the kernel of computer equipment to mitigate a vulnerability likely to affect a function to be protected running in a user space of said computer equipment, this module comprising:
  • sub-module for installing the executable code in the kernel of said equipment, said equipment comprising means for ensuring that said mitigation program only mitigates said vulnerability for said function to be protected.
  • the invention proposes a mechanism for distributing mitigation programs intended to be installed in the cores of computer equipment.
  • the security server proposed by the invention can be considered as a distribution platform (“store”) for mitigation programs.
  • the mitigation program is loaded in the kernel and not in a kernel module, namely a module isolated from the kernel, and dedicated to specific functions.
  • the mitigation program loaded in the kernel is an executable program. It is not a simple signature or a simple set of rules.
  • the invention proposes to download the appropriate mitigation program when a vulnerability affecting software running on the computer equipment has been detected, and to automatically install this program in the kernel of the equipment to mitigate this vulnerability for the affected software, and only for this one.
  • a mitigation program is an example of a particular security policy dealing with mitigation corrections.
  • the mitigation program can be loaded without privileged administration rights.
  • This characteristic is particularly advantageous because the LSMs (for “Linux Security Module”) modules require that the security policies be put in place by an entity of the user space having administrative rights.
  • the mitigation programs can be loaded including “hot”, that is to say during the execution of the vulnerable software.
  • the installation method according to the invention comprises:
  • the source code is in eBPF language (for “Extended Berkeley Packet Filter”).
  • eBPF Extended Berkeley Packet Filter
  • this language is deliberately limited in terms of functionality (no loops, no pointer arithmetic, no direct access to kernel structures, ...) but has strong security properties so that it is unable to attack the rest of the system.
  • This characteristic advantageously makes it possible to prevent critical attacks, for example to recover information, modify the integrity or the availability of the rest of the system.
  • the proposed technique thus allows the implementation of mitigation programs without compromising the security of the system, including after the initialization of the software performing the function to be protected. This makes it possible to block, after the initialization of the software to be protected, behaviors which it is necessary to authorize for the initialization of the software.
  • the installation method comprises a step of downloading said object code from an address included in said description file.
  • the description file of the mitigation program includes the identifier of at least one support function that can be called by the mitigation program when it is executed by a processor of said equipment.
  • This embodiment overcomes the intrinsic limitations of the eBPF language.
  • helpers can be loaded “hot”, ie during the execution of the kernel. They can be called by an eBPF security policy, and in particular by a mitigation program, to perform critical processing such as access to core structures for the eBPF code. They are external to the mitigation programs and must be loaded into the kernel by a user space entity with administrative rights.
  • This particular embodiment allows, by deporting the critical accesses and the complex processing operations to the support functions, the implementation of elaborate policies without compromising the security of the system and with low additional performance costs.
  • the installation method comprises, before said link editing step, a step for verifying that said at least one support function is installed in said kernel.
  • this verification step includes the verification of a hash of said support function included in said description file.
  • the source code of the mitigation program includes a static function for calling said support function, the call to said static function being replaced by a call to a dynamic function during said editing step of link.
  • said link editing step uses a header file configured to allow the substitution of a unique identifier obtained from the identifier of the support function by an index representative of the location of the support function in the core of the equipment.
  • this unique identifier comprises a hash of the support function.
  • the installation method comprises:
  • said kernel implements a security method to secure a system call triggered by a current process of said user space before executing at least one operation, typically an LSM (Linux Security Module) operation triggered by said at least one system call, said securing method comprising:
  • the invention relates to equipment comprising a user space, a kernel and a module as mentioned above for installing a mitigation program in the kernel to mitigate a vulnerability likely to affect a function to be protected running in the space user, this equipment comprising:
  • the protection of a system call can more particularly consist in protecting the accesses (read/creation/modification/deletion, etc.) to sensitive kernel resources (inodes, files, etc.) which can be triggered in the code of the system call.
  • system call from the user space, for example, to manage the sensitive operations of opening a file, sending a package, creating an "inode", ...
  • This embodiment of the invention finds a preferred application in the Linux environment but can be applied to any operating system offering a resource isolation mechanism by namespace.
  • This security mechanism proposes to associate security policies with a kernel namespace instead of integrating the policy into the LSM module itself. This characteristic very advantageously makes it possible to benefit from all the mechanisms for managing the namespaces of the kernel.
  • the mitigation program is associated with a namespace dedicated to security management associated with an operation likely to be triggered by a system call from a process of the vulnerable software function.
  • the kernel comprises a security control infrastructure and a security module, this infrastructure being configured to execute the mitigation program before executing at least one operation triggered by the system call.
  • the securing method determines whether the namespace of the current process includes at least one ancestor. If this is the case, the method (or the device) implements for each of these ancestor namespaces, processing identical to that implemented for the namespace associated with the current process.
  • the method comprises:
  • a mitigation program cannot be deactivated or modified from the user space, in particular by a software stack or a container belonging to a namespace for which this policy has been defined.
  • the installation process is implemented by a computer program. Consequently, the invention also relates to a computer program on a recording medium, this program being capable of being implemented in computer equipment or more generally in a computer.
  • This program includes instructions allowing the implementation of a method as described above.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing the programs.
  • the media can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of one of the methods as described previously.
  • FIG. 1 shows a system comprising an installation module according to a particular embodiment
  • FIG. 2 shows in flowchart form the main steps of an installation method according to a particular embodiment
  • FIG. 3 shows a description file of a mitigation program that can be used in a particular embodiment
  • FIG. 4 shows a header file that can be used in a particular embodiment
  • - Figure 5 shows a process table that can be used in a particular embodiment
  • - Figure 6 shows a control table that can be used in a particular embodiment
  • FIG. 7 shows in the form of a flowchart the main steps of a securing method that can be implemented in a particular embodiment
  • FIG. 8 shows the functional architecture of an installation module according to a particular embodiment.
  • FIG. 1 represents a user's computer equipment EQ, for example a server.
  • this EQ equipment has the hardware architecture of a computer. It comprises in particular a processor 10, a random access memory of the RAM type 11, a read only memory of the ROM type 12, means of communication 13 and a non-volatile rewritable memory, for example a hard disk 14.
  • the equipment EQ is configured to be able to communicate with a security server SERVSEC via a communication network NET.
  • This security server SERVSEC comprises a database BD comprising a set of CVE identifiers of vulnerabilities and in association with each of these vulnerability identifiers IDCVEÎ, the identifier IDFÎ of a description file of a PGi program configured for s to execute in the kernel (in English “kernel”) of an item of equipment and to implement a security policy capable of mitigating the vulnerability of the identifier IDCVEÎ.
  • PGi mitigation programs are hereinafter referred to as “PGi mitigation programs” or “IDCVEÎ vulnerability mitigation programs”.
  • the PGi mitigation programs can be downloaded by the EQ equipment from the SERVSEC security server.
  • a vulnerability identifier IDCVEÎ is for example of the form CVE-AAAA-IIII, where AAAA is the year of publication and IIII a unique number.
  • the mitigation programs PGi downloadable from the security server SERVSEC are source files in eBPF language, denoted PG s i .
  • the mitigation programs PGi downloadable from the security server SERVSEC are object files denoted PG°i obtained by compiling source files PG s i in eBPF language.
  • the description files are in JSON (Java Script Object Notation) format.
  • the IDFÎ description file of a PGi mitigation program includes:
  • the PGi mitigation program metadata includes:
  • a mitigation program PGi can call on at least one support function (or dependency, in English “helper”) HLPy.
  • the description file IDFÎ comprises, in a “METAJHLP” structure, metadata of this support function HLPy;
  • the META_HLP metadata of an HLPy support function includes:
  • the equipment EQ comprises a software system SYS, this system comprising a kernel or operating system KER, and a user space USR.
  • KER operating system is of the Linux (registered trademark) type.
  • the user space USR comprises an installation module MINST in accordance with the invention.
  • This installation module is configured to implement an installation method in accordance with the invention, the main steps of which are represented in the form of a flowchart in FIG. 2.
  • the USR user space includes:
  • the KER kernel has a GAS system call handler that references the implementation of these system calls.
  • the installation module MINST sends a request REQ to the server SRVSEC, this request REQ comprising the vulnerability identifier IDcvEk.
  • the installation module MINST receives, in response to the request REQ, the description file whose identifier IÜFk is associated with the vulnerability identifier IDcvEk in the database BD.
  • the description file IÜFk includes:
  • the metadata META_PG of the mitigation program PGk comprises: the metadata “NP” corresponding to the name PGk of this program;
  • the META_HLP metadata of the HLPkl support function includes:
  • the META_HLP metadata of the HLPk2 support function includes:
  • the installation module MINST verifies whether the support functions HLPk1 and HLPk2 necessary for the execution of the mitigation program PGk and identified in the description file IÜFk received at step E20 are already installed in the KER core.
  • the verification module MINST performs this verification through a kernel interface of the kernel KER.
  • This operation can be performed by querying a virtual file system, for example similar to the Sysfs system known to those skilled in the art and described in particular in the Linux manual (for example at the address https://man7.org/linux /man-pages/man5/sysfs.5.html).
  • the support functions HLPk1 and HLPk2 are already installed in the kernel KER and the result of the test F30 is positive.
  • the installation module MINST downloads the mitigation program PGk identified in the description file IÜFk received at step F20. In the embodiment described here, this download is done from the security server
  • this program (denoted PG3 ⁇ 4) is downloaded in source code in eBPF format.
  • the installation module MINST compiles the mitigation program PGk.
  • the mitigation program PGk is linked with an HDF header file according to a link editing mechanism known to those skilled in the art, to obtain a PG E executable mitigation program k.
  • this HDF header file is stored in rewritable non-volatile memory 14.
  • This HDF header file is updated each time an HLPkl and HLPk2 support function is installed in the KER kernel.
  • Figure 4 shows an example HDF header file assuming that only the HLPkl and HLPk2 support functions are installed in the KER kernel and that the HLPkl function was installed before the HLPk2 function.
  • the HDF header file includes:
  • Each line L1, L2 comprises:
  • the HDF header file includes, after all the lines Ll, L2, ... corresponding to each of the support functions installed in the KER kernel, a line:
  • the step E60 of link edition translates this instruction:
  • Ll, _ ID_HLPkl_a0...65f _ is set to 0 where 4 corresponds to the entry point to call in the HLPkl support function.
  • the executable form of the mitigation program PGk in binary, is stored in the non-volatile memory 14 of the equipment EQ for installation in a zone ZPS of the kernel KER during a step F70 described later.
  • the fnsup_stat function is a static function that acts as a proxy to call the HPPi support functions installed in the KER kernel.
  • this function has three parameters:
  • a memory space is reserved for them, and the address of this memory space is associated with the support function identifier fsjd in a TB table of the KER kernel.
  • the KER kernel table TB illustrates the situation in which the mitigation program PGk is installed at the address @PGk, with a support function identifier valued at 0 so that the execution of the instruction fnsup_dyn(0, 4, arg) triggers the execution of the program PGk at entry point 4, with the arguments arg.
  • step F30 if it turns out that at least one HLPk1 and HLPk2 support function identified in the description file is not installed in the KER kernel, the result of test F30 is negative, and this support function must be downloaded (step H10) from the server and installed (step H20) in the ZPS zone of the KER kernel.
  • the support functions are downloaded in object code and intended to be linked with the object code of the mitigation program.
  • download steps are performed by the administrator of the EQ device or by a module in the USR user space with administrator rights.
  • this file can be compiled (step F50), linked (step F60) and loaded in turn into the kernel.
  • the mitigation program is downloaded in source code.
  • the mitigation program PGk is downloaded in the form of object code (denoted PG°k) and the compilation step F50 is not necessary.
  • the compilation of the mitigation program in source code uses the description file IFFk of FIG. 3, and generates in addition to the object code PG°k, a table comprising a box for each support function called by this mitigation program.
  • the k th box of this table is reserved to contain the identifier fsjd of the k th support function taken in order from the description file IDFk.
  • This table is downloaded at the same time as the object code PG°k, during step F40.
  • each cell k of the table is filled with the identifier HLPk,i of the k th support function.
  • the PGk mitigation program aims to mitigate the vulnerability of the Fl function only and more precisely to block the effects of the open() file opening system call by the pl( process ) of this function Fl.
  • the invention implements the securing method described in document [1].
  • the user space USR comprises a process p0(), the software function F1 in the container C1 and another software function F2 in the container C2.
  • the processes of the USR user space are isolated thanks to the known mechanism of namespaces.
  • the Linux operating system offers several namespaces (for example: Network, IPC, PID, User)... which can be used to isolate processes in a mechanism in which sets of processes are defined, so that the processes of a given set cannot see the resources used by another set of processes.
  • namespaces for example: Network, IPC, PID, User... which can be used to isolate processes in a mechanism in which sets of processes are defined, so that the processes of a given set cannot see the resources used by another set of processes.
  • ENNETWORKO for the Network space
  • ENIPCO for IPC
  • ENIPDO for PID
  • ENUserO for User
  • the processes of the container Cl in this case the pl() process, are associated with different namespaces ENNETWORK1, ENIPC1, ENIPD1, ENUserl;
  • the p2() process calls, like the pl() process, the open() system call for opening a file and the send() system call for sending packets.
  • the process p0() is associated with the security management namespace ENSECUREO
  • the container C1 is associated with the security management namespace ENSECURE1
  • the container C2 is associated with the ENSECURE2 security management namespace.
  • FIG. 5 represents a table TABPID of the processes stored in the kernel KER.
  • a process consists of a structure comprising several fields allowing to manage its life cycle such as its PID identifier, its flags, its stack, and an nsproxy field which comprises pointers to spaces of naming.
  • the nsproxy field includes an ENSECURE pointer to the namespace dedicated to security management associated with this process.
  • This namespace defines a data structure which notably includes the security policy, for example the mitigation policy.
  • the ENSECURE namespace of a process has a link to the ENSECURE namespace of the parent of that process's namespace.
  • ENSECURE1 and ENSECURE2 associated respectively with the containers C1 and C2 point to the ENSECUREO namespace of the pO process.
  • the ENSECURE namespaces therefore form a tree.
  • a process can change namespace to join the namespace of one of its child processes, for example by using the unshare() command.
  • the loading of a security policy, and in particular of a mitigation program, specific to a container in the memory of the kernel can be carried out at any moment of the life cycle of the container, not only at its initialization.
  • the installation module MINST comprises load_ps() instructions for loading (step F70) a mitigation program in the form of an eBPF file compiled in binary form in the ZPS zone of the KER kernel.
  • This load_ps() function consists of opening the eBPF file included in the non-volatile memory 14 and copying it to an interface with the KER kernel.
  • this step includes the allocation of a memory space in the ZPS zone for this mitigation function, and the association of the address of this memory space with a support function identifier fsjd in a table TB of the KER core.
  • this writing in the kernel interface triggers an event to store the mitigation program in the namespace of the process protected by this mitigation program, namely the pl() process in this example.
  • the kernel KER comprises a security control infrastructure ICS for managing Linux security modules, a Linux security management module LSM1 and optionally at least one other security module LSM2, for example, a SELinux module or an AppAmor module.
  • the kernel KER includes a control table TABCTR which defines, for each sensitive OPS operation (file opening, packet sending over the network, etc.) whether the security module LSM1 wants to control or not these sensitive operations.
  • This TABCTR table is shown in Figure 6.
  • FIG. 7 represents in the form of a flowchart the main steps of a method implemented by the system call manager GAS, the security control infrastructure ICS (framework LSM) and by the security module LSM1.
  • the system call manager GAS determines, during a step E10, whether a system call triggered by a user space process must perform a sensitive operation. If so, it triggers the KER core ICS security control infrastructure.
  • the ICS infrastructure determines whether the sensitive OPS operation is listed in the TABCTR table. In the example embodiment described here, if a process wishes to perform the sensitive operation send a packet (oper_send()) or execute a new process in user space (oper_exec()) by calling the exec() function, as these sensitive operations are not verified by the security module LSM1, the result of the determination step is negative. These operations can nevertheless be verified by the LSM2 security module, for example SELinux and an AppAmor module.
  • the ICS infrastructure determines that this sensitive operation is listed in the TABCTR table and it triggers the execution of the LSM1 security module. during a step E20.
  • the security module LSM1 determines the namespace associated with the current process at the origin of this call. For this, it uses the current process from the table of processes TABPID. This is the pl() process.
  • the security module LSM1 then executes a loop to execute the policies of the namespace of the current process linked to this sensitive operation. In a particular embodiment, the security module LSM1 then executes a loop to execute the policies of its ancestor namespaces if they exist.
  • the security module LSM1 determines whether the current namespace has defined one or more security policies to verify the validity of the sensitive operation.
  • the security module concerned LSM1 executes during a step E50 the security policy or policies defined in the namespace dedicated to the ENSECURE security management of the current process for this sensitive operation.
  • the PGk mitigation program is executed and the open() file open system call is blocked.
  • the security module LSM1 records this blocking in a log file FLOG of the kernel KER during a step E70 and sends a negative result RET to the security infrastructure ICS.
  • This FLOG log file can be analyzed by the administrator using the ADM administration tool.
  • a security policy returns a negative RET result if it detects a security problem (translating for example malicious or abnormal behavior) and a positive result if it does not detect any security problem.
  • the security module determines, if it exists, the parent namespace of the namespace of the current process (step E60) and the loop repeats.
  • the LSM1 security module sends a positive RET result to the ICS security infrastructure (test E90).
  • the ICS security infrastructure receives a positive RET result, it does not trigger any particular action and the system call is executed, unless an action is triggered by another LSM2 security module. , for example, an SELinux module or an AppAmor module.
  • the control infrastructure ICS triggers a security action AS during a step E80.
  • This action may consist of destroying the process at the origin of the call and raising an alert in the FLOG log file.
  • this namespace when no process remains in a namespace dedicated to security management, this namespace is automatically destroyed by the kernel. This operation destroys the security policies associated with these namespaces.
  • the securing method described in document [1] was used to install the mitigation program PGk so that it only mitigates the CVEk vulnerability of the Fl function.
  • a first method consists in applying programmable eBPF policies by process hierarchy, these policies being applied via the Landlock LSM framework at the Linux security module (LSM) level as described in chapter 4 of the document https://tel.archives-ouvertes. fr/tel- 01762144/document.
  • LSM Linux security module
  • a second method consists in applying policies at the system call level in the form of a cBPF program applicable using a Seccomp-BPF security module.
  • policies are stored in dedicated kernel structures. They identify a process or a hierarchy of processes (by pid, inode number of the executable, ...) and are called during specific events (system calls, LSM operation, %)
  • FIG. 8 represents the functional architecture of a module MINST for installing a mitigation program in the kernel of an item of equipment, in accordance with a particular embodiment. It comprises :
  • a sub-module MF20 for obtaining, in response to this request, a description file of the mitigation program

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

Ce procédé installe un programme de mitigation (PGk) dans le noyau (KER) d'un équipement informatique (EQ) pour mitiger une vulnérabilité susceptible d'affecter une fonction à protéger (Fl) 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 (IDCVEQ de ladite vulnérabilité à un serveur de sécurisation (SRVSEC);- une étape (F20) d'obtention, en réponse à la requête (REQ) d'un fichier (IDEQ de description dudit programme (PGk);- une étape (F40, F50) d'obtention d'un code objet (PG°k) du programme de mitigation (PGk) identifié dans ledit fichier de description (IDEQ;- une étape (F60) d'édition de lien pour résoudre au moins un symbole d'un code objet (PG°k) afin de générer un code exécutable (PGEk) dudit programme de mitigation (PGk) spécifique audit équipement (EQ); et- une étape (F70) d'installation du code exécutable (PGEK) 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 (Fl).

Description

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 oeuvre 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 particulier, 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 oeuvre pour chacun de ces espaces de nommage ancêtres, 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 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 oeuvre 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 oeuvre dans un équipement informatique 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 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 figure 1 représente un système comportant un module d'installation conforme à un mode particulier de réalisation ;
- la figure 2 représente sous forme d'ordinogramme les principales étapes d'un procédé d'installation conforme à un mode particulier de réalisation ;
- la figure 3 représente un fichier de description d'un programme de mitigation pouvant être utilisé dans un mode particulier de réalisation ;
- la figure 4 représente un fichier d'en-tête pouvant être utilisé dans un mode particulier de réalisation ;
- la figure 5 représente une table de processus pouvant être utilisée dans un mode particulier de réalisation ; - la figure 6 représente une table de contrôle pouvant être utilisée dans un mode particulier de réalisation ;
- la figure 7 représente sous forme d'ordinogramme les principales étapes d'un procédé de sécurisation pouvant être mis en oeuvre dans un mode particulier de réalisation ; et
- la figure 8 représente l'architecture fonctionnelle d'un module d'installation conforme à un mode particulier de réalisation.
La figure 1 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 SERVSEC via un réseau de communication NET. Ce serveur de sécurisation SERVSEC 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é IDCVEÎ, l'identifiant IDFÎ d'un fichier de description d'un programme PGi configuré pour s'exécuter dans le noyau (en anglais « kernel ») d'un équipement et pour mettre en oeuvre une politique de sécurité apte à mitiger la vulnérabilité d'identifiant IDCVEÎ.
Pour plus de simplicité, les programmes PGi sont ci-après appelés « programmes de mitigation PGi » ou « programmes de mitigation de la vulnérabilité IDCVEÎ ».
Les programmes de mitigation PGi peuvent être téléchargés par l'équipement EQ auprès du serveur de sécurisation SERVSEC.
Un identifiant IDCVEÎ 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 PGi téléchargeables auprès du serveur de sécurisation SERVSEC sont des fichiers sources en langage eBPF, notés PGsi.
Dans un autre mode de réalisation décrit ici, les programmes de mitigation PGi téléchargeables auprès du serveur de sécurisation SERVSEC sont des fichiers objets notés PG°i obtenus par compilation de fichiers sources PGsi 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 IDFÎ d'un programme de mitigation PGi comporte :
- dans un champ « IDVUL », l'identifiant IDCVEÎ de la vulnérabilité que ce programme peut mitiger ; et
- dans une structure « META_PG » des métadonnées du programme de mitigation PGi. Dans le mode de réalisation décrit ici, les métadonnées du programme de mitigation PGi 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 PGi peut faire appel à au moins une fonction de support (ou dépendance, en anglais « helper ») HLPy.
Dans l'exemple de réalisation décrit ici, lorsqu'un programme PGi fait appel à au moins une fonction de support HLPy :
- le fichier de description IDFÎ comporte, dans une structure « METAJHLP » des métadonnées de cette fonction de support HLPy ; et
- ces fonctions de support HLPy peuvent être téléchargées auprès du serveur de sécurisation SERVSEC.
Dans le mode de réalisation décrit ici, les métadonnées META_HLP d'une fonction de support HLPy 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 oeuvre un procédé d'installation conforme à l'invention et dont les principales étapes sont représentées sous forme d'ordinogramme à la figure 2.
Dans l'exemple décrit ici, l'espace utilisateur USR comporte :
- un processus p0() et deux conteneurs Cl, 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 Fl installée dans le container Cl de l'espace utilisateur USR. Dans l'exemple décrit ici, cette fonction logicielle Fl met en oeuvre un unique processus pl 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 Fl était vulnérable et que cette vulnérabilité possède l'identifiant unique IDcvEk.
Au cours d'une étape F10 du procédé d'installation, le module d'installation MINST envoie une requête REQ au serveur SRVSEC, cette requête REQ comportant l'identifiant de vulnérabilité IDcvEk.
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 IÜFk est associé à l'identifiant de vulnérabilité IDcvEk dans la base de données BD.
Ce fichier de description IÜFk est représenté à la figure 3.
Dans l'exemple de réalisation décrit ici, le fichier de description IÜFk comporte :
- dans le champ « IDVUL », l'identifiant IDcvEk de la vulnérabilité;
- dans la structure « META_PG », les métadonnées d'un programme PGk de mitigation de la vulnérabilité IDcvEk ; et
- dans la structure « META_HLP » les métadonnées de deux fonctions de support HLPkl et HLPk2 appelées par le programme PGk.
Dans l'exemple de la figure 3, les métadonnées META_PG du programme de mitigation PGk comportent : la métadonnée « NP » correspondant au nom PGk de ce programme ; et
- la métadonnée « HK » correspondant au point de déclenchement du programme PGk constitué ici par l'appel système d'ouverture de fichier open.
Dans l'exemple de la figure 3, les métadonnées META_HLP de la fonction de support HLPkl comportent :
- la métadonnée « NH » correspondant au nom HLPkl 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 figure 3, 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 HLPkl et HLPk2 nécessaires à l'exécution du programme de mitigation PGk et identifiées dans le fichier de description IÜ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 manuel Linux (par exemple à l'adresse https://man7.org/linux/man- pages/man5/sysfs.5.html).
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 HLPkl 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 PGk identifié dans le fichier de description IÜ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
Dans le mode de réalisation décrit ici, ce programme (noté PG¾ 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 PGk.
Au cours d'une étape F60, le programme de mitigation PGk 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 PGEk. 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 HLPkl et HLPk2 est installée dans le noyau KER.
La figure 4 illustre un exemple de fichier d'en-tête HDF en supposant que seules les fonctions de support HLPkl et HLPk2 sont installées dans le noyau KER et que la fonction HLPkl 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 HLPkl 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 Ll, 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 « HLPkl », « 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 Ll, L2, ... correspondantes à chacune des fonctions de support installées dans le noyau KER, une ligne :
# define fnsup_stat(fs_id, h, pejd, arg) fnsup_dyn( _ ID_##fs_id##_##h## _ , pejd, arg)
L'homme du métier du logiciel comprend ainsi que si, par exemple, le fichier de mitigation PGk, comporte dans son code source l'instruction fnsup_stat(HLPkl, a0...65f, 4, arg), l'étape E60 d'édition de lien traduit cette instruction :
- dans un premier temps en fnsup_dyn( _ ID_HLPkl_a0...65f _ , 4, arg),
- puis dans un deuxième temps, en fnsup_dyn(0, 4, arg), car dans l'exemple de la figure 4, en ligne
Ll, _ ID_HLPkl_a0...65f _ est défini à 0 où 4 correspond au point d'entrée à appeler dans la fonction support HLPkl.
La forme exécutable du programme de mitigation PGk, 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 HLPi 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 fsjd, valorisé à « 0 » dans cet exemple ;
- un point d'entrée pejd dans la fonction support, valorisé à 4 dans cet exemple ; et
- des arguments valorisés ici à arg.
Conformément à ce mode de réalisation, 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 fsjd de fonction de support dans une table TB du noyau KER.
Dans l'exemple de la figure 1, 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 HLPkl 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 H 10) auprès du serveur 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 PGk 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é PG°k) 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 figure 3, et génère en plus du code objet PG°k, 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 fsjd 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 PG°k, 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,i de la kième fonction de support.
Il est important de rappeler que dans cet exemple, le programme de mitigation PGk vise à mitiger la vulnérabilité de la fonction Fl uniquement et plus précisément à bloquer les effets de l'appel système d'ouverture de fichier open() par le processus pl() de cette fonction Fl.
A cet effet, et dans le mode de réalisation décrit ici, l'invention met en oeuvre 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 Fl dans le container Cl 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 PGk.
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 pO est associé respectivement à des espaces de nommage différents ENNETWORKO (pour l'espace Network), ENIPCO (pour IPC), ENIPDO (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.
Dans l'exemple décrit ici, le processus p2() appelle, comme le processus pl(), l'appel système open() d'ouverture de fichier et l'appel système send() d'envoi de paquets.
Dans l'exemple de la figure 1, 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(), pl() 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é ENSECUREO, le container Cl 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 figure 5 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 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é 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 PGk qui vient d'être généré pour mitiger la vulnérabilité IDcvEk de la fonction Fl, par compilation et édition de liens au cours des étapes F50 et F60. Le programme de mitigation PGk 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 fsjd 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 pl() 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 figure 6.
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 7 représente sous forme d'ordinogramme les principales étapes d'un procédé 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.
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 pl() de la fonction Fl 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 pl().
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 pl(), 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 PGk 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 PGk de sorte qu'il ne mitige que la vulnérabilité CVEk de la fonction Fl.
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 figure 8 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. 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

Claims

REVENDICATIONS
[Revendication 1] Procédé d'installation d'un programme de mitigation (PGk) dans le noyau (KER) d'un équipement informatique (EQ) pour mitiger une vulnérabilité susceptible d'affecter une fonction à protéger (Fl) 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 (IDCVEQ de ladite vulnérabilité à un serveur de sécurisation (SRVSEC) ;
- une étape (F20) d'obtention, en réponse à la requête (REQ) d'un fichier (IDFQ de description dudit programme (PGk) ;
- une étape (F40, F50) d'obtention d'un code objet (PG°k) du programme de mitigation (PGk) identifié dans ledit fichier de description (IDFQ ;
- une étape (F60) d'édition de lien pour résoudre au moins un symbole du code objet (PG°k) afin de générer un code exécutable (PG¾ dudit programme de mitigation (PGk) spécifique audit équipement (EQ) ; et
- une étape (F70) d'installation du code exécutable (PGEK) 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 (Fl).
[Revendication 2] 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¾ dudit programme de mitigation à partir d'une adresse comprise dans ledit fichier de description (IDFk) ; et
- une étape (F50) de compilation dudit code source (PG¾ pour obtenir ledit code objet (PG°k).
[Revendication 3] Procédé selon la revendication 2 dans lequel le code source est un programme en langage eBPF.
[Revendication 4] 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°k) à partir d'une adresse comprise dans ledit fichier de description (IDFk).
[Revendication 5] Procédé d'installation selon l'une quelconque des revendications 1 à 4 dans lequel ledit fichier de description (IDFQ comporte l'identifiant d'au moins une fonction de support (HLPi ) pouvant être appelée par ledit programme de mitigation (PGk) lorsqu'il est exécuté par un processeur (10) dudit équipement.
[Revendication 6] 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).
[Revendication 7] 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 (HLPi, j) compris dans ledit fichier de description (IDFk).
[Revendication 8] Procédé d'installation selon l'une quelconque des revendications 5 à 7 dans lequel le code source (PG¾ du programme de mitigation (PGk) comporte une fonction statique (fnsup_stat) pour appeler ladite fonction de support (HLPi ), 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.
[Revendication 9] 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 (HLPy) par un index représentatif de l'emplacement de la fonction de support (HLPi, j) dans le noyau de l'équipement.
[Revendication 10] Procédé d'installation selon la revendication 9 dans lequel ledit identifiant unique comporte un haché de la fonction de support (HLPi ).
[Revendication 11] 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 (PGk) 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 (pl) de ladite fonction à protéger (Fl), et
- ledit noyau (KER) met en oeuvre un procédé de sécurisation pour sécuriser un appel système déclenché par un processus courant (pl) 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 (pl) ;
- 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é.
[Revendication 12] Module (MINST) d'installation d'un programme de mitigation (PGk) dans le noyau (KER) d'un équipement informatique (EQ) pour mitiger une vulnérabilité susceptible d'affecter une fonction à protéger (Fl) 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 (IDcvEk) de ladite vulnérabilité à un serveur de sécurisation (SRVSEC) ;
- un sous-module (MF20) d'obtention, en réponse à la requête (REQ) d'un fichier (IDFk) de description dudit programme (PGk) ;
- un sous-module (MF40, MF50) d'obtention d'un code objet (PG°k) du programme de mitigation (PGk) identifié dans ledit fichier de description (IDFk) ;
- un sous-module (MF60) d'édition de lien pour résoudre au moins un symbole du code objet (PG°k) afin de générer un code exécutable (PG¾ dudit programme de mitigation (PGk) spécifique audit équipement (EQ) ; et
- un sous-module (MF70) d'installation du code exécutable (PGEK) 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 (Fl).
[Revendication 13] Equipement (EQ) comportant un espace utilisateur (USR), un noyau (KER) et un module (MINST) selon la revendication 12 pour installer un programme de mitigation (PGk) dans le noyau (KER) pour mitiger une vulnérabilité susceptible d'affecter une fonction à protéger (Fl) s'exécutant dans l'espace utilisateur (USR), cet équipement comportant :
- un module (MF70) d'enregistrement dudit programme de mitigation (PGk) 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 (pl) de ladite fonction à protéger (Fl),
- des moyens (GAS, ICS, LSM1) dudit noyau (KER) pour sécuriser au moins un appel système déclenché par un processus courant (pl) 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 (pl) ;
- 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é.
EP22710693.7A 2021-03-02 2022-02-24 Procede et module d'installation d'un programme de mitigation dans le noyau d'un equipement informatique Pending EP4302213A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2102026A FR3120455A1 (fr) 2021-03-02 2021-03-02 Procédé et module d’installation d’un programme de mitigation dans le noyau d’un équipement informatique.
PCT/FR2022/050340 WO2022184998A1 (fr) 2021-03-02 2022-02-24 Procede et module d'installation d'un programme de mitigation dans le noyau d'un equipement informatique

Publications (1)

Publication Number Publication Date
EP4302213A1 true EP4302213A1 (fr) 2024-01-10

Family

ID=76523025

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22710693.7A Pending EP4302213A1 (fr) 2021-03-02 2022-02-24 Procede et module d'installation d'un programme de mitigation dans le noyau d'un equipement informatique

Country Status (5)

Country Link
US (1) US20240152602A1 (fr)
EP (1) EP4302213A1 (fr)
CN (1) CN116964577A (fr)
FR (1) FR3120455A1 (fr)
WO (1) WO2022184998A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116861411B (zh) * 2023-06-05 2024-06-25 北京连山科技股份有限公司 基于Seccomp机制的安全沙箱数据保护方法及系统
US12355770B2 (en) * 2023-10-03 2025-07-08 strongDM, Inc. Identity and activity based network security policies
US12242599B1 (en) 2024-09-27 2025-03-04 strongDM, Inc. Fine-grained security policy enforcement for applications
US12348519B1 (en) 2025-02-07 2025-07-01 strongDM, Inc. Evaluating security policies in aggregate
US12432242B1 (en) 2025-03-28 2025-09-30 strongDM, Inc. Anomaly detection in managed networks
US12603921B1 (en) 2025-11-19 2026-04-14 strongDM, Inc. Indexing entities and attributes for policy enforcement

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1207454A1 (fr) * 2000-11-15 2002-05-22 International Business Machines Corporation Système de temps d'exécution pour Java avec identificateurs de liaison modifiés
CN1610887A (zh) * 2001-12-31 2005-04-27 大本营安全软件公司 计算机脆弱性自动解决方案系统
US8984644B2 (en) * 2003-07-01 2015-03-17 Securityprofiling, Llc Anti-vulnerability system, method, and computer program product
US7945958B2 (en) * 2005-06-07 2011-05-17 Vmware, Inc. Constraint injection system for immunizing software programs against vulnerabilities and attacks
US8468595B1 (en) * 2006-03-22 2013-06-18 Trend Micro Incorporated Content filtering prior to data encryption
US8352925B2 (en) * 2007-01-16 2013-01-08 Oracle America, Inc. Mechanism for enabling a set of code intended for a first platform to be executed on a second platform
US7845006B2 (en) * 2007-01-23 2010-11-30 International Business Machines Corporation Mitigating malicious exploitation of a vulnerability in a software application by selectively trapping execution along a code path
US8893298B2 (en) * 2011-02-11 2014-11-18 Mocana Corporation Network linker for secure execution of unsecured apps on a device
US20130347104A1 (en) * 2012-02-10 2013-12-26 Riverside Research Institute Analyzing executable binary code without detection
US9043903B2 (en) * 2012-06-08 2015-05-26 Crowdstrike, Inc. Kernel-level security agent
US9292693B2 (en) * 2012-10-09 2016-03-22 International Business Machines Corporation Remediation of security vulnerabilities in computer software
CN105354045A (zh) * 2014-08-21 2016-02-24 中兴通讯股份有限公司 补丁的制作方法及装置、补丁的激活方法及装置
JP6415353B2 (ja) * 2015-03-02 2018-10-31 キヤノン株式会社 情報処理方装置、情報処理装置の制御方法、およびコンピュータプログラム
CN105893850B (zh) * 2016-03-30 2017-12-15 百度在线网络技术（北京）有限公司 漏洞修复方法和装置
DE112018004464T5 (de) * 2017-11-06 2020-05-20 Intel Corporation Technologien zur Programmierung flexibler, beschleunigter Netzwerk-Pipelines unter Verwendung von eBPF
US11979422B1 (en) * 2017-11-27 2024-05-07 Lacework, Inc. Elastic privileges in a secure access service edge
US11544383B2 (en) * 2018-03-29 2023-01-03 Red Bend Ltd. Method for runtime mitigation of software and firmware code weaknesses
US10984098B2 (en) * 2018-04-06 2021-04-20 Palo Alto Networks, Inc. Process privilege escalation protection in a computing environment
CN112906008B (zh) * 2018-11-15 2023-07-25 百度在线网络技术（北京）有限公司 内核漏洞修复方法、装置、服务器及系统
US11232206B2 (en) * 2019-04-23 2022-01-25 Microsoft Technology Licensing, Llc Automated malware remediation and file restoration management
US10747875B1 (en) * 2020-03-19 2020-08-18 Cyberark Software Ltd. Customizing operating system kernels with secure kernel modules

Also Published As

Publication number Publication date
FR3120455A1 (fr) 2022-09-09
US20240152602A1 (en) 2024-05-09
CN116964577A (zh) 2023-10-27
WO2022184998A1 (fr) 2022-09-09

Similar Documents

Publication Publication Date Title
EP4302213A1 (fr) Procede et module d'installation d'un programme de mitigation dans le noyau d'un equipement informatique
EP4154141A1 (fr) Procede de securisation d'un appel systeme, procede de mise en place d'une politique de securite associee et dispositifs mettant en oeuvre ces procedes
US10055576B2 (en) Detection of malicious software packages
US9727352B2 (en) Utilizing history of changes associated with software packages to manage computing systems
KR101238572B1 (ko) 신뢰 환경을 지원하기 위한 컴퓨터 판독가능 구성요소의자동 업데이트
WO2015121418A2 (fr) Procédé de déploiement d'un ensemble d'application(s) logicielle(s)
JP2004502233A (ja) 共有名を用いてコンポーネントにセキュリティを提供するシステムおよび方法
US8843903B1 (en) Process tracking application layered system
US20240232350A1 (en) Detection of suspicious objects in customer premises equipment (cpe)
US20140090063A1 (en) System and method for inhibiting the processing of new code modules by an outdated runtime environment
EP4487230B1 (fr) Procédé et module de détection de tentatives d'attaques informatiques dans un parc d'ordinateurs
FR3125609A1 (fr) Mise en partage d’une fonction d’une application définie en langage orienté objet
WO2021130420A1 (fr) Procédé et dispositif mettant en œuvre ce procédé pour générer et installer un code exécutable dans la mémoire d'un noyau d'une machine virtuelle depuis un hyperviseur
EP2791794B1 (fr) Procede de gestion d'une application referencee par un dispositif
WO2023222330A1 (fr) Procédé et module de détection de vulnérabilités informatiques dans un parc d'ordinateurs
EP2284751B1 (fr) Procédé de traçabilité et d'imputabilité dynamiques des échanges dans un environnement ouvert de type internet
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
WO2025132515A1 (fr) Procédé d'optimisation du dimensionnement d'une infrastructure de virtualisation à une charge de service
FR2888958A1 (fr) Procede, systeme et produit de programme d'ordinateur d'execution de programmes d'ordinateurs surs, sur un terminal non sur
FR2911022A1 (fr) Procede permettant d'imposer une politique de securite a une application telechargeable accedant a des ressources du reseau
HK1247691B (zh) 应用程序升级方法、装置及设备

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230928

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20251112