EP4154141A1

EP4154141A1 - Method for securing a system call, method for implementing an associated security policy and devices for carrying out such methods

Info

Publication number: EP4154141A1
Application number: EP21732967.1A
Authority: EP
Inventors: Maxime BELAIR; Sylvie Laniepce
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2020-05-20
Filing date: 2021-05-18
Publication date: 2023-03-29
Also published as: FR3110726A1; CN115917539A; US20230195884A1; WO2021234267A1

Abstract

Method for securing a system call, method for implementing an associated security policy and devices for carrying out such methods. The securing method secures at least one system call triggered by a current process of a user space of a software system. Said method is implemented by a kernel of the software system before executing at least one operation triggered by the at least one system call and comprises: a step (E30) of obtaining at least one namespace of the kernel, the namespace being dedicated to the security management associated with the current process; a step (E50) of executing a security policy associated with the operation and recorded in an area (ZPS) of the kernel (KER), which area is defined in the namespace; a step (E30) of obtaining at least one namespace (ENSECURE0) dedicated to the security management and ancestor of the namespace (ENSECURE1) of the current process (pl); a step (E50) of executing a security policy associated with the operation and recorded in an area (ZPS) of the kernel (KER) defined in the ancestor namespace; and a step of processing the system call according to a result (RET) of the executions.

Description

Method for securing a system call, method for setting up an associated security policy and devices implementing these methods

The invention relates to the general field of securing computer programs and more particularly to that of securing the system calls of a kernel by the processes of a software stack running in a user space.

In this document, the protection of a system call consists more particularly in protecting the accesses (read / create / modify / delete ...) to sensitive kernel resources (inodes, files, ...) which can be triggered in the code of the system call from the user space, for example to manage sensitive operations of opening a file, sending a package, creating an "inode", ...

More precisely, this protection consists in checking, just before access to these sensitive resources, whether the access can be validated.

The invention finds a preferred but non-limiting application in Linux-type environments.

In the current state of the art, the LSM (Linux Security Module) infrastructure is the standard means of improving the security of a software stack in a Linux environment, and in particular access to sensitive kernel resources. It makes it possible to set up in the form of Linux security modules additional security policies to Discretionary Access Control (DAC), which are in particular:

- mandatory access control (Mandatory Access Control - MAC), in particular offered by the AppArmor module;

- Role-Based Access Control (RBAC), notably offered by the SELinux module; and

- integrity control, in particular offered by the IMA module.

In a manner known to those skilled in the art, these policies are applied at the kernel level in “hooks” (primitives allowing the LSM modules to execute arbitrary “pieces of code” during sensitive operations (opening a file, receiving a file). network packet, ...)).

Today there are LSMs that allow you to define and apply differentiated security policies for different software stacks in user space. However, these modules are difficult to maintain because they integrate both the security policy itself and its implementation. In addition, these LSMs enforce security policies by process or by process hierarchy. In this case, it is possible that an elevation of privilege will occur. For example, a process may have greater rights than those of the process that requested its creation because it inherits the rights of the process that created it. The latter is not in the hierarchy of processes of the one who has requested creation when the process creation is done through another process with which the requesting process is not related. In this case, the policies of the requesting process are not applied to the created process, which is undesirable from a security perspective.

One of the aims of the invention is to remedy shortcomings / drawbacks of the state of the art and / or to make improvements thereto.

More precisely, and according to a first aspect, the invention relates to a method for securing at least one system call triggered by a current process of a user space of a software system. This method is implemented by a kernel of the software system before executing at least one operation triggered by said at least one system call and comprises:

a step of obtaining at least one namespace of the kernel dedicated to security management associated with the current process;

a step for determining whether said at least one namespace includes a security policy associated with said operation and recorded in a zone of the kernel;

- a step of execution of the security policy; and

a step of processing the system call as a function of a result of this execution.

Thus, and in general, the invention proposes a mechanism allowing a process or a set of processes in the user space to define its own security policies to be implemented by the kernel.

The invention finds a preferred application in the Linux environment but can be applied to any operating system offering a mechanism for isolating resources by namespace. Indeed, the invention proposes to define a new namespace dedicated to security management and to define the security policies in these namespaces.

Unlike the LSM modules of the state of the art, this securing mechanism proposes associating the security policies with a namespace of the kernel instead of integrating the policy with the LSM module itself. This characteristic makes it possible very advantageously to benefit from all the mechanisms for managing the namespaces of the kernel.

According to a second aspect, the invention relates to a method for setting up a security policy, this method being implemented by a software stack of a user space of a software system to secure at least one system call likely to to be triggered by a process in the software stack. This method comprises a step of loading the security policy into an area of the core of said system, said security policy being associated with a namespace dedicated to security management associated with an operation capable of being triggered by said at least one. a system call of this process. Thus, and very advantageously, the security policy can be loaded by the software stack in the kernel, including when the latter does not benefit from privileged administration rights. This characteristic is particularly advantageous because the LSMs modules of the current state of the art require that the policies be put in place by an entity of the user space having administration rights.

The invention is also aimed at a device comprising a user space and a kernel, the user space comprising at least one process capable of triggering at least one system call of the kernel. This device is characterized in that:

the kernel comprises a security control infrastructure and a security module, this infrastructure being configured to execute the security module before executing at least one operation triggered by the system call;

- said security module being configured for:

- Obtain at least one namespace of the kernel dedicated to the security management associated with the process;

determining whether said at least one namespace includes a security policy associated with the operation and recorded in a zone of said kernel; and

- execute said at least one security policy.

In one embodiment, the method (or the device) for securing at least one system call 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.

More precisely, in this embodiment, the method comprises:

- a step of obtaining the name space (s) dedicated to security management and ancestor (s) of the namespace of the current process;

a step for determining whether this or these name space (s) include (s) a security policy associated with the operation and recorded in a zone of the kernel;

- a stage of execution of this security policy; and

In one embodiment of the method for setting up a proposed security policy, the software stack is a container and the loading of the security policy is defined by an instruction from a configuration file of the container. This configuration file can, for example, comply with the specifications defined by the OCI (Open Container Initiative) or a file of type Dockerfile. Remember that a Dockerfile type file is a text file that contains the commands necessary for generating the image of a container.

In a particularly advantageous manner, the security policies can be loaded by the software stack or by the “hot” container, that is to say during the execution of the container.

Thus, the operation triggered by a system call of the current process causes the execution of the security policy (s) associated with this operation in the namespace of this process, but also in the spaces of naming ancestors of the namespace of this process, if they exist.

Thus, and in particular, the processes of a container inherit the security policies defined in the ancestor namespaces. The process to which the security policy applies cannot have rights greater than those defined by the security policy (s) defined in the ancestor namespaces.

In this sense, it can be said that the proposed method makes it possible to stack personalized security policies for the processes of a namespace.

In a particular embodiment, the software stack or the user space container constructs an executable code which contains its own security policies applicable to particular operations (opening a file, receiving a network packet, etc.). This code can be loaded at runtime (ie dynamically) through a system interface to the kernel. It is then executed by the kernel when these operations (or events) occur for a process belonging to this container. Since this code is not necessarily executed by a trusted (potentially malicious) process, it should not be able to interfere with the rest of the system or the kernel. Thus, the security policies are only applied if they actually refer to the container at the origin of the policy applicable to the event.

Advantageously, since it is possible for a software stack to be compromised, a security policy cannot be disabled or modified from the user space, in particular by a software stack or a container belonging to a namespace for which this policy was defined.

In a particular embodiment, the proposed securing method comprises a step of deleting at least one security policy by the kernel if this security policy is not included in a namespace dedicated to security associated with the. minus an active user-space process.

In a particular embodiment, the proposed securing method comprises a step for determining whether the system call is associated with a sensitive operation and the securing method is implemented only for sensitive operations (file opening, sending package, execution of a function, ...). This determination can in particular be carried out by the kernel system call manager. In one embodiment of the proposed security method, the processing step consists in executing the operation if the result of the execution of said at least one security policy does not detect any security problem and in triggering a security action if the result of the execution of said at least one said security policy detects at least one security problem.

In one embodiment of the proposed securing method, the security action comprises the destruction of the current process.

In one embodiment of the proposed securing method, a security policy is a file in binary language obtained by compiling a program in eBPF language (for “Extended Berkeley Packet Filter”).

As is known, this language is deliberately limited in terms of functionalities (no loop, no pointer arithmetic, no direct access to kernel structures, ...) but has strong security properties so that it is incapable of attacking 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 enables a software stack to set up security policies without compromising the security of the system. It allows in particular the application of hardened policies after initialization of the software stack to subsequently block behaviors which would only be acceptable on initialization.

The possibilities offered by the eBPF language being limited, in one embodiment of the method for setting up a proposed security policy, at least one security policy calls at least one support function external to this policy and loaded in a dedicated kernel area by a user space entity with administrative rights.

These support functions (in English "helpers") can be loaded "hot", ie during the execution of the kernel. They can be called by an eBPF security policy to perform critical processing such as access to kernel structures for the eBPF code. These support functions can only be written by an entity with administration rights and are not subject to the limitations related to the eBPF verifier.

This particular embodiment makes it possible, by deporting the critical accesses and complex processing operations to the support functions, the implementation by the containers of policies developed without compromising the security of the system and with low performance overheads.

In a particular embodiment, at least one support function is a dynamic function that can be executed independently of its position, this dynamic function being called by a static support function compiled with the kernel and called by the security policy. For more information on the concept of a code independent of its position (in English "position independent code ”), those skilled in the art can refer to the document available at the address https://fr.qwe.wiki/wiki/Position-independent_code.

In a particular embodiment, the method of setting up a proposed security policy comprises a step of analyzing a log file (better known under the term logs) comprising at least one result of the execution of a security policy executed by a security method as mentioned above.

The securing method and the method for implementing a security policy proposed are implemented by computer programs.

Consequently, the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a device or more generally in a computer. This program includes instructions allowing the implementation of a method as described above.

This program can 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 a partially compiled form, or in any other. desirable shape.

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. For example, 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 floppy disk or a disk. hard, or flash memory.

On the other hand, the information or recording medium can be a transmissible medium such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.

The proposed computer program can in particular be downloaded from an Internet type network.

Alternatively, the information or recording medium can 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 above.

Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate an exemplary embodiment thereof without any limiting nature. In the figures: - Figure 1 shows a device in accordance with a particular embodiment and the main steps of a method of setting up a security policy in accordance with a particular embodiment;

FIG. 2 represents a process table that can be used in a particular embodiment;

FIG. 3 represents a control table that can be used in a particular embodiment;

FIG. 4 represents in the form of a flowchart the main steps of a securing method in accordance with a particular embodiment.

FIG. 1 represents a device 100 in accordance with the invention. In the exemplary embodiment described here, this device 100 has the hardware architecture of a computer. It comprises in particular a processor 10, a random access memory of the RAM 11 type, a read-only memory of the ROM type 12, and communication means 13.

This device comprises a SYS software system, this system comprising a KER kernel or operating system, and a USR user space. In the embodiment described here, the KER operating system is of the Linux type (registered trademark).

In the embodiment described here, the user space USR comprises a process p0 (), two software stacks of container type C1, C2 and an administration tool ADM. The process p0 () and the software stacks C1, C2 are associated with user level rights and the administration tool ADM with administrator level rights.

In the exemplary embodiment described here, the software stacks C1, C2 of the user space USR are containers, each comprising a set of processes isolated from the rest of the software system SYS.

In this example, the creation of containers C1 and C2 is requested by the process p0 ().

It is recalled that the processes of the USR user space can be isolated thanks to the known mechanism of namespaces. As is known, the Linux operating system offers, in the current state of the art, 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.

In the example of figure 1:

- the process pO is associated respectively with namespaces ENNETWORKO (for the Network space), ENIPC0 (for IPC), ENPID0 (for PID), ENUserO (for User) ...;

- the processes of the container C1, in this case the process pl (), are associated with different namespaces ENNETWORK1, ENIPC1, ENIPD1, ENUserl; and - the processes of container C2, in this case the process p2 (), are associated with different namespaces ENNETWORK2, ENIPC2, ENIPD2, ENUser2.

Some SYS system processes may call on KER kernel system functions. The KER kernel includes a GAS system call manager in which these system calls are implemented.

The invention proposes a security management mechanism for securing system calls triggering sensitive operations within the meaning of Linux Security Modules (LSM).

In the embodiment described here, the open file oper_open (), send packet oper_send () and function execute oper_exec () operations are considered to be sensitive operations.

In the example of figure 1 the process pl of the container C1 and the process p2 of the container C2 call:

- the open () system call for opening a file which generates, during its execution, the sensitive operation oper_open (); and

- the send () system call for sending packets which generates during its execution, the sensitive operation oper_send ().

In the example of Figure 1, the pO process does not call the open () send (), exec () system calls.

In the embodiment described here, the invention proposes to use a new ENSECURE namespace dedicated to security management.

For example, the process pO is associated with the security management namespace ENSECUREO, the container C1 is associated with the security management namespace ENSECURE1 and the container C2 is associated with the namespace ENSECURE2.

FIG. 2 represents in detail a TABPID table of the processes p0, p1 and p2 stored in the kernel KER. In the KER kernel, a process consists of a structure comprising several fields making it possible to manage the life cycle of the process such as its process identifier PID, its flags, its stack, etc.

In kernel space, the data structure corresponding to the current process can be recovered using the current instruction (see step E30, FIG. 4).

This structure also has an nsproxy field which has pointers to namespaces. In accordance with this particular embodiment, this nsproxy field includes an ENSECURE pointer to the namespace dedicated to the management of the security associated with the process. This namespace defines a data structure which includes in particular the security policy defined in eBPF language. In the embodiment described here, these structures are recorded in a zone of security policies ZPS of the KER kernel. The ENSECURE namespace of a process has a link to the ENSECURE namespace of the parent of the namespace of that process. In the example described here, ENSECURE1 and ENSECURE2 associated respectively with the containers C1 and C2 point to the namespace ENSECUREO of the process p0.

The ENSECURE namespaces therefore form a tree.

In a manner known to those skilled in the art, a process can change the namespace to join the namespace of one of its child processes, for example by using the unshare () command.

From the USR user space, it is possible to access the identifier of a namespace but it is not possible to modify its structure. This feature advantageously makes it possible to prevent any modification or deactivation of a security policy by a container.

In the exemplary embodiment described here, it is assumed that the process p0 () has defined a security policy PSOFp0 to secure calls to the sensitive operation of opening the oper_open () file. It is assumed that it has not defined a security policy to secure calls to the sensitive packet send operation on the oper_send () network.

In the embodiment described here, the processes of a container inherit the security policies defined by all of its ancestor ENSECURE namespaces.

In the exemplary embodiment described here, it is assumed that the container C1 has defined its own security policy PSOFC1 to secure the calls by its processes, in this case pl (), to the sensitive operation of opening the oper_open file. (), in addition to the PSOFpO policy defined by the p0 () process.

It is assumed that the container C1 has defined a security policy PSTPC1 to secure the calls by its processes, in this case pl (), to the sensitive operation of sending a packet oper_send ().

It is assumed that the container C2 has not defined any own security policy. The p2 () process of this container inherits the PSOFpO security policy defined by the p0 () process to secure its calls to the sensitive open file operation. But it does not define any security function to check the sensitive packet send operation.

In the embodiment described here, each of the security policies PSOFp0, PSOFC1, PSTPC1 is defined by a software function in eBPF language compiled in binary. These security policies are recorded in the read only memory 12 of the device 100 and intended to be loaded into the security policy zone ZPS of the KER core.

This loading (step F10) can be done in different ways.

In the embodiment described here, the read only memory 12 comprises an OCI (Open Container Initiative) type configuration file for each container, namely a FOCIC1 configuration file for the C1 container and a FOCIC2 configuration file for the C2 container. . In a known manner, the OCI configuration of a container is specified under the name config.json and details the characteristics of the container to be created. This configuration file specifies in particular the files that the container must contain, its system interfaces, its namespaces, etc.

In the embodiment described here, the OCI configuration file of a container includes instructions for the container to load its security policies into the security policy zone ZPS of the KER kernel.

When a container is created, for example C1, the security policies PSOFC1 and PCTPC1 of the C1 container are copied from the read only memory 12 into a memory M1 of the C1 container. Once the C1 container is built, it is executed and executed. At execution, the security policies are transferred from the memory M1, into the ZPS area of the kernel.

The manual writing of the OCI configuration file can nevertheless prove to be complex, and in another embodiment of the invention, the loading of the security policy of a container in the KER core is defined by an instruction of a higher level container building method, for example the Dockerfile method.

In addition, loading a container-specific security policy into kernel memory can be done at any time during the container lifecycle, not just when it is initialized. In the embodiment described here, the code of the container C1 also includes load_ps () instructions making it possible to load a security policy in the form of an eBPF file compiled in binary form in the security policy zone ZPS of the KER kernel. This particular embodiment makes it possible in particular to load a new security policy which will be applied after the start of the container C1. This load_ps () function consists of opening the eBPF file included in the read only memory 12 and copying it to an interface with the KER kernel.

In the embodiment described here, the KER kernel comprises an ICS security control infrastructure for managing the Linux security modules, a Linux security module LSM1 in accordance with the invention and possibly at least one other security module LSM2, for example example, a SELinux module or an AppAmor module as mentioned previously.

In the exemplary embodiment described here, the KER kernel includes a TABCTR control table which defines, for each sensitive OPS operation (opening a file, sending a packet on the network, etc.) whether the security module LSM1 wants to control or not these sensitive operations. This TABCTR table is shown in Figure 3.

In the verification example described here, it is assumed that the security module LSM1 only wishes to verify the sensitive operation of opening files.

FIG. 4 represents in the form of a flowchart the main steps of a securing method in accordance with a particular embodiment. In the embodiment described here, this method is implemented by the GAS system call manager, the ICS security control infrastructure (LSM framework in English) and by the LSM1 security module. In the exemplary embodiment described here, the GAS system call manager determines, during a step E10, whether a system call triggered by a process in the user space must perform a sensitive operation. If so, it triggers the KER kernel ICS security monitoring infrastructure.

If the ICS infrastructure determines that the sensitive operation OPS listed in the TABCTR table is supervised by the security module LSM1, the ICS infrastructure triggers the execution of the security module LSM1 during a step E20.

In the exemplary 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, like 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 security module LSM2, outside the context of the invention, for example SELinux and an AppAmor module.

During a step E30, the security module LSM1 determines the namespace associated with the current process at the origin of this call. It uses the current process from the TABPID process table for this.

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.

During a step E40, the security module LSM1 determines whether the current namespace has defined one or more security policies to verify the validity of the sensitive operation.

If this is the case, the relevant security module 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.

In this case, during the first iteration, the security policy PSOFC1 is executed. This security policy returns a result RET of this execution to the security module LSM1.

In the embodiment described here, a security policy, and in particular the PSOFC1 security policy, returns a negative RET result if it detects a security problem (for example reflecting malicious or abnormal behavior) and a positive result if it does not detect any security problem.

If this RET value is positive, the security module determines, if it exists, the parent namespace of the namespace of the current process (step E60) and the loop is repeated.

In this case, during the second iteration the security policy PSOFpO of the ENSECUREO namespace of the process pO is executed. If a security policy returns a negative RET result, the security module records this result in a KER kernel FLOG log file during a step E70 and sends this negative RET result to the security infrastructure ICS. This FLOG log file can be analyzed (step F30) by the administrator by means of the administration tool ADM.

When all the security policies of the entire namespace tree have been executed with a positive RET result, the LSM1 security module sends a positive RET result to the ICS security infrastructure (test E90).

In the embodiment described here, if the RET 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, a SELinux module and an AppAmor module.

In the embodiment described here, if the security infrastructure RET receives a negative RET result, the control infrastructure ICS triggers a security action AS during a step E80. This action can consist of destroying the process that initiated the call and raising an alert in the FLOG log file.

In the embodiment described here, 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.

For example, in the exemplary embodiment described here, as soon as the process pl dies, there is no longer any process in the SYS system whose namespace dedicated to security management is ENSECURE1 so that the PSOFC1 and PSTPC1 security policies can be destroyed.

In the embodiment described here, if a security policy is not included in a namespace dedicated to security associated with at least one active process of the user space, this security policy is deleted by the kernel.

In accordance with the invention, the security policies in compiled eBPF language can call functions of the KER kernel external to these policies, in order to implement critical operations which cannot be done directly by the security policy in eBPF language itself. -same. Such functions are known to those skilled in the art under the name of eBPF support functions (in English “Helper eBPF”).

In a particular embodiment of the invention, such an FSUP support function can be written by an administrator, for example in C language, then compiled like a conventional kernel module with GCC (in English “GNU Compiler Collection”) .

In the embodiment described here, this executable code is transformed so that it can be executed independently of its position according to the PIC (Position Independent Code) mechanism known to those skilled in the art. These dynamic FSUP support functions can be loaded (step F20) in a dedicated area of the kernel KER without interrupting the execution of the kernel.

Once loaded into the kernel, these dynamic FSUP support functions can be invoked by the eBPF code of a security policy using a single static FSUPSTAT support function.

Claims

1. Method for securing at least one system call triggered by a current process (pl) of a user space (USR) of a software system (SYS), said method being implemented by a kernel (KER) of said software system (SYS) before executing at least one operation triggered by said at least one system call, and comprising:

a step (E30) of obtaining at least one namespace (ENSECURE1) of the kernel (KER) dedicated to the security management associated with said current process (pl);

a step (E50) for executing a security policy defined in the namespace associated with said operation and recorded in a zone (ZPS) of said kernel (KER);

- a step (E30) of obtaining at least one namespace (ENSECUREO) dedicated to the security management and ancestor of the namespace (ENSECURE1) of said current process (pl);

a step (E50) for executing a security policy defined in the ancestor namespace associated with said operation and recorded in a zone of said kernel; and

a step of processing said system call as a function of a result (RET) of said executions.

2. A method of securing at least one system call according to claim 1, comprising a step (E10) for determining whether said operation is a sensitive operation.

3. A method of securing at least one system call according to any one of claims 1 to 2, wherein said processing step consists of executing said operation if the result of the execution of said at least one security policy does not. detects no security problem and to trigger (E80) a security action if the result of the execution of at least one said security policy detects a security problem.

4. A method of securing at least one system call according to claim 3, wherein said security action comprises the destruction of said current process (pl).

5. A method of securing at least one system call according to any one of claims 1 to 4, comprising a step of deleting at least one said security policy by said kernel (KER) if said security policy does not. is not included in a namespace dedicated to security associated with at least one active process of said user space (USR).

6. A method of setting up a security policy, said method being implemented by a software stack (C1) of a user space (USR) of a software system (SYS) to secure at least one system call. capable of being triggered by a process (pl) of said software stack (C1), said method comprising a step (F10) of loading said security policy into an area (ZPS) of a kernel (KER) of said system ( SYS), said security policy being defined in a namespace (ENSECURE1) of the kernel dedicated to security management associated with a operation capable of being triggered by said at least one system call of said process (pl), said namespace comprising a link to an ancestor namespace.

7. A method of setting up a security policy according to claim 6, in which said software stack (C1) is a container, said loading being defined by an instruction from a configuration file of said container (C1), said loading. configuration file (FOCIC1) conforming to the specifications defined by the OCI (Open Container Initiative) or a Dockerfile type file.

8. A method of setting up a security policy according to claim 6 or 7 wherein said at least one security policy calls at least one support function (FSUP) external to said policy and loaded (F20) in an area. dedicated kernel (KER) by an entity of said user space (USR) benefiting from administration rights.

9. A method of implementing a security policy according to claim 8 wherein said at least one support function (FSUP) is a dynamic function that can be executed independently of its position, this dynamic function (FSUP) being called by a function. of static support (FSUPSTAT) compiled with said kernel (KER) and called by said security policy.

10. A method of setting up a security policy according to any one of claims 6 to 9, comprising a step (F30) of analyzing a log file (FLOG) comprising at least one result (RET) d execution of a security policy executed by a securing method according to any one of claims 1 to 4.

11. A method according to any one of claims 1 to 10 wherein said at least one security policy is a binary language file obtained by compiling a program in eBPF language.

12. Device (100) comprising a user space (USR) and a kernel (KER), the user space (USR) comprising at least one process (pl) capable of triggering at least one system call of said kernel (KER), said device (100) comprising:

- said kernel (KER) comprises a security control infrastructure (ICS) and a security module (LSM1), said infrastructure (ISC) being configured to execute said security module (LSM1) before executing at least one triggered operation by said at least one system call;

- said security module (LSM1) being configured for:

- obtain at least one namespace (ENSECURE1) of the kernel (KER) dedicated to the security management associated with said process (pl);

- obtain at least one namespace (ENSECURE0) dedicated to security management and ancestor of the namespace of said current process;

- execute a security policy defined in the namespace associated with said operation and recorded in a zone (ZPS) of said kernel (KER); and executing a security policy defined in the ancestor namespace associated with said operation and recorded in a zone of said kernel.