WO2021234267A1 - 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 - Google Patents

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 Download PDF

Info

Publication number
WO2021234267A1
WO2021234267A1 PCT/FR2021/050860 FR2021050860W WO2021234267A1 WO 2021234267 A1 WO2021234267 A1 WO 2021234267A1 FR 2021050860 W FR2021050860 W FR 2021050860W WO 2021234267 A1 WO2021234267 A1 WO 2021234267A1
Authority
WO
WIPO (PCT)
Prior art keywords
security
kernel
namespace
security policy
ker
Prior art date
Application number
PCT/FR2021/050860
Other languages
English (en)
Inventor
Maxime BELAIR
Sylvie Laniepce
Original Assignee
Orange
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 filed Critical Orange
Priority to CN202180043947.9A priority Critical patent/CN115917539A/zh
Priority to EP21732967.1A priority patent/EP4154141A1/fr
Priority to US17/999,532 priority patent/US20230195884A1/en
Publication of WO2021234267A1 publication Critical patent/WO2021234267A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/53—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 executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • 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.
  • 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", ...
  • 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.
  • 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:
  • RBAC Role-Based Access Control
  • 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, 7)).
  • LSMs 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.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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:
  • 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.
  • the method comprises:
  • a step for determining whether this or these name space include (s) a security policy associated with the operation and recorded in a zone of the kernel;
  • 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.
  • OCI Open Container Initiative
  • a Dockerfile type file is a text file that contains the commands necessary for generating the image of a container.
  • 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.
  • 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.
  • 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.
  • the proposed method makes it possible to stack personalized security policies for the processes of a namespace.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the security action comprises the destruction of the current process.
  • a security policy is a file in binary language obtained by compiling a program in eBPF language (for “Extended Berkeley Packet Filter”).
  • 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.
  • 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.
  • 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.
  • 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.
  • this dynamic function being called by a static support function compiled with the kernel and called by the security policy.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • the KER operating system is of the Linux type (registered trademark).
  • 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.
  • 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.
  • the processes of the USR user space can be isolated thanks to the known mechanism of namespaces.
  • 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.
  • 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).
  • LSM Linux Security Modules
  • open file oper_open (), send packet oper_send () and function execute oper_exec () operations are considered to be sensitive operations.
  • the pO process does not call the open () send (), exec () system calls.
  • the invention proposes to use a new ENSECURE namespace dedicated to security management.
  • the process pO 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 namespace ENSECURE2.
  • FIG. 2 represents in detail a TABPID table of the processes p0, p1 and p2 stored in the kernel KER.
  • 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.
  • 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.
  • 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.
  • 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.
  • a process can change the namespace to join the namespace of one of its child processes, for example by using the unshare () command.
  • 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.
  • the processes of a container inherit the security policies defined by all of its ancestor ENSECURE namespaces.
  • 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.
  • 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 ().
  • 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.
  • 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.
  • 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.
  • OCI Open Container Initiative
  • 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.
  • 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.
  • 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.
  • the security policies are transferred from the memory M1, into the ZPS area of the kernel.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 4 represents in the form of a flowchart the main steps of a securing method in accordance with a particular embodiment.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the security policy PSOFC1 is executed. This security policy returns a result RET of this execution to the security module LSM1.
  • 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.
  • the security module determines, if it exists, the parent namespace of the namespace of the current process (step E60) and the loop is repeated.
  • 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.
  • the LSM1 security module sends a positive RET result to the ICS security infrastructure (test E90).
  • 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.
  • another LSM2 security module for example, a SELinux module and an AppAmor module.
  • 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.
  • 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.
  • this security policy is deleted by the kernel.
  • 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”).
  • 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”) .
  • 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.
  • PIC Position Independent Code
  • 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.
  • these dynamic FSUP support functions can be invoked by the eBPF code of a security policy using a single static FSUPSTAT support function.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Procédé de sécurisation d'un appel système, procédé de mise en place d'une politique de sécurité associée et dispositifs mettant en oeuvre ces procédés. Le procédé de sécurisation sécurise au moins un appel système déclenché par un processus courant d'un espace utilisateur d'un système logiciel. Ce procédé est mis en oeuvre par un noyau du système logiciel avant d'exécuter au moins une opération déclenchée par ledit au moins un appel système et comporte : une étape (E30) d'obtention d'au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus courant; une étape (E50) d'exécution d'une politique de sécurité associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) définie dans l'espace de nommage; une étape (E30) d'obtention d'au moins un espace de nommage (ENSECURE0) dédié à la gestion de sécurité et ancêtre de l'espace nommage (ENSECURE1) dudit processus courant (pl); une étape (E50) d'exécution d'une politique de sécurité associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) définie dans l'espace de nommage ancêtre; et une étape de traitement dudit appel système en fonction d'un résultat (RET) desdites exécutions.

Description

Procédé de sécurisation d'un appel système, procédé de mise en place d'une politique de sécurité associée et dispositifs mettant en oeuvre ces procédés
L'invention se rapporte au domaine général de la sécurisation des programmes informatiques et plus particulièrement à celui de la sécurisation des appels système d'un noyau par les processus d'une pile logicielle s'exécutant dans un espace utilisateur.
Dans ce document, la protection d'un appel système consiste plus particulièrement à protéger les accès (lecture/création/modification/suppression...) aux ressources sensibles du noyau (inodes, fichiers, ...) qui peuvent être déclenchés dans le code de l'appel système depuis l'espace utilisateur par exemple pour gérer les opérations sensibles d'ouverture d'un fichier, d'envoi d'un paquet, de création d'un « inode », ...
Plus précisément, cette protection consiste à vérifier, juste avant l'accès à ces ressources sensibles, si l'accès peut être validé.
L'invention trouve une application privilégiée mais non limitative dans les environnements de type Linux.
Dans l'état actuel de la technique, l'infrastructure LSM (Linux Security Module) est le moyen standard d'améliorer la sécurité d'une pile logicielle dans un environnement Linux, et en particulier l'accès aux ressources sensibles du noyau. Elle permet de mettre en place sous forme de modules de sécurité Linux des politiques de sécurité additionnelles au contrôle d'accès discrétionnaire (Discretionary Access Control - DAC) que sont en particulier :
- le contrôle d'accès obligatoire (Mandatory Access Control - MAC), notamment proposé par le module AppArmor ;
- le contrôle d'accès à base de rôle (Role-Based Access Control - RBAC), notamment proposé par le module SELinux ; et
- le contrôle d'intégrité, notamment proposé par le module IMA.
De façon connue de l'homme du métier, ces politiques sont appliquées au niveau noyau dans des « hooks » (primitives permettant aux modules LSM d'exécuter des « bouts de codes » arbitraires lors d'opérations sensibles (ouverture de fichier, réception de paquet réseau, ...)).
Il existe aujourd'hui des modules LSM qui permettent de définir et d'appliquer des politiques de sécurité différentiées pour différentes piles logicielles en espace utilisateur. Cependant, ces modules sont difficiles à maintenir car ils intègrent à la fois la politique de sécurité elle-même et sa mise en oeuvre. De plus, ces modules LSM appliquent des politiques de sécurité par processus ou par hiérarchie de processus. Dans ce cas, il est possible qu'une élévation de privilège se produise. Par exemple, un processus peut avoir des droits supérieurs à ceux du processus qui a demandé sa création car il hérite des droits du processus qui l'a créé. Ce dernier n'est pas dans la hiérarchie de processus de celui qui a demandé la création lorsque la création de processus se fait à travers un autre processus avec qui le processus demandeur n'a pas de lien de parenté. Dans ce cas, les politiques du processus demandeur ne sont pas appliquées au processus créé, ce qui n'est pas souhaitable sur le plan de la sécurité.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Plus précisément, et selon un premier aspect, l'invention concerne un procédé de sécurisation d'au moins un appel système déclenché par un processus courant d'un espace utilisateur d'un système logiciel. Ce procédé est mis en oeuvre par un noyau du système logiciel avant d'exécuter au moins une opération déclenchée par ledit au moins un appel système et comporte :
- une étape d'obtention d'au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus courant;
- une étape pour déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à ladite opération et enregistrée dans une zone du noyau ;
- une étape d'exécution de la politique de sécurité ; et
- une étape de traitement de l'appel système en fonction d'un résultat de cette exécution.
Ainsi, et d'une façon générale, l'invention propose un mécanisme permettant à un processus ou à un ensemble de processus de l'espace utilisateur de définir ses propres politiques de sécurité à mettre en oeuvre par le noyau.
L'invention trouve une application privilégiée dans l'environnement Linux mais peut être appliquée à tout système d'exploitation offrant un mécanisme d'isolation des ressources par espace de nommage (en anglais « Namespace »). En effet, l'invention propose de définir un nouvel espace de nommage dédié à la gestion de sécurité et de définir les politiques de sécurité dans ces espaces de nommage.
Contrairement aux modules LSM de l'état de la technique, ce mécanisme de sécurisation propose d'associer les politiques de sécurité à un espace de nommage du noyau au lieu d'intégrer la politique au module LSM lui-même. Cette caractéristique permet fort avantageusement de bénéficier de tous les mécanismes de gestion des espaces de nommage du noyau.
Selon un deuxième aspect, l'invention concerne un procédé de mise en place d'une politique de sécurité, ce procédé étant mis en oeuvre par une pile logicielle d'un espace utilisateur d'un système logiciel pour sécuriser au moins un appel système susceptible d'être déclenché par un processus de la pile logicielle. Ce procédé comporte une étape de chargement de la politique de sécurité dans une zone du noyau dudit système, ladite politique de sécurité étant associée à un espace de nommage dédié à la gestion de sécurité associé à une opération susceptible d'être déclenchée par ledit au moins un appel système de ce processus. Ainsi, et de façon très avantageuse, la politique de sécurité peut être chargée par la pile logicielle dans le noyau, y compris quand celle-ci ne bénéficie pas de droits privilégiés d'administration. Cette caractéristique est particulièrement avantageuse car les modules LSMs de l'état actuel de la technique imposent que les politiques soient mises en place par une entité de l'espace utilisateur ayant des droits d'administration.
L'invention vise aussi un dispositif comportant un espace utilisateur et un noyau, l'espace utilisateur comportant au moins un processus apte à déclencher au moins un appel système du noyau. Ce dispositif est caractérisé en ce que :
- le noyau comporte une infrastructure de contrôle de sécurité et un module de sécurité, cette infrastructure étant configurée pour exécuter le module de sécurité avant d'exécuter au moins une opération déclenchée par l'appel système;
- ledit module de sécurité étant configuré pour :
- obtenir au moins un espace de nommage du noyau dédié à la gestion de sécurité associé au processus;
- déterminer si ledit au moins un espace de nommage comporte une politique de sécurité associée à l'opération et enregistrée dans une zone dudit noyau ; et
- exécuter ladite au moins une politique de sécurité.
Dans un mode de réalisation, le procédé (ou le dispositif) de sécurisation d'au moins un appel système détermine si l'espace de nommage du processus courant comporte au moins un ancêtre. Si c'est le cas, le procédé (ou le dispositif) met en oeuvre pour chacun de ces espaces de nommage ancêtre, un traitement identique à celui mis en oeuvre pour l'espace de nommage associé au processus courant.
Plus précisément, dans ce mode de réalisation, le procédé comporte :
- une étape d'obtention du ou des espaces de nommage dédié(s) à la gestion de sécurité et ancêtre(s) de l'espace nommage du processus courant ;
- une étape pour déterminer si ce ou ces espace(s) de nommage comporte(nt) une politique de sécurité associée à l'opération et enregistrée dans une zone du noyau ;
- une étape d'exécution de cette politique de sécurité ; et
- une étape de traitement de l'appel système en fonction d'un résultat de cette exécution.
Dans un mode de réalisation du procédé de mise en place d'une politique de sécurité proposé, la pile logicielle est un conteneur et le chargement de la politique de sécurité est défini par une instruction d'un fichier de configuration du conteneur. Ce fichier de configuration peut par exemple être conforme à aux spécifications définies par l'OCI (Open Container Initiative) ou un fichier de type Dockerfile. On rappelle qu'un fichier de type Dockerfile est un fichier texte qui comporte les commandes nécessaires à la génération de l'image d'un conteneur.
De façon particulièrement avantageuse, les politiques de sécurité peuvent être chargées par la pile logicielle ou par le conteneur « à chaud », c'est-à-dire pendant l'exécution du conteneur.
Ainsi, l'opération déclenchée par un appel système du processus courant entraîne l'exécution de la ou les politique(s) de sécurité associée(s) à cette opération dans l'espace de nommage de ce processus, mais aussi dans les espaces de nommage ancêtres de l'espace de nommage de ce processus, s'ils existent.
Ainsi, et en particulier, les processus d'un conteneur héritent des politiques de sécurité définies dans les espaces de nommage ancêtres. Le processus sur lequel la politique de sécurité s'applique ne peut avoir des droits supérieurs à ceux définis par la ou les politiques de sécurité définies dans les espaces de nommage ancêtres.
En ce sens, il peut être dit que le procédé proposé permet d'empiler des politiques de sécurité personnalisées pour les processus d'un espace de nommage.
Dans un mode de réalisation particulier, la pile logicielle ou le conteneur de l'espace utilisateur construit un code exécutable qui contient ses propres politiques de sécurité applicables à des opérations particulières (ouverture de fichier, réception de paquet réseau, ...). Ce code peut être chargé à l'exécution (c'est-à-dire dynamiquement) à travers une interface système vers le noyau. Il est alors exécuté par le noyau quand ces opérations (ou événements) se produisent pour un processus appartenant à ce conteneur. Puisque ce code n'est pas forcément exécuté par un processus de confiance (potentiellement malveillant), il ne doit pas être en mesure d'interférer avec le reste du système ou le noyau. Ainsi, les politiques de sécurité ne sont appliquées que si elles se réfèrent bien au conteneur à l'origine de la politique applicable à l'évènement.
De façon avantageuse, puisqu'il est possible qu'une pile logicielle soit compromise, une politique de sécurité ne peut pas être désactivée ou modifiée depuis l'espace utilisateur, en particulier par une pile logicielle ou un conteneur appartenant à un espace de nommage pour lequel cette politique a été définie.
Dans un mode de réalisation particulier, le procédé de sécurisation proposé comporte une étape de suppression d'au moins une politique de sécurité par le noyau si cette politique de sécurité n'est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif de l'espace utilisateur.
Dans un mode de réalisation particulier, le procédé de sécurisation proposé comporte une étape pour déterminer si l'appel système est associé à une opération sensible et le procédé de sécurisation n'est mis en oeuvre que pour les opérations sensibles (ouverture de fichier, envoi de paquet, exécution d'une fonction, ...). Cette détermination peut notamment être effectuée par le gestionnaire d'appels système du noyau. Dans un mode de réalisation du procédé de sécurisation proposé, l'étape de traitement consiste à exécuter l'opération si le résultat de l'exécution de ladite au moins une politique de sécurité ne détecte aucun problème de sécurité et à déclencher une action de sécurité si le résultat de l'exécution de ladite au moins une dite politique de sécurité détecte au moins un problème de sécurité.
Dans un mode de réalisation du procédé de sécurisation proposé, l'action de sécurité comporte la destruction du processus courant.
Dans un mode de réalisation du procédé de sécurisation proposé, une politique de sécurité est un fichier en langage binaire obtenu par compilation d'un programme en langage eBPF (pour « Extended Berkeley Packet Filter »).
De façon connue, ce langage est volontairement limité en termes de fonctionnalités (pas de boucle, pas d'arithmétique de pointeur, pas d'accès direct aux structures noyau, ...) mais possède de fortes propriétés de sécurité de sorte qu'il est inapte à attaquer le reste du système.
Cette caractéristique permet avantageusement d'empêcher les attaques critiques, par exemple pour récupérer des informations, modifier l'intégrité ou la disponibilité du reste du système.
La technique proposée permet ainsi à une pile logicielle de mettre en place des politiques de sécurité sans compromettre la sécurité du système. Elle permet en particulier l'application de politiques durcies après l'initialisation de la pile logicielle pour bloquer ultérieurement des comportements qui ne seraient acceptables qu'à l'initialisation.
Les possibilités offertes par le langage eBPF étant limitées, dans un mode de réalisation du procédé de mise en place d'une politique de sécurité proposé, au moins une politique de sécurité appelle au moins une fonction de support externe à cette politique et chargée dans une zone dédiée du noyau par une entité de l'espace utilisateur bénéficiant de droits d'administration.
Ces fonctions de support (en anglais « helpers ») peuvent être chargées « à chaud », c'est à dire pendant l'exécution du noyau. Elles peuvent être appelées par une politique de sécurité eBPF pour réaliser des traitements critiques comme les accès aux structures noyau pour le code eBPF. Ces fonctions support ne peuvent être écrites que par une entité bénéficiant de droits d'administration et ne sont pas soumises aux limitations liées au vérifieur eBPF.
Ce mode de réalisation particulier permet, en déportant les accès critiques et les traitements complexes vers les fonctions support, la mise en place par les conteneurs de politiques élaborées sans compromettre la sécurité du système et avec des surcoûts en performance faibles.
Dans un mode de réalisation particulier, au moins une fonction de support est une fonction dynamique exécutable indépendamment de sa position, cette fonction dynamique étant appelée par une fonction de support statique compilée avec le noyau et appelée par la politique de sécurité. Pour plus de renseignements sur la notion de code indépendant de sa position (en anglais « position independent code »), l'homme du métier peut se reporter au document disponible à l'adresse https://fr.qwe.wiki/wiki/Position-independent_code.
Dans un mode de réalisation particulier, le procédé de mise en place d'une politique de sécurité proposé comporte une étape d'analyse d'un fichier journal (plus connu sous le terme logs) comportant au moins un résultat d'exécution d'une politique de sécurité exécutée par un procédé de sécurisation tel que mentionné ci-dessus.
Le procédé de sécurisation et le procédé de mise en place d'une politique de sécurité proposés sont mis en oeuvre par des programmes d'ordinateur.
Par conséquent, l'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un dispositif ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en oeuvre d'un procédé tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.
D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
Le programme d'ordinateur proposé peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés tels que décrits précédemment.
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente un dispositif conforme à un mode particulier de réalisation et les principales étapes d'un procédé de mise en place d'une politique de sécurité conforme à un mode particulier de réalisation ;
- la figure 2 représente une table de processus pouvant être utilisée dans un mode particulier de réalisation ;
- la figure 3 représente une table de contrôle pouvant être utilisée dans un mode particulier de réalisation ;
- la figure 4 représente sous forme d'ordinogramme les principales étapes d'un procédé de sécurisation conforme à un mode particulier de réalisation.
La figure 1 représente un dispositif 100 conforme à l'invention. Dans l'exemple de réalisation décrit ici, ce dispositif 100 a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, et des moyens de communication 13.
Ce dispositif comporte un système logiciel SYS, ce système comportant un noyau ou système d'exploitation KER, et un espace utilisateur USR. Dans le mode de réalisation décrit ici, le système d'exploitation KER est de type Linux (marque déposée).
Dans le mode de réalisation décrit ici, l'espace utilisateur USR comporte un processus p0(), deux piles logicielles de type conteneur Cl, C2 et un outil d'administration ADM. Le processus p0() et les piles logicielles Cl, C2 sont associées à des droits de niveau utilisateur et l'outil d'administration ADM à des droits de niveau administrateur.
Dans l'exemple de réalisation décrit ici, les piles logicielles Cl, C2 de l'espace utilisateur USR sont des conteneurs, chacun comportant un ensemble de processus isolés du reste du système logiciel SYS.
Dans cet exemple, la création des conteneurs Cl et C2 est demandée par le processus p0().
On rappelle que les processus de l'espace utilisateur USR peuvent être isolés grâce au mécanisme connu d'espaces de nommage. De façon connue, le système d'exploitation Linux propose dans l'état actuel de la technique, plusieurs espaces de nommage (par exemple : Network, IPC, PID, User)... qui peuvent être utilisés pour isoler des processus dans un mécanisme dans lequel on définit des ensembles de processus, de sorte que les processus d'un ensemble donné ne puissent pas voir les ressources utilisées par un autre ensemble de processus.
Dans l'exemple de la figure 1:
- le processus pO est associé respectivement à des espaces de nommage ENNETWORKO (pour l'espace Network), ENIPC0 (pour IPC), ENPID0 (pour PID), ENUserO (pour User) ... ;
- les processus du conteneur Cl, en l'occurrence le processus pl(), sont associés à des espaces de nommage différents ENNETWORK1, ENIPC1, ENIPD1, ENUserl; et - les processus du conteneur C2, en l'occurrence le processus p2(), sont associés à des espaces de nommage différents ENNETWORK2, ENIPC2, ENIPD2, ENUser2.
Certains processus du système SYS peuvent faire appel à des fonctions système du noyau KER. Le noyau KER comporte un gestionnaire d'appel système GAS dans lequel sont implémentés ces appels système.
L'invention propose un mécanisme de gestion de sécurité pour sécuriser les appels système déclenchant des opérations sensibles au sens des Modules de Sécurité Linux (LSM).
Dans le mode de réalisation décrit ici, on considère que les opérations oper_open() d'ouverture de fichier, oper_send() d'envoi de paquets et oper_exec() d'exécution de fonction sont des opérations sensibles.
Dans l'exemple de la figure 1 le processus pl du conteneur Cl et le processus p2 du conteneur C2 appellent :
- l'appel système open() d'ouverture de fichier qui génère lors de son exécution, l'opération sensible oper_open(); et
- l'appel système send() d'envoi de paquets qui génère lors de son exécution, l'opération sensible oper_send().
Dans l'exemple de la figure 1, le processus pO ne fait pas appel aux appels système open() send(), exec().
Dans le mode de réalisation décrit ici, l'invention propose d'utiliser un nouvel espace de nommage ENSECURE dédié à la gestion de la sécurité.
Par exemple, le processus pO est associé à l'espace de nommage de gestion de la sécurité ENSECUREO, le conteneur Cl est associé à l'espace de nommage de gestion de la sécurité ENSECURE1 et le conteneur C2 est associé à l'espace de nommage ENSECURE2.
La figure 2 représente en détail une table TABPID des processus pO, pl et p2 mémorisée dans le noyau KER. Dans le noyau KER, un processus est constitué d'une structure comportant plusieurs champs permettant de gérer le cycle de vie du processus comme son identifiant de processus PID, ses drapeaux (flags en anglais), sa pile ...
Dans l'espace noyau, on peut récupérer la structure de données correspondant au processus courant à l'aide de l'instruction current (voir étape E30, figure 4).
Cette structure comporte également un champ nsproxy qui comporte des pointeurs vers les espaces de nommage. Conformément à ce mode de réalisation particulier, ce champ nsproxy comporte un pointeur ENSECURE vers l'espace de nommage dédié à la gestion de la sécurité associé au processus. Cet espace de nommage définit une structure de données qui comprend notamment la politique de sécurité définie en langage eBPF. Dans le mode de réalisation décrit ici, ces structures sont enregistrées dans une zone de politiques de sécurité ZPS du noyau KER. L'espace de nommage ENSECURE d'un processus comporte un lien vers l'espace de nommage ENSECURE du parent de l'espace de nommage de ce processus. Dans l'exemple décrit ici, ENSECURE1 et ENSECURE2 associés respectivement aux conteneurs Cl et C2 pointent vers l'espace de nommage ENSECUREO du processus pO.
Les espaces de nommage ENSECURE forment donc un arbre.
De façon connue de l'homme du métier un processus peut changer d'espace de nommage pour rejoindre l'espace de nommage d'un de ses processus fils, par exemple en utilisant la commande unshare().
Depuis l'espace utilisateur USR, il est possible d'accéder à l'identifiant d'un espace de nommage mais il n'est pas possible de modifier sa structure. Cette caractéristique permet avantageusement d'empêcher toute modification ou désactivation d'une politique de sécurité par un conteneur.
Dans l'exemple de réalisation décrit ici, on suppose que le processus p0() a défini une politique de sécurité PSOFpO pour sécuriser les appels à l'opération sensible d'ouverture de fichier oper_open(). On suppose qu'il n'a pas défini de politique de sécurité pour sécuriser les appels à l'opération sensible d'envoi de paquet sur le réseau oper_send().
Dans le mode de réalisation décrit ici, les processus d'un conteneur héritent des politiques de sécurité définies par tous ses espaces de nommage ENSECURE ancêtres.
Dans l'exemple de réalisation décrit ici, on suppose que le conteneur Cl a défini sa propre politique de sécurité PSOFC1 pour sécuriser les appels par ses processus, en l'occurrence pl(), à l'opération sensible d'ouverture de fichier oper_open(), en complément de la politique PSOFpO définie par le processus p0().
On suppose que le conteneur Cl a défini une politique de sécurité PSTPC1 pour sécuriser les appels par ses processus, en l'occurrence pl(), à l'opération sensible d'envoi de paquet oper_send().
On suppose que le conteneur C2 n'a défini aucune politique de sécurité propre. Le processus p2() de ce conteneur hérite de la politique de sécurité PSOFpO définie par le processus p0() pour sécuriser ses appels à l'opération sensible d'ouverture de fichier. Mais il ne définit aucune fonction de sécurité pour vérifier l'opération sensible d'envoi de paquet.
Dans le mode de réalisation décrit ici, chacune des politiques de sécurité PSOFpO, PSOFC1, PSTPC1 est définie par une fonction logicielle en langage eBPF compilée en binaire. Ces politiques de sécurité sont enregistrées dans la mémoire morte 12 du dispositif 100 et destinées à être chargées dans la zone ZPS de politiques de sécurité du noyau KER.
Ce chargement (étape F10) peut se faire de différentes façons.
Dans le mode de réalisation décrit ici, la mémoire morte 12 comporte un fichier de configuration de type OCI (Open Container Initiative) pour chaque conteneur, à savoir un fichier de configuration FOCIC1 pour le conteneur Cl et un fichier de configuration FOCIC2 pour le conteneur C2. De façon connue, la configuration OCI d'un conteneur est spécifiée sous le nom config.json et détaille les caractéristiques du conteneur à créer. Ce fichier de configuration précise notamment les fichiers que doit contenir le conteneur, ses interfaces système, ses espaces de nommage, ...
Dans le mode de réalisation décrit ici, le fichier de configuration OCI d'un conteneur comporte des instructions pour que le conteneur charge ses politiques de sécurité dans la zone ZPS de politiques de sécurité du noyau KER.
Quand un conteneur est créé, par exemple Cl, les politiques de sécurité PSOFC1 et PCTPC1 du conteneur Cl sont copiées de la mémoire morte 12 dans une mémoire Ml du conteneur Cl. Une fois que le conteneur Cl est construit, il est exécuté et à l'exécution, les politiques de sécurité sont transférées de la mémoire Ml, dans la zone ZPS du noyau.
L'écriture manuelle de fichier de configuration OCI peut néanmoins s'avérer complexe, et dans un autre mode de réalisation de l'invention, le chargement de la politique de sécurité d'un conteneur dans le noyau KER est définie par une instruction d'une méthode de construction de conteneur de plus haut niveau, par exemple de la méthode Dockerfile.
Par ailleurs, le chargement d'une politique de sécurité propre à un conteneur dans la mémoire du noyau peut être effectué à tout moment du cycle de vie du conteneur, pas seulement à son initialisation. Dans le mode de réalisation décrit ici, le code du conteneur Cl comporte également des instructions load_ps() permettant de charger une politique de sécurité sous forme d'un fichier eBPF compilé sous forme binaire dans la zone ZPS de politiques de sécurité du noyau KER. Ce mode de réalisation particulier permet en particulier de charger une nouvelle politique de sécurité qui va être appliquée après le démarrage du conteneur Cl. Cette fonction load_ps() consiste à ouvrir le fichier eBPF compris dans la mémoire morte 12 et à le copier vers une interface avec le noyau KER.
Dans le mode de réalisation décrit ici, le noyau KER comporte une infrastructure de contrôle de sécurité ICS de gestion des Modules de sécurité Linux, un module de sécurité Linux LSM1 conforme à l'invention et éventuellement au moins un autre module de sécurité LSM2, par exemple, un module SELinux ou un module AppAmor tels que mentionnés précédemment.
Dans l'exemple de réalisation décrit ici, le noyau KER comporte une table de contrôle TABCTR qui définit, pour chaque opération sensible OPS (ouverture de fichier, envoi de paquet sur le réseau, ...) si le module de sécurité LSM1 veut contrôler ou non ces opérations sensibles. Cette table TABCTR est représentée à la figure 3.
Dans l'exemple de vérification décrit ici, on suppose que le module de sécurité LSM1 ne souhaite vérifier que l'opération sensible d'ouverture de fichiers.
La figure 4 représente sous forme d'ordinogramme les principales étapes d'un procédé de sécurisation conforme à un mode particulier de réalisation. Dans le mode de réalisation décrit ici, ce procédé est mis en oeuvre par le gestionnaire d'appel système GAS, l'infrastructure de contrôle de sécurité ICS (en anglais framework LSM) et par le module de sécurité LSM1. Dans l'exemple de réalisation décrit ici, le gestionnaire d'appel système GAS détermine, au cours d'une étape E10, si un appel système déclenché par un processus de l'espace utilisateur doit réaliser une opération sensible. Si c'est le cas, il déclenche l'infrastructure de contrôle de sécurité ICS du noyau KER.
Si l'infrastructure ICS détermine que l'opération sensible OPS répertoriée dans la table TABCTR est supervisée par le module de sécurité LSM1, l'infrastructure ICS déclenche l'exécution du module de sécurité LSM1 au cours d'une étape E20.
Dans l'exemple de réalisation décrit ici, si un processus souhaite réaliser l'opération sensible envoyer un paquet (oper_send()) ou exécuter un nouveau processus en espace utilisateur (oper_exec()) par appel à la fonction exec(), comme ces opérations sensibles ne sont pas vérifiées par le module de sécurité LSM1, le résultat de l'étape de détermination est négatif. Ces opérations peuvent néanmoins être vérifiées par le module de sécurité LSM2, hors contexte de l'invention, par exemple SELinux et un module AppAmor.
Au cours d'une étape E30, le module de sécurité LSM1 détermine l'espace de nommage associé au processus courant à l'origine de cet appel. Il utilise pour cela le processus courant de la table des processus TABPID.
Le module de sécurité LSM1 exécute ensuite une boucle pour exécuter les politiques de l'espace de nommage du processus courant liées à cette opération sensible. Dans un mode de réalisation particulier, le module de sécurité LSM1 exécute ensuite une boucle pour exécuter les politiques de ses espaces de nommage ancêtres s'ils existent.
Au cours d'une étape E40 le module de sécurité LSM1 détermine si l'espace de nommage courant a défini une ou plusieurs politiques de sécurité pour vérifier la validité de l'opération sensible.
Si tel est le cas, le module de sécurité concerné LSM1 exécute au cours d'une étape E50 la ou les politiques de sécurité définies dans l'espace de nommage dédié à la gestion de sécurité ENSECURE du processus courant pour cette opération sensible.
En l'espèce, au cours de la première itération, la politique de sécurité PSOFC1 est exécutée. Cette politique de sécurité renvoie un résultat RET de cette exécution au module de sécurité LSM1.
Dans le mode de réalisation décrit ici, une politique de sécurité, et en particulier la politique de sécurité PSOFC1, renvoie un résultat RET négatif si elle détecte un problème de sécurité (traduisant par exemple un comportement malveillant ou anormal) et un résultat positif si elle ne détecte aucun problème de sécurité.
Si cette valeur RET est positive, le module de sécurité détermine, s'il existe, l'espace de nommage parent de l'espace de nommage du processus courant (étape E60) et la boucle se répète.
En l'espèce, au cours de la deuxième itération la politique de sécurité PSOFpO de l'espace de nommage ENSECUREO du processus pO est exécutée. Si une politique de sécurité renvoie un résultat RET négatif, le module de sécurité enregistre ce résultat dans un fichier de log FLOG du noyau KER au cours d'une étape E70 et envoie ce résultat négatif RET à l'infrastructure de sécurité ICS. Ce fichier de log FLOG peut être analysé (étape F30) par l'administrateur au moyen de l'outil d'administration ADM.
Lorsque toutes les politiques de sécurité de toute l'arborescence d'espaces de nommages ont été exécutées avec un résultat RET positif, le module de sécurité LSM1 envoie un résultat positif RET à l'infrastructure de sécurité ICS (test E90).
Dans le mode de réalisation décrit ici, si l'infrastructure de sécurité RET reçoit un résultat RET positif, elle ne déclenche pas d'action particulière et l'appel système est exécuté, sauf si une action est déclenchée par un autre module de sécurité LSM2, par exemple, un module SELinux et un module AppAmor.
Dans le mode de réalisation décrit ici, si l'infrastructure de sécurité RET reçoit un résultat RET négatif, l'infrastructure de contrôle ICS déclenche une action de sécurité AS au cours d'une étape E80. Cette action peut consister à détruire le processus à l'origine de l'appel et à lever une alerte dans le fichier de log FLOG.
Dans le mode de réalisation décrit ici, lorsqu'aucun processus ne reste dans un espace de nommage dédié à la gestion de sécurité, cet espace de nommage est détruit automatiquement par le noyau. Cette opération détruit les politiques de sécurité associées à ces espaces de nommage.
Par exemple, dans l'exemple de réalisation décrit ici, dès lors que le processus pl meurt, il n'y a plus dans le système SYS de processus dont l'espace de nommage dédié à la gestion de sécurité est ENSECURE1 si bien que les politiques de sécurité PSOFC1 et PSTPC1 peuvent être détruites.
Dans le mode de réalisation décrit ici, si une politique de sécurité n'est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif de l'espace utilisateur, cette politique de sécurité est supprimée par le noyau.
Conformément à l'invention, les politiques de sécurité en langage eBPF compilé peuvent appeler des fonctions du noyau KER externes à ces politiques, pour mettre en oeuvre des opérations critiques qui ne peuvent pas l'être directement par la politique de sécurité en langage eBPF elle-même. De telles fonctions sont connues de l'homme du métier sous le nom de fonctions de support eBPF (en anglais « Helper eBPF »).
Dans un mode particulier de mise en oeuvre de l'invention, une telle fonction de support FSUP peut être écrite par un administrateur, par exemple en langage C, puis compilée comme un module noyau classique avec GCC (en anglais « GNU Compiler Collection »).
Dans le mode de réalisation décrit ici, ce code exécutable est transformé pour pouvoir être exécuté indépendamment de sa position selon le mécanisme PIC (Position Independent Code) connu de l'homme du métier. Ces fonctions de support FSUP dynamiques peuvent être chargées (étape F20) dans une zone dédiée du noyau KER sans interrompre l'exécution du noyau.
Une fois chargées dans le noyau, ces fonctions de support dynamiques FSUP peuvent être appelées par le code eBPF d'une politique de sécurité à l'aide d'une unique fonction de support statique FSUPSTAT.

Claims

REVENDICATIONS
1. Procédé de sécurisation d'au moins un appel système déclenché par un processus courant (pl) d'un espace utilisateur (USR) d'un système logiciel (SYS), ledit procédé étant mis en oeuvre par un noyau (KER) dudit système logiciel (SYS) avant d'exécuter au moins une opération déclenchée par ledit au moins un appel système, et 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 (E50) d'exécution d'une politique de sécurité définie dans l'espace de nommage associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) ;
- une étape (E30) d'obtention d'au moins un espace de nommage (ENSECUREO) dédié à la gestion de sécurité et ancêtre de l'espace nommage (ENSECURE1) dudit processus courant (pl) ;
- une étape (E50) d'exécution d'une politique de sécurité définie dans l'espace de nommage ancêtre associée à ladite opération et enregistrée dans une zone dudit noyau; et
- une étape de traitement dudit appel système en fonction d'un résultat (RET) desdites exécutions.
2. Procédé de sécurisation d'au moins un appel système selon la revendication 1, comportant une étape (E10) pour déterminer si ladite opération est une opération sensible.
3. Procédé de sécurisation d'au moins un appel système selon l'une quelconque des revendications 1 à 2, dans lequel ladite étape de traitement consiste à exécuter ladite opération si le résultat de l'exécution de ladite au moins une politique de sécurité ne détecte aucun problème de sécurité et à déclencher (E80) une action de sécurité si le résultat de l'exécution d'au moins une dite politique de sécurité détecte un problème de sécurité.
4. Procédé de sécurisation d'au moins un appel système selon la revendication 3, dans lequel ladite action de sécurité comporte la destruction dudit processus courant (pl).
5. Procédé de sécurisation d'au moins un appel système selon l'une quelconque des revendications 1 à 4, comportant une étape de suppression d'au moins une dite politique de sécurité par ledit noyau (KER) si ladite politique de sécurité n'est pas comprise dans un espace de nommage dédié à la sécurité associé à au moins un processus actif dudit espace utilisateur (USR).
6. Procédé de mise en place d'une politique de sécurité, ledit procédé étant mis en oeuvre par une pile logicielle (Cl) d'un espace utilisateur (USR) d'un système logiciel (SYS) pour sécuriser au moins un appel système susceptible d'être déclenché par un processus (pl) de ladite pile logicielle (Cl), ledit procédé comportant une étape (F10) de chargement de ladite politique de sécurité dans une zone (ZPS) d'un noyau (KER) dudit système (SYS), ladite politique de sécurité étant définie dans un espace de nommage (ENSECURE1) du noyau dédié à la gestion de sécurité associé à une opération susceptible d'être déclenchée par ledit au moins un appel système dudit processus (pl), ledit espace de nommage comprenant un lien vers un espace de nommage ancêtre.
7. Procédé de mise en place d'une politique de sécurité selon la revendication 6, dans lequel ladite pile logicielle (Cl) est un conteneur, ledit chargement étant défini par une instruction d'un fichier de configuration dudit conteneur (Cl), ledit fichier de configuration (FOCIC1) étant conforme aux spécifications définies par l'OCI (Open Container Initiative) ou un fichier de type Dockerfile.
8. Procédé de mise en place d'une politique de sécurité selon la revendication 6 ou 7 dans lequel ladite au moins une politique de sécurité appelle au moins une fonction de support (FSUP) externe à ladite politique et chargée (F20) dans une zone dédiée du noyau (KER) par une entité dudit espace utilisateur (USR) bénéficiant de droits d'administration.
9. Procédé de mise en place d'une politique de sécurité selon la revendication 8 dans lequel ladite au moins une fonction de support (FSUP) est une fonction dynamique exécutable indépendamment de sa position, cette fonction dynamique (FSUP) étant appelée par une fonction de support statique (FSUPSTAT) compilée avec ledit noyau (KER) et appelée par ladite politique de sécurité.
10. Procédé de mise en place d'une politique de sécurité selon l'une quelconque des revendications 6 à 9, comportant une étape (F30) d'analyse d'un fichier journal (FLOG) comportant au moins un résultat (RET) d'exécution d'une politique de sécurité exécutée par un procédé de sécurisation selon l'une quelconque des revendications 1 à 4.
11. Procédé selon l'une quelconque des revendications 1 à 10 dans lequel ladite au moins une politique de sécurité est un fichier en langage binaire obtenu par compilation d'un programme en langage eBPF.
12. Dispositif (100) comportant un espace utilisateur (USR) et un noyau (KER), l'espace utilisateur (USR) comportant au moins un processus (pl) apte un déclencher au moins un appel système dudit noyau (KER), ledit dispositif (100) comprenant :
- ledit noyau (KER) comporte une infrastructure de contrôle de sécurité (ICS) et un module de sécurité (LSM1), ladite infrastructure (ISC) étant configurée pour exécuter ledit module de sécurité (LSM1) avant d'exécuter au moins une opération déclenchée par ledit au moins un appel système;
- ledit module de sécurité (LSM1) étant configuré pour :
- obtenir au moins un espace de nommage (ENSECURE1) du noyau (KER) dédié à la gestion de sécurité associé audit processus (pl) ;
- obtenir au moins un espace de nommage (ENSECURE0) dédié à la gestion de sécurité et ancêtre de l'espace nommage dudit processus courant ;
- exécuter une politique de sécurité définie dans l'espace de nommage associée à ladite opération et enregistrée dans une zone (ZPS) dudit noyau (KER) ; et - exécuter une politique de sécurité définie dans l'espace de nommage ancêtre associée à ladite opération et enregistrée dans une zone dudit noyau.
PCT/FR2021/050860 2020-05-20 2021-05-18 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 WO2021234267A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202180043947.9A CN115917539A (zh) 2020-05-20 2021-05-18 确保系统调用的安全的方法、实施关联安全策略的方法、和执行这些方法的设备
EP21732967.1A EP4154141A1 (fr) 2020-05-20 2021-05-18 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
US17/999,532 US20230195884A1 (en) 2020-05-20 2021-05-18 Method for securing a system call, method for implementing an associated security policy and devices for carrying out such methods

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2005153A FR3110726A1 (fr) 2020-05-20 2020-05-20 Procédé de sécurisation d’un appel système, procédé de mise en place d’une politique de sécurité associée et dispositifs mettant en œuvre ces procédés.
FRF2005153 2020-05-20

Publications (1)

Publication Number Publication Date
WO2021234267A1 true WO2021234267A1 (fr) 2021-11-25

Family

ID=72644323

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2021/050860 WO2021234267A1 (fr) 2020-05-20 2021-05-18 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

Country Status (5)

Country Link
US (1) US20230195884A1 (fr)
EP (1) EP4154141A1 (fr)
CN (1) CN115917539A (fr)
FR (1) FR3110726A1 (fr)
WO (1) WO2021234267A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116991449A (zh) * 2023-09-28 2023-11-03 阿里云计算有限公司 内核子系统热升级方法、设备及存储介质

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3133087A1 (fr) * 2022-02-28 2023-09-01 Orange Procédé et module de détection de tentatives d’attaques informatiques dans un parc d’ordinateurs.

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170353499A1 (en) * 2016-06-06 2017-12-07 NeuVector, Inc. Methods and Systems for Applying Security Policies in a Virtualization Environment Using a Security Instance
US20180129666A1 (en) * 2016-11-04 2018-05-10 Microsoft Technology Licensing, Llc Multi-layer merge in a storage virtualization system
WO2019127399A1 (fr) * 2017-12-29 2019-07-04 浙江大学 Procédé d'exécution de politique de bac à sable à grains fins pour conteneur linux

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170353499A1 (en) * 2016-06-06 2017-12-07 NeuVector, Inc. Methods and Systems for Applying Security Policies in a Virtualization Environment Using a Security Instance
US20180129666A1 (en) * 2016-11-04 2018-05-10 Microsoft Technology Licensing, Llc Multi-layer merge in a storage virtualization system
WO2019127399A1 (fr) * 2017-12-29 2019-07-04 浙江大学 Procédé d'exécution de politique de bac à sable à grains fins pour conteneur linux

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
BÉLAIR MAXIME MAXIME BELAIR@ORANGE COM ET AL: "SNAPPY programmable kernel-level policies for containers", PROCEEDINGS OF THE 36TH ANNUAL ACM SYMPOSIUM ON APPLIED COMPUTING, ACMPUB27, NEW YORK, NY, USA, 22 March 2021 (2021-03-22), pages 1636 - 1645, XP058562519, ISBN: 978-1-4503-8108-6, DOI: 10.1145/3412841.3442037 *
YUQIONG SUN SYMANTEC RESEARCH LABS DIMITRIOS PENDARAKIS IBM RESEARCH ZHONGSHU GU IBM RESEARCH DAVID SAFFORD GE GLOBAL RESEARCH MIM: "Security Namespace : Making Linux Security Frameworks Available to Containers", 14 August 2018 (2018-08-14), pages 1436 - 1452, XP061026245, Retrieved from the Internet <URL:https://www.usenix.org/sites/default/files/sec18_full_proceedings_interior.pdf> [retrieved on 20180814] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116991449A (zh) * 2023-09-28 2023-11-03 阿里云计算有限公司 内核子系统热升级方法、设备及存储介质
CN116991449B (zh) * 2023-09-28 2024-03-08 阿里云计算有限公司 内核子系统热升级方法、设备及存储介质

Also Published As

Publication number Publication date
FR3110726A1 (fr) 2021-11-26
EP4154141A1 (fr) 2023-03-29
US20230195884A1 (en) 2023-06-22
CN115917539A (zh) 2023-04-04

Similar Documents

Publication Publication Date Title
WO2021234267A1 (fr) Procede de securisation d&#39;un appel systeme, procede de mise en place d&#39;une politique de securite associee et dispositifs mettant en oeuvre ces procedes
US20120090025A1 (en) Systems and methods for detection of malicious software packages
EP2649522B1 (fr) Methode de mise a disposition d&#39;une application en tant que librairie dans une machine virtuelle
EP2372974A1 (fr) Procédé de sécurisation de données et/ou des apllications dans une architecture informatique en nuage
FR3017725A1 (fr) Procede de deploiement d&#39;un ensemble d&#39;application (s) logicielle (s)
CN109255235B (zh) 基于用户态沙箱的移动应用第三方库隔离方法
EP2958040B1 (fr) Procédé et dispositif de codage de fichiers sources pour la livraison sécurisée de code source
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
FR2961922A1 (fr) Procede de compilation selective, dispositif et produit programme d&#39;ordinateur correspondant.
EP3588359A1 (fr) Procédé de vérification de l&#39;intégrité d&#39;un code applicatif, dispositif et produit programme d&#39;ordinateur correspondants
WO2007068706A1 (fr) Procede pour securiser l&#39;execution d&#39;un code logiciel en langage intermediaire dans un appareil portatif
EP1700218A2 (fr) Procede de determination de caracteristiques operationnelles d&#39;un programme
EP4302213A1 (fr) Procede et module d&#39;installation d&#39;un programme de mitigation dans le noyau d&#39;un equipement informatique
EP1054332B1 (fr) Système et procédé de gestion d&#39;attributs dans un environnement orienté objet
WO2023161105A1 (fr) Procédé et module de détection de tentatives d&#39;attaques informatiques dans un parc d&#39;ordinateurs
FR3067486A1 (fr) Procede de detection non intrusif des failles de securite d&#39;un programme informatique
FR3125609A1 (fr) Mise en partage d’une fonction d’une application définie en langage orienté objet
WO2023222330A1 (fr) Procédé et module de détection de vulnérabilités informatiques dans un parc d&#39;ordinateurs
EP3411821B1 (fr) Procédé de stockage de contenus, procédé de consultation de contenus, procédé de gestion de contenus et lecteurs de contenus
FR2911022A1 (fr) Procede permettant d&#39;imposer une politique de securite a une application telechargeable accedant a des ressources du reseau
FR2859548A1 (fr) Procede de surveillance de l&#39;execution de programmes sur un ordinateur
EP2075733B1 (fr) Dispositif et un procédé de protection contre la rétro conception
EP2579177A1 (fr) Terminal mobile apte à modifier dynamiquement son niveau de sécurité et procédé de sécurisation associé
EP4187426A1 (fr) Procédé d exécution d&#39;un programme logiciel par une unité de traitement comprenant une phase de compilation
EP2449495A1 (fr) Procédé de validation distante d&#39;un code exécutable

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21732967

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021732967

Country of ref document: EP

Effective date: 20221220