A method and device for analyzing shared virtual resources

Abstract

One or more embodiments of the present specification provide a shared virtual resource analysis method, apparatus, electronic device, and machine-readable storage medium, which are applied to a terminal device equipped with a Linux system. The method comprises: scanning the kernel code of the Linux system, identifying sensitive functions contained in the kernel code, and shared virtual resources related to the sensitive functions; wherein the sensitive functions are functions related to the use of the shared virtual resources; determining whether a system call initiated by the plurality of containers triggers the sensitive function; if a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target for a DoS attack by the target container.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of Linux system security technology, and in particular, to a shared virtual resource analysis method, device, electronic device, and machine-readable storage medium. Background Art

[0002] Containers are a Linux kernel virtualization technology that can be used to isolate processes and allocate system resources to them. In other words, multiple containers in a Linux system can share the Linux kernel and the system resources provided by the kernel. These resources can include non-shared resources allocated to a container and shared resources that can be shared by some containers.

[0003] For the shared resources, if a container maliciously exhausts the shared resources that can be shared by multiple containers, the Linux system may be unable to properly allocate the shared resources to other containers, thereby causing a DoS (Denial of Service) attack. Summary of the Invention

[0004] The present application provides a shared virtual resource analysis method, which is applied to a terminal device equipped with a Linux system; the Linux system is equipped with a plurality of mutually isolated containers corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources include shared virtual resources that can be shared by at least some of the plurality of containers; the method comprises:

[0005] Scanning the kernel code of the Linux system to identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions; wherein the sensitive functions are functions related to the use of the shared virtual resources;

[0006] Determining whether the system calls initiated by the plurality of containers trigger the sensitive function;

[0007] If a system call initiated by any target container among the plurality of containers triggers the sensitive function, the shared virtual resources related to the sensitive function are determined as potential attack targets of a DoS attack on the target container.

[0008] Optionally, the sensitive function includes an allocation function for allocating the shared virtual resource to at least part of the containers.

[0009] Optionally, identifying the sensitive functions contained in the kernel code and the shared virtual resources related to the sensitive functions includes:

[0010] Obtain kernel parameters of the Linux system;

[0011] Locating a first type of code segment containing the kernel parameters in the kernel code; wherein the first type of code segment at least includes relevant code for using the kernel parameters to perform a restriction check on the use of the shared virtual resource;

[0012] The allocation function contained in the first type of code segment and used to allocate the shared virtual resources to the at least part of the container is determined as a sensitive function contained in the kernel code; and the shared virtual resources referenced by the allocation function are determined as shared virtual resources related to the sensitive function.

[0013] Optionally, identifying the sensitive functions contained in the kernel code and the shared virtual resources related to the sensitive functions includes:

[0014] Locating a second type of code segment in the kernel code; wherein the second type of code segment at least includes relevant code for performing mutually exclusive access to the shared virtual resource through a lock operation or an atomic operation;

[0015] The allocation function contained in the second type of code segment and used to allocate the shared virtual resources to the at least part of the container is determined as a sensitive function contained in the kernel code; and the shared virtual resources referenced by the allocation function are determined as shared virtual resources related to the sensitive function.

[0016] Optionally, if a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target for a DoS attack on the target container includes:

[0017] If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further reading seccomp configuration information for the target container and determining whether the seccomp configuration information indicates prohibiting the system call that triggered the sensitive function;

[0018] If the seccomp configuration information does not indicate prohibiting the system call that triggers the sensitive function, the shared virtual resources related to the sensitive function are determined as potential attack targets of the DoS attack on the target container.

[0019] Optionally, if a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target for a DoS attack on the target container includes:

[0020] If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further determining whether a restriction check operation on the shared virtual resources related to the sensitive function is performed on the target container along all triggering paths of the system call initiated by the target container triggering the sensitive function;

[0021] If the restriction check operation of the shared virtual resources related to the sensitive function is not performed on the target container on all the trigger paths, the shared virtual resources related to the sensitive function are determined as potential attack targets of the DoS attack on the target container.

[0022] Optionally, the method further includes:

[0023] A trigger path for which no restriction check operation of the shared virtual resource is performed on the target container is determined as a potential attack path for a DoS attack on the target container.

[0024] Optionally, if a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target for a DoS attack on the target container includes:

[0025] If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further determining whether a shared virtual resource related to the sensitive function includes a pointer to a namespace;

[0026] If the shared virtual resource related to the sensitive function does not include a pointer to the namespace, the shared virtual resource related to the sensitive function is determined as a potential attack target for the DoS attack on the target container.

[0027] Optionally, determining whether the system calls initiated by the plurality of containers trigger the sensitive function includes:

[0028] Obtaining, based on a program control flow graph of the Linux system generated by scanning the kernel code, all system calls initiated by the plurality of containers, and determining in sequence whether each of all the system calls initiated by the plurality of containers triggers the sensitive function;

[0029] If any system call initiated by any target container among the plurality of containers triggers the sensitive function, it is determined that the system call initiated by the target container triggers the sensitive function.

[0030] The present application further provides a shared virtual resource analysis device, which is applied to a terminal device equipped with a Linux system; the Linux system is equipped with a plurality of mutually isolated containers corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources include shared virtual resources that can be shared by at least some of the plurality of containers; the device comprises:

[0031] an identification unit, configured to scan the kernel code of the Linux system and identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions; wherein the sensitive functions are functions related to the use of the shared virtual resources;

[0032] A determination unit is configured to determine whether the system call initiated by the plurality of containers triggers the sensitive function; if the system call initiated by any target container among the plurality of containers triggers the sensitive function, the shared virtual resources associated with the sensitive function are determined as potential attack targets for a DoS attack on the target container.

[0033] The present application also provides an electronic device, comprising a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus;

[0034] The memory stores machine-readable instructions, and the processor executes the above method by calling the machine-readable instructions.

[0035] The present application also provides a machine-readable storage medium, which stores machine-readable instructions. When the machine-readable instructions are called and executed by a processor, the above method is implemented.

[0036] Through the above embodiment, by scanning the kernel code of the Linux system, all shared virtual resources provided by the Linux system kernel can be identified first, and then the shared virtual resources that can be used by the target container are determined from all the identified shared virtual resources, that is, the potential attack targets of the target container for DoS attack, thereby automatically analyzing the potential attack targets of DoS attack for several containers installed in the Linux system, which helps technicians develop more secure containers. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 Flowchart of the shared virtual resource analysis method;

[0038] Figure 2 This is a structural diagram of an electronic device in which a shared virtual resource analysis device is located, showing an exemplary embodiment;

[0039] Figure 3 It is a block diagram of a shared virtual resource analysis device shown in an exemplary embodiment. DETAILED DESCRIPTION

[0040] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0041] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0042] In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the following briefly describes the relevant technologies involved in the embodiments of this specification.

[0043] In actual applications, if a container maliciously exhausts shared resources that can be shared by multiple containers, the Linux system may be unable to properly allocate the shared resources to other containers, thereby causing a DoS (Denial of Service) attack.

[0044] To design more secure containers, technicians in this field can usually manually analyze the relevant code of the Linux system kernel to identify potential attack surfaces; and then develop corresponding defense measures based on these potential attack surfaces.

[0045] It can be seen that in the above embodiments, the workload of the technicians is very heavy, which requires a lot of time and manpower; in addition, the accuracy of the analysis results is closely related to the level of the technicians, requiring the technicians to have a high level of technology.

[0046] Currently, there are no related tools in this field that can automatically analyze shared resources in the Linux system kernel.

[0047] In view of this, this specification aims to propose a static analysis tool that can identify potential targets of DoS attacks on containers based on automated analysis of the Linux kernel code.

[0048] During implementation, a terminal device equipped with a Linux system may first scan the kernel code of the Linux system to identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions; wherein the sensitive functions are functions related to the use of the shared virtual resources;

[0049] Furthermore, it can be determined whether the system calls initiated by several containers carried in the Linux system trigger the identified sensitive function; if the system call initiated by any target container among the several containers triggers the sensitive function, the shared virtual resources related to the sensitive function can be determined as potential attack targets for DoS attacks on the target container.

[0050] It can be seen that in the technical solution of this specification, by scanning the kernel code of the Linux system, all shared virtual resources provided by the Linux system kernel can be identified first, and then the shared virtual resources that can be used by the target container are determined from all the identified shared virtual resources, that is, the potential attack targets of the target container for DoS attack, thereby automatically analyzing the potential attack targets of DoS attack on several containers installed in the Linux system, and thus helping technical personnel develop more secure containers.

[0051] Compared with manual analysis, the automated analysis method for shared virtual resources shown above can save analysis costs and improve analysis efficiency. Ordinary technicians can also automatically identify potential attack targets of DoS attacks on containers based on the above static analysis tools, which requires a lower level of technical skills from users.

[0052] The present application is described below through specific embodiments and in combination with specific application scenarios.

[0053] See Figure 1 , Figure 1 This is a flow chart of a method for analyzing shared virtual resources according to an exemplary embodiment. The method may perform the following steps:

[0054] Step 102: Scan the kernel code of the Linux system to identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions; wherein the sensitive functions are functions related to the use of the shared virtual resources;

[0055] Step 104: Determine whether the system calls initiated by the plurality of containers carried by the Linux system trigger the sensitive function;

[0056] Step 106: If the system call initiated by any target container among the plurality of containers triggers the sensitive function, the shared virtual resources related to the sensitive function are determined as potential attack targets of the DoS attack on the target container.

[0057] In this specification, the above method can be applied to terminal devices equipped with a Linux system. The terminal device can include a server equipped with a Linux system, a server cluster formed by multiple servers, or a client-side network device equipped with a Linux system, and this specification does not impose any special restrictions.

[0058] For example, the terminal device may specifically include a network device equipped with a shared virtual resource analysis tool or a potential attack surface detection program.

[0059] In this specification, the above-mentioned Linux system is equipped with a number of containers corresponding to different tenants and isolated from each other; the above-mentioned Linux system kernel can provide a number of virtual resources.

[0060] The aforementioned virtual resources can be understood as global variables or structures corresponding to the system resources provided by the Linux system kernel in the Linux system kernel code. The process of the Linux system kernel allocating system resources to a container is usually reflected in the Linux system kernel code as the allocation of corresponding virtual resources to the container. For example, in the memory management mechanism of the Linux system, the memory can usually be divided into multiple physical pages (page frames, also known as page frames, page frames), each page frame can contain a page. The Linux kernel can usually use memory pages as the basic unit of memory management. In the kernel code, the structure "struct page" can be used to represent physical pages. That is, the virtual resource corresponding to the system resource memory page is the structure struct page.

[0061] In this specification, the aforementioned virtual resources may include shared virtual resources that can be shared by at least some of the aforementioned containers. Accordingly, the aforementioned shared virtual resources may correspond to the shared system resources provided by the aforementioned Linux system kernel, and will not be further described here.

[0062] In this specification, the kernel code of the Linux system may be scanned to identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions.

[0063] Among them, scanning the kernel code of the above-mentioned Linux system, that is, scanning the LLVM IR (LLVM Intermediate Representation, intermediate representation of the LLVM compiler) of the above-mentioned Linux system kernel; the above-mentioned LLVM IR is an intermediate language code that is independent of the source programming language and the target machine architecture, and can usually have three forms of expression: compiled intermediate language in memory, binary code on disk, and readable assembly text. The three forms of the above-mentioned LLVM IR are essentially equivalent, and this manual does not impose any special restrictions.

[0064] The sensitive function may be a function related to the use of the shared virtual resource, that is, a function related to operations such as allocation, access, and modification of the shared virtual resource.

[0065] For example, by scanning the kernel code of the Linux system, the sensitive function f1 contained in the kernel code and the shared virtual resource R1 related to the sensitive function f1 can be identified; in addition, the identified shared virtual resources can be marked to facilitate subsequent further filtering of the above analysis results.

[0066] It should be noted that by scanning the above kernel code, the number of sensitive functions that can be identified and the number of shared virtual resources related to the above sensitive functions can also be greater than one. The above is only an exemplary description and does not limit this specification.

[0067] In practical applications, the sensitive function may include an allocation function for allocating the shared virtual resource to at least part of the plurality of containers.

[0068] For example, the sensitive function f1 may specifically include the allocation function alloc_empty_file() for allocating the shared virtual resource structfile for certain containers; for another example, the sensitive function f2 may specifically include the allocation function ioctx_alloc() for allocating the shared virtual resource struct kioctx for certain containers.

[0069] In one embodiment shown, the execution logic of the allocation function for allocating the above-mentioned shared virtual resources may generally include: in response to an application operation for the above-mentioned shared virtual resources from a certain container, first performing a limit check using the kernel parameters related to the above-mentioned shared virtual resources, and if the limit check passes, allocating the above-mentioned shared virtual resources to the container; therefore, by locating the above-mentioned limit check operation in the above-mentioned kernel code, the above-mentioned allocation function and the above-mentioned shared virtual resources can be identified.

[0070] The kernel parameters are related to the performance of the Linux system. For example, the kernel parameter files_stat.max_files can be used to limit the maximum number of open files in the Linux system. For other kernel parameters, please refer to the relevant art and will not be described in detail in this specification.

[0071] During implementation, the process of identifying the sensitive functions contained in the above-mentioned kernel code and the shared virtual resources related to the above-mentioned sensitive functions may specifically include: obtaining the kernel parameters of the above-mentioned Linux system; locating a first type of code segment containing the above-mentioned kernel parameters in the above-mentioned kernel code; wherein the above-mentioned first type of code segment at least includes relevant code for using the above-mentioned kernel parameters to perform restriction checks on the use of the above-mentioned shared virtual resources; determining the allocation function contained in the above-mentioned first type of code segment for allocating the above-mentioned shared virtual resources to at least part of the above-mentioned containers as the sensitive function contained in the above-mentioned kernel code; and determining the shared virtual resources referenced by the above-mentioned allocation function as the shared virtual resources related to the above-mentioned sensitive functions.

[0072] For example, you can obtain the kernel parameter files_stat.max_files of the Linux system, and locate the first type of code segment shown below in the kernel code of the above Linux system.

[0073] struct file*alloc_empty_file()

[0074] {

[0075] ... / *Related code for checking the limit using the kernel parameter files_stat.max_files* /

[0076] ... / *Related code for allocating shared virtual resources struct file* /

[0077] }

[0078] After locating the first type of code segment containing the kernel parameter files_stat.max_files as shown above, the allocation function alloc_empty_file() contained in the above first type of code segment can be determined as the sensitive function f1 contained in the above kernel code; and the shared virtual resource struct file referenced by the allocation function alloc_empty_file() can be determined as the shared virtual resource R1 related to the sensitive function f1.

[0079] It should be noted that, in the above-described embodiment, the specific implementation method of obtaining the kernel parameters of the above-mentioned Linux system is not particularly limited in this specification.

[0080] For example, the modifiable kernel parameters in the Linux system are usually saved in the directory / proc / sys. Each kernel parameter may correspond to a kernel file. Therefore, the kernel file / proc / sys / files_stat / max_files in the directory may be read to obtain the kernel parameter files_stat.max_files of the Linux system.

[0081] For another example, the kernel parameters may be stored as variables in a configuration file sysctl.conf, and the variables in the configuration file may be read and set using a sysctl instruction, thereby obtaining the kernel parameters of the Linux system.

[0082] In another embodiment shown, since lock operations, atomic operations and the like can usually be used to achieve mutually exclusive access to the above-mentioned shared virtual resources, the above-mentioned sensitive functions and the shared virtual resources related to the above-mentioned sensitive functions can be identified by locating lock operations and / or atomic operations in the above-mentioned kernel code.

[0083] During implementation, the above-mentioned process of identifying the sensitive functions contained in the above-mentioned kernel code and the shared virtual resources related to the above-mentioned sensitive functions may specifically include: locating a second type of code segment in the above-mentioned kernel code; wherein the above-mentioned second type of code segment at least includes relevant code for performing mutual exclusive access to the above-mentioned shared virtual resources through lock operations or atomic operations; determining the allocation function contained in the above-mentioned second type of code segment for allocating the above-mentioned shared virtual resources to at least part of the above-mentioned containers as the sensitive function contained in the above-mentioned kernel code; and determining the shared virtual resources referenced by the above-mentioned allocation function as the shared virtual resources related to the above-mentioned sensitive function.

[0084] For example, the spin lock aio_nr_lock can be used to limit the maximum number of aio in the Linux system. Through the spin lock aio_nr_lock, the second type of code segment shown below can be located in the kernel code of the above Linux system.

[0085] struct kioctx*ioctx_alloc()

[0086] {

[0087] spin_lock(&aio_nr_lock); / *Lock operation, used to obtain spin lock aio_nr_lock* /

[0088] ... / *Related code for accessing shared virtual resources struct kioctx* /

[0089] spin_unlock(&aio_nr_lock); / *unlock operation* /

[0090] }

[0091] After locating the second type of code segment shown above, which includes mutually exclusive access to the shared virtual resource struct kioctx through a lock operation, the allocation function ioctx_alloc() contained in the above second type of code segment can be determined as the sensitive function f2 contained in the above kernel code; and the shared virtual resource struct kioctx referenced by the allocation function ioctx_alloc() can be determined as the shared virtual resource R2 related to the sensitive function f2.

[0092] It should be noted that in the implementation shown above, only the lock operation implemented using the spin lock aio_nr_lock is described as an example. For the specific implementation methods of lock operations implemented using other methods and other mutually exclusive access means, please refer to the relevant technology and will not be repeated here.

[0093] In addition, it should be noted that in this specification, either the implementation method of locating the above-mentioned first type of code segment or the above-mentioned second type of code segment can be used to identify sensitive functions in the above-mentioned kernel code and shared virtual resources related to the above-mentioned sensitive functions, or the above-mentioned two implementation methods can be used at the same time to identify the above-mentioned sensitive functions and the above-mentioned shared virtual resources, which helps to obtain more comprehensive analysis results.

[0094] In this specification, after identifying the sensitive functions contained in the above-mentioned kernel code and the shared virtual resources related to the above-mentioned sensitive functions, it can be determined whether the system calls initiated by several containers carried by the above-mentioned Linux system trigger the above-mentioned sensitive functions, that is, it can be further determined whether the above-mentioned containers can use the shared virtual resources related to the above-mentioned sensitive functions.

[0095] For example, after identifying the sensitive function f1 contained in the above kernel code and the shared virtual resource R1 related to the sensitive function f1, determine whether the system calls initiated by several containers carried by the above Linux system can trigger the sensitive function f1, that is, determine whether the above containers can use the shared virtual resource R1 related to the sensitive function f1.

[0096] During implementation, the process of determining whether the system calls initiated by the above-mentioned containers trigger the above-mentioned sensitive functions may specifically include: obtaining all system calls initiated by the above-mentioned containers based on the program control flow graph of the above-mentioned Linux system generated by scanning the kernel code of the above-mentioned Linux system, and determining in turn whether each of all the system calls initiated by the above-mentioned containers triggers the above-mentioned sensitive functions; if any target system call initiated by any target container among the above-mentioned containers triggers the above-mentioned sensitive function, determining that the system call initiated by the above-mentioned target container triggers the above-mentioned sensitive function.

[0097] For example, by scanning the kernel code of the above-mentioned Linux system, the sensitive function f1 contained in the above-mentioned kernel code and the shared virtual resource R1 related to the sensitive function f1 can be identified, and a program control flow graph of the above-mentioned Linux system can be generated; according to the above-mentioned program control flow graph, all system calls initiated by each container can be obtained for several containers carried in the above-mentioned Linux system, and it can be determined in turn whether all system calls initiated by each container can trigger the sensitive function f1; if any target system call initiated by a target container triggers the sensitive function f1, it can be determined that the system call initiated by the above-mentioned target container triggers the sensitive function f1.

[0098] In this specification, if a system call initiated by any target container among the above-mentioned several containers triggers the above-mentioned sensitive function, the shared virtual resources related to the above-mentioned sensitive function can be determined as a potential attack target of the DoS attack on the above-mentioned target container.

[0099] For example, if a system call initiated by any target container among the above-mentioned containers can trigger the sensitive function f1, it can be considered that the above-mentioned target container can use the shared virtual resource R1 related to the sensitive function f1, and the shared virtual resource R1 related to the sensitive function f1 can be determined as a potential attack target for DoS attack on the above-mentioned target container.

[0100] In actual applications, if the system calls initiated by several containers carried in the above-mentioned Linux system cannot trigger the above-mentioned sensitive functions, it can be considered that the above-mentioned containers cannot use the shared virtual resources related to the above-mentioned sensitive functions. Therefore, it can be considered that the above-mentioned containers cannot use the above-mentioned shared virtual resources as potential attack targets for DoS attacks.

[0101] In addition, in addition to determining whether the system calls initiated by the above-mentioned containers trigger the above-mentioned sensitive functions, the analysis results can also be filtered by one or more of the following methods, that is, from the above-mentioned shared virtual resources identified, further determine the shared virtual resources that can be used by the target container.

[0102] <Method 1>

[0103] In practical applications, it is possible to determine whether system calls initiated by the containers are restricted by the Linux kernel's seccomp mechanism to determine whether the containers can use the shared virtual resources. The seccomp mechanism is a security feature of the Linux kernel that restricts system calls initiated from user space to the kernel. Specifically, the seccomp configuration information for each container can indicate whether to prohibit or allow system calls initiated by the container. The specific implementation of the seccomp mechanism can be found in related art and will not be detailed here.

[0104] This shows that if the system call initiated by a container is restricted by the above-mentioned seccomp mechanism, then the container cannot actually trigger the above-mentioned sensitive functions, and cannot cause a DoS attack on the above-mentioned shared virtual resources.

[0105] In an illustrated embodiment, it is determined whether the system calls initiated by the several containers trigger the sensitive function. If the system call initiated by any target container among the several containers triggers the sensitive function, the seccomp configuration information for the target container is further read to determine whether the seccomp configuration information indicates that the system call that triggered the sensitive function is prohibited. If the seccomp configuration information does not indicate that the system call that triggered the sensitive function is prohibited, the shared virtual resources related to the sensitive function are determined as potential attack targets for a DoS attack against the target container.

[0106] For example, if the target system call initiated by the target container can trigger the sensitive function f1, the seccomp configuration information for the target container can be further read to determine whether the seccomp configuration information indicates that the target system call is prohibited; if the seccomp configuration information does not indicate that the target system call is prohibited, it can be considered that the target container can use the shared virtual resource R1 related to the sensitive function f1 by initiating the target system call, and the shared virtual resource R1 can be determined as a potential attack target for a DoS attack on the target container.

[0107] In another illustrated embodiment, seccomp configuration information for the plurality of containers is read, and a determination is made as to whether the seccomp configuration information indicates prohibition of system calls initiated by the plurality of containers. Furthermore, a determination is made as to whether a system call not prohibited by the seccomp configuration information triggers the sensitive function. If a system call not prohibited by the seccomp configuration information and initiated by any target container among the plurality of containers triggers the sensitive function, the shared virtual resource associated with the sensitive function is determined as a potential target for a DoS attack against the target container.

[0108] For example, the seccomp configuration information for the above-mentioned containers can be read first, and the system calls that can actually be initiated by the above-mentioned containers can be determined among all the system calls initiated by the above-mentioned containers; further, it can be determined whether the system calls that can actually be initiated by the above-mentioned containers can trigger the sensitive function f1; if the system call that can actually be initiated by any target container among the above-mentioned containers triggers the sensitive function f1, the shared virtual resource R1 related to the sensitive function f1 can be determined as a potential attack target for the DoS attack on the above-mentioned target container.

[0109] <Method 2>

[0110] In practical applications, it is possible to determine whether the shared virtual resources used by the containers are restricted by the Per-User Quota function (also known as the Rlimit mechanism) to determine whether the shared virtual resources can be used as potential targets for DoS attacks. The Rlimit mechanism is a security feature of the Linux kernel that can set usage limits on certain Linux system resources for containers or processes, i.e., resource quotas for each container.

[0111] This shows that if a container's use of the shared virtual resources is restricted by the Per-User Quota function, the container cannot use shared virtual resources that exceed its resource quota, and cannot cause a DoS attack on the shared virtual resources.

[0112] In one embodiment shown, it is determined whether the system calls initiated by the above-mentioned several containers trigger the above-mentioned sensitive function; if the system call initiated by any target container among the above-mentioned several containers triggers the above-mentioned sensitive function, it is further determined whether the restriction check operation of the shared virtual resources related to the above-mentioned sensitive function is performed on the above-mentioned target container on all triggering paths of the system call initiated by the above-mentioned target container triggering the above-mentioned sensitive function; if the restriction check operation of the shared virtual resources related to the above-mentioned sensitive function is not performed on the above-mentioned target container on all the above-mentioned triggering paths, the shared virtual resources related to the above-mentioned sensitive function are determined as potential attack targets of DoS attack for the above-mentioned target container.

[0113] For example, if the target system call initiated by the above-mentioned target container can trigger the sensitive function f1, it can be further determined whether the Rlimit operation related to the shared virtual resource R1 is performed on the above-mentioned target container on all trigger paths of the above-mentioned target system call initiated by the above-mentioned target container to trigger the sensitive function f1; if the Rlimit operation related to the shared virtual resource R1 is performed on the above-mentioned target container on all the above-mentioned trigger paths, it is considered that the above-mentioned target container cannot use the shared virtual resource R1 as a potential attack target for DoS attack; otherwise, the shared virtual resource R1 is determined as a potential attack target for DoS attack by the above-mentioned target container.

[0114] In the embodiment described above, if the restriction check operation for the shared virtual resource associated with the sensitive function is not performed on the target container along all trigger paths, in addition to determining the target container as a potential target for a DoS attack, the potential attack path for the target container can also be determined. During implementation, the method may further include determining the trigger paths for which the restriction check operation for the shared virtual resource is not performed on the target container as potential attack paths for a DoS attack against the target container.

[0115] For example, if the target system call initiated by the above-mentioned target container can trigger the sensitive function f1, it can be further determined whether the Rlimit operation related to the shared virtual resource R1 is performed on the above-mentioned target container on all trigger paths of the above-mentioned target system call initiated by the above-mentioned target container to trigger the sensitive function f1; if the Rlimit operation related to the shared virtual resource R1 is not performed on the above-mentioned target container on all the above-mentioned trigger paths, the shared virtual resource R1 can be determined as a potential attack target of the DoS attack on the above-mentioned target container, and the trigger path on which the Rlimit operation related to the shared virtual resource R1 is not performed on the above-mentioned target container can be determined as a potential attack path for the DoS attack on the above-mentioned target container.

[0116] <Method 3>

[0117] In practical applications, whether the shared virtual resources are isolated by the Linux kernel's namespace mechanism can be determined to determine whether the containers can use the shared virtual resources. The namespace mechanism can be used to partition and isolate system resources in the Linux kernel. If the virtual resource corresponding to a system resource contains a pointer to a namespace, it indicates that the system resource has been isolated for use by a specific container.

[0118] It can be seen from this that if the above-mentioned shared virtual resources are isolated by the namespace mechanism, then in fact the shared virtual resources will not be allocated to other containers, and will not cause a DoS attack.

[0119] In one embodiment shown, it is determined whether the system call initiated by the above-mentioned several containers triggers the above-mentioned sensitive function; if the system call initiated by any target container among the above-mentioned several containers triggers the above-mentioned sensitive function, it is further determined whether the shared virtual resources related to the above-mentioned sensitive function contain a pointer to the namespace; if the shared virtual resources related to the above-mentioned sensitive function do not contain a pointer to the namespace, the shared virtual resources related to the above-mentioned sensitive function are determined to be potential attack targets for DoS attacks on the above-mentioned target containers.

[0120] For example, if the target system call initiated by the above-mentioned target container can trigger the sensitive function f1, it can be further determined whether the shared virtual resource R1 related to the sensitive function f1 contains a pointer to the namespace; if not, the shared virtual resource R1 can be determined as a potential attack target for the DoS attack on the above-mentioned target container.

[0121] In another embodiment shown, it can be determined first whether the shared virtual resources related to the above-mentioned sensitive function contain a pointer to the namespace; if the shared virtual resources related to the above-mentioned sensitive function do not contain a pointer to the namespace, it is further determined whether the system call initiated by the above-mentioned containers triggers the above-mentioned sensitive function; if the system call initiated by any target container among the above-mentioned containers triggers the above-mentioned sensitive function, the shared virtual resources related to the above-mentioned sensitive function will be determined as a potential attack target for the DoS attack on the above-mentioned target container.

[0122] For example, we can first determine whether the shared virtual resource R1 related to the sensitive function f1 contains a pointer to the namespace; if not, we can further determine whether the system call initiated by the above-mentioned containers triggers the sensitive function f1; if the target system call initiated by any target container among the above-mentioned containers triggers the sensitive function f1, then the shared virtual resource R1 can be determined as a potential attack target for the DoS attack of the above-mentioned target container.

[0123] It should be noted that, in each of the embodiments shown above, only one of the above-mentioned methods 1, 2, and 3 is used to filter the analysis results. In addition, multiple methods of the above-mentioned methods 1, 2, and 3 can also be used to filter the analysis results. Those skilled in the art can derive the results without creative work based on the embodiments shown in this specification, and will not be elaborated here one by one.

[0124] Through the above technical solution, it can be seen that by scanning the kernel code of the Linux system, all shared virtual resources provided by the Linux system kernel can be identified first, and then the shared virtual resources that can be used by the target container can be determined from all the identified shared virtual resources, that is, the potential attack targets of the target container for DoS attack, thereby automatically analyzing the potential attack targets of DoS attack on several containers installed in the Linux system, and thus helping technicians develop more secure containers.

[0125] Corresponding to the above-mentioned embodiment of the shared virtual resource analysis method, this specification also provides an embodiment of a shared virtual resource analysis device.

[0126] See Figure 2 , Figure 2This is a hardware structure diagram of an electronic device where a shared virtual resource analysis device is located, shown as an exemplary embodiment. At the hardware level, the device includes a processor 202, an internal bus 204, a network interface 206, a memory 208, and a non-volatile memory 210, and may also include hardware required for other services. One or more embodiments of this specification can be implemented based on software, such as the processor 202 reading the corresponding computer program from the non-volatile memory 210 into the memory 208 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logical devices or a combination of hardware and software, etc., that is, the execution subject of the following processing flow is not limited to each logical unit, but can also be hardware or logical devices.

[0127] See Figure 3 , Figure 3 This is a block diagram of a shared virtual resource analysis device according to an exemplary embodiment. Figure 2 The electronic device shown in FIG. 1 is used to implement the technical solution of this specification. The shared virtual resource analysis device may include:

[0128] The identification unit 302 is configured to scan the kernel code of the Linux system and identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions; wherein the sensitive functions are functions related to the use of the shared virtual resources;

[0129] The determination unit 304 is used to determine whether the system call initiated by the above-mentioned several containers triggers the above-mentioned sensitive function; if the system call initiated by any target container among the above-mentioned several containers triggers the above-mentioned sensitive function, the shared virtual resources related to the above-mentioned sensitive function will be determined as a potential attack target of the DoS attack on the above-mentioned target container.

[0130] In this embodiment, the sensitive function includes an allocation function for allocating the shared virtual resource to at least part of the containers.

[0131] In this embodiment, the identification unit 302 is specifically configured to:

[0132] Get the kernel parameters of the above Linux system;

[0133] Locating a first type of code segment containing the kernel parameters in the kernel code; wherein the first type of code segment at least includes relevant code for performing a restriction check on the use of the shared virtual resource using the kernel parameters;

[0134] The allocation function contained in the first type of code segment and used to allocate the shared virtual resources to at least part of the containers is determined as a sensitive function contained in the kernel code; and the shared virtual resources referenced by the allocation function are determined as shared virtual resources related to the sensitive function.

[0135] In this embodiment, the identification unit 302 is specifically configured to:

[0136] Locating a second type of code segment in the kernel code; wherein the second type of code segment at least includes relevant code for mutually exclusive access to the shared virtual resource through a lock operation or an atomic operation;

[0137] The allocation function contained in the second type of code segment and used to allocate the shared virtual resources to at least part of the containers is determined as a sensitive function contained in the kernel code; and the shared virtual resources referenced by the allocation function are determined as shared virtual resources related to the sensitive function.

[0138] In this embodiment, the determining unit 304 is specifically configured to:

[0139] If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further reading the seccomp configuration information for the target container and determining whether the seccomp configuration information indicates prohibiting the system call that triggered the sensitive function;

[0140] If the seccomp configuration information does not indicate prohibiting the system call that triggers the sensitive function, the shared virtual resources related to the sensitive function are determined as potential attack targets for the DoS attack on the target container.

[0141] In this embodiment, the determining unit 304 is specifically configured to:

[0142] If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further determining whether a restriction check operation on the shared virtual resources related to the sensitive function has been performed on the target container along all triggering paths of the system call initiated by the target container that triggers the sensitive function;

[0143] If the restriction check operation of the shared virtual resources related to the sensitive function is not performed on the target container on all the trigger paths, the shared virtual resources related to the sensitive function will be determined as a potential attack target of the DoS attack on the target container.

[0144] In this embodiment, the determining unit 304 is further configured to:

[0145] A trigger path for which no restriction check operation of the shared virtual resource is performed on the target container is determined as a potential attack path for a DoS attack on the target container.

[0146] In this embodiment, the determining unit 304 is specifically configured to:

[0147] If the system call initiated by any target container among the above-mentioned several containers triggers the above-mentioned sensitive function, it is further determined whether the shared virtual resource related to the above-mentioned sensitive function contains a pointer to the namespace;

[0148] If the shared virtual resource associated with the sensitive function does not include a pointer to the namespace, the shared virtual resource associated with the sensitive function is determined as a potential attack target for the DoS attack on the target container.

[0149] In this embodiment, the determining unit 304 is specifically configured to:

[0150] Based on a program control flow graph of the Linux system generated by scanning the kernel code, all system calls initiated by the containers are obtained, and each of the system calls initiated by the containers triggers the sensitive function.

[0151] If any system call initiated by any target container among the plurality of containers triggers the sensitive function, it is determined that the system call initiated by the target container triggers the sensitive function.

[0152] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0153] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying any creative work.

[0154] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0155] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0156] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0157] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0158] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0159] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0160] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0161] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

[0162] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A shared virtual resource analysis method, characterized in that: The method is applied to a terminal device equipped with a Linux system; the Linux system is equipped with a plurality of mutually isolated containers corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources include shared virtual resources that can be shared by at least some of the plurality of containers; the method comprises: Scanning kernel code of the Linux system to identify sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions; wherein the sensitive functions include allocation functions for allocating the shared virtual resources to at least part of the containers; Determining whether the system calls initiated by the plurality of containers trigger the sensitive function; If a system call initiated by any target container among the plurality of containers triggers the sensitive function, the shared virtual resources related to the sensitive function are determined as potential attack targets of a DoS attack on the target container.

2. The method according to claim 1, characterized in that The identifying of sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions includes: Obtain kernel parameters of the Linux system; Locating a first type of code segment containing the kernel parameters in the kernel code; wherein the first type of code segment at least includes relevant code for using the kernel parameters to perform a restriction check on the use of the shared virtual resource; The allocation function contained in the first type of code segment and used to allocate the shared virtual resources to the at least part of the container is determined as a sensitive function contained in the kernel code; and the shared virtual resources referenced by the allocation function are determined as shared virtual resources related to the sensitive function.

3. The method according to claim 1, characterized in that The identifying of sensitive functions contained in the kernel code and shared virtual resources related to the sensitive functions includes: Locating a second type of code segment in the kernel code; wherein the second type of code segment at least includes relevant code for performing mutually exclusive access to the shared virtual resource through a lock operation or an atomic operation; The allocation function contained in the second type of code segment and used to allocate the shared virtual resources to the at least part of the container is determined as a sensitive function contained in the kernel code; and the shared virtual resources referenced by the allocation function are determined as shared virtual resources related to the sensitive function.

4. The method according to claim 1, wherein If a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target of a DoS attack on the target container includes: If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further reading seccomp configuration information for the target container and determining whether the seccomp configuration information indicates prohibiting the system call that triggered the sensitive function; If the seccomp configuration information does not indicate prohibiting the system call that triggers the sensitive function, the shared virtual resources related to the sensitive function are determined as potential attack targets of the DoS attack on the target container.

5. The method according to claim 1, wherein If a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target of a DoS attack on the target container includes: If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further determining whether a restriction check operation on the shared virtual resources related to the sensitive function is performed on the target container along all triggering paths of the system call initiated by the target container triggering the sensitive function; If the restriction check operation of the shared virtual resources related to the sensitive function is not performed on the target container on all the trigger paths, the shared virtual resources related to the sensitive function are determined as potential attack targets of the DoS attack on the target container.

6. The method according to claim 5, characterized in that The method further comprises: A trigger path for which no restriction check operation of the shared virtual resource is performed on the target container is determined as a potential attack path for a DoS attack on the target container.

7. The method according to claim 1, characterized in that If a system call initiated by any target container among the plurality of containers triggers the sensitive function, determining the shared virtual resources related to the sensitive function as a potential attack target of a DoS attack on the target container includes: If a system call initiated by any target container among the plurality of containers triggers the sensitive function, further determining whether a shared virtual resource related to the sensitive function includes a pointer to a namespace; If the shared virtual resource related to the sensitive function does not include a pointer to the namespace, the shared virtual resource related to the sensitive function is determined as a potential attack target for the DoS attack on the target container.

8. The method according to claim 1, characterized in that The determining whether the system calls initiated by the plurality of containers trigger the sensitive function includes: Obtaining, based on a program control flow graph of the Linux system generated by scanning the kernel code, all system calls initiated by the plurality of containers, and determining in sequence whether each of all the system calls initiated by the plurality of containers triggers the sensitive function; If any system call initiated by any target container among the plurality of containers triggers the sensitive function, it is determined that the system call initiated by the target container triggers the sensitive function.

9. A shared virtual resource analysis device, characterized in that: The invention is applied to a terminal device equipped with a Linux system; the Linux system is equipped with a plurality of mutually isolated containers corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources include shared virtual resources that can be shared by at least some of the plurality of containers; the device comprises: an identification unit, configured to scan kernel code of the Linux system, identify sensitive functions contained in the kernel code, and shared virtual resources related to the sensitive functions; wherein the sensitive functions include an allocation function for allocating the shared virtual resources to at least part of the containers; A determination unit is configured to determine whether the system call initiated by the plurality of containers triggers the sensitive function; if the system call initiated by any target container among the plurality of containers triggers the sensitive function, the shared virtual resources associated with the sensitive function are determined as potential attack targets for a DoS attack on the target container.

10. An electronic device, characterized in that: It includes a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 8 by calling the machine-readable instructions.

11. A machine-readable storage medium, characterized in that The machine-readable storage medium stores machine-readable instructions, and when the machine-readable instructions are called and executed by a processor, the method according to any one of claims 1 to 8 is implemented.

Images