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 Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• General Health & Medical Sciences (AREA)
• Bioethics (AREA)
• Health & Medical Sciences (AREA)
• Databases & Information Systems (AREA)
• Storage Device Security (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=72644323

Family Applications (1)

Country Status (5)

Families Citing this family (2)

Family Cites Families (3)

• 2020
  • 2020-05-20 FR FR2005153A patent/FR3110726A1/fr not_active Withdrawn
• 2021
  • 2021-05-18 CN CN202180043947.9A patent/CN115917539A/zh active Pending
  • 2021-05-18 WO PCT/FR2021/050860 patent/WO2021234267A1/fr unknown
  • 2021-05-18 US US17/999,532 patent/US20230195884A1/en active Pending
  • 2021-05-18 EP EP21732967.1A patent/EP4154141A1/de active Pending

Also Published As

Similar Documents

Legal Events