CN113849811A

CN113849811A - Shared virtual resource analysis method and device

Info

Publication number: CN113849811A
Application number: CN202111032255.2A
Authority: CN
Inventors: 申文博; 杨男子; 喻望; 秦承刚
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2021-09-03
Filing date: 2021-09-03
Publication date: 2021-12-28

Abstract

One or more embodiments of the present specification provide a method, an apparatus, an electronic device, and a machine-readable storage medium for analyzing a shared virtual resource, where the method is applied to a terminal device equipped with a Linux system, and the method includes: scanning kernel codes of the Linux system, and identifying sensitive functions contained in the kernel codes and shared virtual resources related to the sensitive functions; wherein the sensitive function is a function related to usage for the shared virtual resource; determining whether a system call initiated by the number of containers triggered the sensitive function; and if the sensitive function is triggered by the system call initiated by any target container in the plurality of containers, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

Description

Shared virtual resource analysis method and device

Technical Field

One or more embodiments of the present disclosure relate to the technical field of Linux system security, and in particular, to a method and an apparatus for analyzing a shared virtual resource, an electronic device, and a machine-readable storage medium.

Background

A container (container) is a kernel virtualization technology of a Linux system, and can be used for isolating processes and allocating system resources for each process; in other words, several containers installed in the Linux system may share the kernel of the Linux system, and may also share system resources provided by the Linux system kernel. The system resources provided by the Linux system kernel may include unshared resources allocated for a certain container and shared resources that can be shared by a part of containers.

For the shared resource, if a certain container maliciously exhausts the shared resource that can be shared by multiple containers, it may cause that the Linux system cannot normally allocate the shared resource to other containers, thereby causing a DoS (Denial of Service) attack.

Disclosure of Invention

The application provides a shared virtual resource analysis method which is applied to terminal equipment loaded with a Linux system; the Linux system is loaded with a plurality of mutually isolated containers respectively corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources comprise shared virtual resources which can be shared by at least part of the plurality of containers; the method comprises the following steps:

scanning kernel codes of the Linux system, and identifying sensitive functions contained in the kernel codes and shared virtual resources related to the sensitive functions; wherein the sensitive function is a function related to usage for the shared virtual resource;

determining whether a system call initiated by the number of containers triggered the sensitive function;

and if the sensitive function is triggered by the system call initiated by any target container in the plurality of containers, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

Optionally, the sensitive function includes an allocation function for allocating the shared virtual resource for the at least part of the container.

Optionally, the identifying a sensitive function included in the kernel code and a shared virtual resource related to the sensitive function includes:

acquiring kernel parameters of the Linux system;

locating a first type code segment containing the kernel parameter in the kernel code; wherein the first class of code sections includes at least associated code for utilizing the kernel parameters to perform a restriction check on the use of the shared virtual resource;

determining an allocation function contained in the first type code segment for allocating the shared virtual resource for the at least part of the container as a sensitive function contained in the kernel code; and determining the shared virtual resource referenced by the allocation function as the shared virtual resource related to the sensitive function.

locating a second type of code segment in the kernel code; wherein the second type code segment at least comprises related codes which carry out mutual exclusion access to the shared virtual resource through lock operation or atomic operation;

determining an allocation function contained in the second type code segment for allocating the shared virtual resource for the at least part of the container as a sensitive function contained in the kernel code; and determining the shared virtual resource referenced by the allocation function as the shared virtual resource related to the sensitive function.

Optionally, if the sensitive function is triggered by a system call initiated by any target container in the multiple containers, determining a shared virtual resource related to the sensitive function as a potential attack object for performing a DoS attack on the target container, including:

if the system call initiated by any target container in 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 that the system call triggering the sensitive function is forbidden;

and if the seccomp configuration information does not indicate that the system call triggering the sensitive function is forbidden, determining shared virtual resources related to the sensitive function as a potential attack object of the target container for DoS attack.

if the sensitive function is triggered by the system call initiated by any target container in the containers, further determining whether a limit check operation of the shared virtual resource related to the sensitive function is performed on the target container on all trigger paths of the sensitive function triggered by the system call initiated by the target container;

and if the limitation check operation of the shared virtual resources related to the sensitive function is not carried out on the target container on all the trigger paths, determining the shared virtual resources related to the sensitive function as a potential attack object of the target container for DoS attack.

Optionally, the method further includes:

and determining a trigger path without performing the limit check operation of the shared virtual resources on the target container as a potential attack path for performing the DoS attack on the target container.

if the sensitive function is triggered by a system call initiated by any target container in the containers, further determining whether a pointer to namespace is contained in the shared virtual resource related to the sensitive function;

and if the shared virtual resources related to the sensitive function do not contain a pointer pointing to namespace, determining the shared virtual resources related to the sensitive function as a potential attack object of the target container for DoS attack.

Optionally, the determining whether the system call initiated by the plurality of containers triggers the sensitive function includes:

acquiring all system calls initiated by the plurality of containers based on a program control flow graph of the Linux system generated by scanning the kernel code, and sequentially determining whether each system call in all system calls initiated by the plurality of containers triggers the sensitive function;

determining that a system call initiated by a target container of the number of containers triggers the sensitive function if any system call initiated by the target container triggers the sensitive function.

The application also provides a shared virtual resource analysis device which is applied to the terminal equipment loaded with the Linux system; the Linux system is loaded with a plurality of mutually isolated containers respectively corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources comprise shared virtual resources which can be shared by at least part of the plurality of containers; the device comprises:

the identification unit is used for scanning the kernel code of the Linux system, identifying a sensitive function contained in the kernel code and a shared virtual resource related to the sensitive function; wherein the sensitive function is a function related to usage for the shared virtual resource;

a determining unit for determining whether a system call initiated by the number of containers triggers the sensitive function; and if the sensitive function is triggered by the system call initiated by any target container in the plurality of containers, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

The application also provides an electronic device, which comprises a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are mutually connected through the bus;

the memory stores machine-readable instructions, and the processor executes the method by calling the machine-readable instructions.

The present application also provides a machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, implement the above-described method.

Through the embodiment, all shared virtual resources provided by the Linux system kernel can be identified firstly by scanning the kernel code of the Linux system, and then the shared virtual resources which can be used by the target container are determined from all the identified shared virtual resources, namely, the target container carries out the potential attack object of the DoS attack, so that the potential attack object of carrying out the DoS attack on a plurality of containers carried in the Linux system is automatically analyzed, and further, technical personnel can develop a safer container.

Drawings

FIG. 1 is a flow diagram of a shared virtual resource analysis method;

fig. 2 is a schematic structural diagram of an electronic device in which a shared virtual resource analysis apparatus is located according to an exemplary embodiment;

fig. 3 is a block diagram of a shared virtual resource analysis apparatus according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

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

In order to make those skilled in the art better understand the technical solutions in the embodiments of the present disclosure, the related technologies related to the embodiments of the present disclosure will be briefly described below.

In practical applications, if a certain container maliciously exhausts the shared resource that can be shared by multiple containers, it may cause that the Linux system cannot normally allocate the shared resource to other containers, thereby causing a DoS (Denial of Service) attack.

In order to design a more secure container, a person skilled in the art can usually perform manual analysis on the relevant code of the Linux system kernel to find out a potential attack surface; and then corresponding defense means are developed aiming at the potential attack surfaces.

Therefore, in the above embodiment, the workload of the technician is large, and much time and labor are consumed; in addition, the accuracy of the analysis result is closely related to the level of the technical staff, and the technical staff is required to have higher technical level.

Currently, no relevant tool exists in the field for automatically analyzing shared resources in the kernel of the Linux system.

In view of the above, the present specification aims to propose a static analysis tool that can identify potential attack objects of a container for DoS attacks based on automated analysis of kernel code for Linux systems.

During implementation, a terminal device equipped with a Linux system may scan a kernel code of the Linux system, and identify a sensitive function contained in the kernel code and a shared virtual resource related to the sensitive function; wherein the sensitive function is a function related to usage for the shared virtual resource;

further, it may be determined whether system calls initiated by a number of containers hosted in the Linux system trigger the identified sensitive function; if the sensitive function is triggered by a system call initiated by any target container in the plurality of containers, the shared virtual resource related to the sensitive function can be determined as a potential attack object for DoS attack on the target container.

Therefore, in the technical scheme of the specification, by scanning the kernel code of the Linux system, all shared virtual resources provided by the Linux system kernel can be identified, and then the shared virtual resources which can be used by the target container are determined from all identified shared virtual resources, that is, the target container carries out a potential attack object of DoS attack, so that the potential attack objects of the DoS attack of a plurality of containers carried in the Linux system are automatically analyzed, and further, technical personnel can be helped to develop a safer container.

Compared with a manual analysis mode, in the above-described mode of implementing automatic analysis for shared virtual resources, analysis cost can be saved, analysis efficiency is improved, and a common technician can also automatically identify a potential attack object of a container for DoS attack based on the static analysis tool, which has a low requirement on the technical level of a user.

The present application is described below with reference to specific embodiments and specific application scenarios.

Referring to fig. 1, fig. 1 is a flowchart illustrating a method for analyzing a shared virtual resource according to an exemplary embodiment. The above method may perform the steps of:

step 102: scanning a kernel code of a Linux system, and identifying a sensitive function contained in the kernel code and a shared virtual resource related to the sensitive function; wherein the sensitive function is a function related to the use of the shared virtual resource;

step 104: determining whether a system call initiated by a plurality of containers hosted by the Linux system triggers the sensitive function;

step 106: and if the sensitive function is triggered by the system call initiated by any one of the plurality of containers, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

In this specification, the above method may be applied to a terminal device equipped with a Linux system. The terminal device may include one server equipped with a Linux system, a server cluster formed by a plurality of servers, or may include a client-side network device equipped with a Linux system, and the present specification is not particularly limited.

For example, the terminal device may specifically include a network device loaded with a shared virtual resource analysis tool or a potential attack plane detection program.

In this specification, the Linux system is loaded with a plurality of containers which respectively correspond to different tenants and are isolated from each other; the Linux system kernel can provide a plurality of virtual resources.

The virtual resource may be a global variable or a structural body corresponding to a system resource provided by the Linux system kernel in the kernel code of the Linux system; the process of allocating system resources to a certain container by a Linux system kernel is usually embodied as allocating corresponding virtual resources to the container in a kernel code of the Linux system. For example, in a memory management mechanism of a Linux system, a memory may be generally divided into a plurality of physical pages (page frames, which may also be referred to as page frames and page frames), each page frame may include one page (page), a Linux kernel may generally use a memory page (page) as a basic unit for memory management, and in an kernel code, a physical page may be represented by a structure "struct page", that is, a virtual resource corresponding to a system resource memory page is a structure struct page.

In this specification, the plurality of virtual resources may include a shared virtual resource that can be shared by at least some of the plurality of containers. Accordingly, the shared virtual resource may correspond to a shared system resource provided by the Linux system kernel, and is not described herein again.

In this specification, the kernel code of the Linux system may be scanned, and the sensitive function included in the kernel code and the shared virtual resource related to the sensitive function may be identified.

Scanning kernel codes of the Linux system, that is, scanning LLVM IR (middle Representation of LLVM compiler) of the Linux system kernel; the LLVM IR is an intermediate language code independent of the source programming language and the target machine architecture, and can generally have three expressions, respectively: the compiled intermediate language in the memory, the binary code in the disk, and the readable assembly text, the three forms of LLVM IR described above are substantially equivalent, and the present specification is not limited in particular.

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

For example, 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, and the analysis result can be conveniently and further filtered subsequently.

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

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

For example, the sensitive function f1 may specifically include an allocation function alloc _ empty _ file (), which is used to allocate a shared virtual resource struct file to some containers; for another example, the sensitive function f2 may specifically include an allocation function ioctx _ alloc () used to allocate a shared virtual resource struct kit for some containers.

In one embodiment, the execution logic of the allocation function for allocating the shared virtual resource may generally include: in response to an application operation for the shared virtual resource from a certain container, firstly, using a kernel parameter related to the shared virtual resource to perform limit check, and if the limit check passes, allocating the shared virtual resource for the container; therefore, by locating the limit check operation in the kernel code, the allocation function and the shared virtual resource can be identified.

The kernel parameters are related to the system performance of the Linux system. For example, the kernel parameter files _ stat.max _ files may be used to limit the maximum number of files that can be opened in the Linux system; for other kernel parameters, reference may be made to related technologies, which are not described in detail in this specification.

In implementation, the process of identifying the sensitive function included in the kernel code and the shared virtual resource related to the sensitive function may specifically include: acquiring kernel parameters of the Linux system; locating a first type code segment containing the kernel parameter in the kernel code; wherein, the first type code segment at least comprises relevant codes for utilizing the kernel parameter to carry out restriction check on the use of the shared virtual resource; determining an allocation function included in the first type code segment, for allocating the shared virtual resource to the at least part of containers, as a sensitive function included in the kernel code; and determining the shared virtual resource quoted by the allocation function as the shared virtual resource related to the sensitive function.

For example, the kernel parameter files _ stat.max _ files of the Linux system can be obtained, and in the kernel code of the Linux system, the first type code segment shown as follows is located,

struct file*alloc_empty_file()

{

… …/. The associated code: @ that performs a limit check using the kernel parameter files _ stat

… …/. The associated code for allocating a shared virtual resource struct file +

}

After locating the first type code segment containing the kernel parameter files _ stat.max _ files as described above, the allocation function alloc _ empty _ file () contained in the first type code segment may be determined as the sensitive function f1 contained in the kernel code; and, the shared virtual resource struct file referenced by the allocation function alloc _ instance _ file () may be determined as the shared virtual resource R1 related to the sensitive function f 1.

In the above illustrated embodiment, the specific implementation manner for acquiring the kernel parameter of the Linux system is not particularly limited in this specification.

For example, modifiable kernel parameters in a Linux system may be usually stored in a directory/proc/sys, and each kernel parameter may correspond to one kernel file, so that the kernel files/proc/sys/files _ stat/max _ files in the directory may be read to obtain the kernel parameters files _ stat.

For another example, the kernel parameter may be stored as a variable in a configuration file sysctl.conf, and the variable in the configuration file may be read and set by a sysctl instruction, so as to obtain the kernel parameter of the Linux system.

In another embodiment, since the mutually exclusive access to the shared virtual resource may be generally implemented by means of a lock operation, an atomic operation, or the like, the sensitive function and the shared virtual resource related to the sensitive function may be identified by locating the lock operation and/or the atomic operation in the kernel code.

In implementation, the process of identifying the sensitive function included in the kernel code and the shared virtual resource related to the sensitive function may specifically include: positioning a second type code segment in the kernel code; wherein, the second code segment at least comprises related codes which carry out mutual exclusion access to the shared virtual resource through lock operation or atomic operation; determining an allocation function included in the second type code segment, which is used for allocating the shared virtual resource to the at least part of containers, as a sensitive function included in the kernel code; and determining the shared virtual resource quoted by the allocation function as the shared virtual resource related to the sensitive function.

For example, a spin lock aio nr lock may be used to limit the maximum aio number for a Linux system, by which a second class of code segments may be located in the kernel code of the Linux system as shown below,

struct kioctx*ioctx_alloc()

{

spin _ lock (& aio _ nr _ lock); v lock operation to acquire spin lock aio _ nr _ lock @

… …/. The relevant code for accessing the shared virtual resource struct kioctx >

spin _ unlock (& aio _ nr _ lock); v unlocking operation

}

After locating the second type of code segment that includes the exclusive access to the shared virtual resource struct kit by the lock operation, the allocation function ioctx _ alloc () included in the second type of code segment may be determined as the sensitive function f2 included in the kernel code; and, the shared virtual resource struct kiotx referenced by the allocation function ioctx _ alloc () may be determined as the shared virtual resource R2 related to the sensitive function f 2.

It should be noted that, in the above illustrated embodiment, only the lock operation implemented by using the spin lock aio _ nr _ lock is described as an example, and for the specific implementation of the lock operation implemented by using other manners and other mutual exclusion access means, please refer to related technologies, which is not described herein again.

In addition, in this specification, an implementation manner of locating the first type code segment or the second type code segment may be adopted to identify a sensitive function in the kernel code and a shared virtual resource related to the sensitive function, or the two implementation manners may be adopted to identify the sensitive function and the shared virtual resource at the same time, which is beneficial to obtaining a more comprehensive analysis result.

In this specification, after identifying the sensitive function included in the kernel code and the shared virtual resource related to the sensitive function, it may be determined whether a system call initiated by a plurality of containers hosted by the Linux system triggers the sensitive function, that is, it may be further determined whether the plurality of containers may use the shared virtual resource related to the sensitive function.

For example, after identifying the sensitive function f1 included in the kernel code and the shared virtual resource R1 associated with the sensitive function f1, it is determined whether the sensitive function f1 can be triggered by system calls initiated by the containers hosted by the Linux system, that is, whether the shared virtual resource R1 associated with the sensitive function f1 can be used by the containers.

In implementation, the determining whether the system call initiated by the plurality of containers triggers the sensitive function may specifically include: acquiring all system calls initiated by the plurality of containers based on a program control flow graph of the Linux system generated by scanning kernel codes of the Linux system, and sequentially determining whether each system call in all system calls initiated by the plurality of containers triggers the sensitive function; and if any target system call initiated by any target container in the plurality of containers triggers the sensitive function, determining that the system call initiated by the target container triggers the sensitive function.

For example, scanning the kernel code of the Linux system, identifying the sensitive function f1 contained in the kernel code and the shared virtual resource R1 associated with the sensitive function f1, and generating a program control flow graph of the Linux system; according to the program control flow graph, all system calls initiated by each container can be acquired for a plurality of containers loaded in the Linux system, and whether all the system calls initiated by each container can trigger a sensitive function f1 can be determined in sequence; if any target system call initiated by a target container triggers a sensitive function f1, it may be determined that the system call initiated by the target container triggers a sensitive function f 1.

In this specification, if a system call initiated by any one of the plurality of containers triggers the sensitive function, the shared virtual resource associated with the sensitive function may be determined as a potential attack object for the target container to perform a DoS attack.

For example, if a system call initiated by any one of the several containers may trigger the sensitive function f1, and it may be considered that the target container may use the shared virtual resource R1 associated with the sensitive function f1, the shared virtual resource R1 associated with the sensitive function f1 may be determined as a potential attack object of the target container for DoS attack.

In practical application, if the system call initiated by the plurality of containers loaded in the Linux system cannot trigger the sensitive function, the plurality of containers may be considered to be unable to use the shared virtual resource related to the sensitive function, and then the plurality of containers may be considered to be unable to use the shared virtual resource as a potential attack object for performing the DoS attack.

In addition, in addition to determining whether the system call initiated by the containers triggers the sensitive function, the analysis result may be filtered in one or more ways shown below, that is, the shared virtual resources that can be used by the target container are further determined from the identified shared virtual resources.

< first mode >

In practical applications, it may be determined whether the system call initiated by the containers is limited by the seccomp mechanism of the Linux system kernel to determine whether the containers can use the shared virtual resource. The seccomp mechanism is a security function of a Linux system kernel, and may be configured to limit a system call initiated from a user space to the kernel, that is, in the seccomp configuration information for each container, it may indicate that the system call initiated by the container is prohibited or allowed; for a specific implementation manner of the seccomp mechanism, reference may be made to related technologies, which are not described herein again.

Therefore, if a system call initiated by a certain container is limited by the seccomp mechanism, the container cannot actually trigger the sensitive function, and thus DoS attacks cannot be caused on the shared virtual resource.

In one embodiment shown, it is determined whether system calls initiated by the number of containers trigger the sensitive function; if the system call initiated by any one of 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 that the system call triggering the sensitive function is prohibited; and if the seccomp configuration information does not indicate that the system call triggering the sensitive function is forbidden, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

For example, if a target system call initiated by the target container may trigger the sensitive function f1, seccomp configuration information for the target container may be further read, and it may be determined 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 may be considered that the target container may use the shared virtual resource R1 associated with the sensitive function f1 by initiating the target system call, and then the shared virtual resource R1 may be determined as a potential attack object of the target container for DoS attack.

In another embodiment shown, seccomp configuration information for the containers is read, and it is determined whether the seccomp configuration information indicates that system calls initiated by the containers are prohibited; further, determining whether the sensitive function is triggered by a system call whose seccomp configuration information does not indicate prohibition; and if the seccomp configuration information does not indicate that the prohibited system call initiated by any target container in the plurality of containers triggers the sensitive function, determining the shared virtual resource related to the sensitive function as a potential attack object for the target container to carry out the DoS attack.

For example, the seccomp configuration information for the containers may be read first, and among all system calls initiated by the containers, the system calls that the containers may actually initiate may be determined; further, whether the sensitive function f1 can be triggered by the system calls which can be actually initiated by the containers is determined; if the sensitive function f1 is triggered by a system call that can be actually initiated by any one of the several containers, the shared virtual resource R1 associated with the sensitive function f1 may be determined as a potential attack object for the target container to perform a DoS attack.

< second mode >

In practical applications, it may be determined whether the usage of the shared virtual resources by the containers is limited by a Per-User quantum function (i.e., Rlimit mechanism), so as to determine whether the containers can use the shared virtual resources as potential attack objects for DoS attacks. The Rlimit mechanism is a security function of the Linux system kernel, and can set a use limit for some system resources in the Linux system for a container or a process, that is, a resource quota of each container.

Therefore, if the use of a certain container for the shared virtual resource is limited by the Per-User quantum function, the container cannot use the shared virtual resource beyond the resource Quota of the container, and thus DoS attacks on the shared virtual resource cannot be caused.

In one embodiment shown, it is determined whether system calls initiated by the number of containers trigger the sensitive function; if the sensitive function is triggered by the system call initiated by any target container in the plurality of containers, further determining whether the limit check operation of the shared virtual resource related to the sensitive function is performed on the target container on all trigger paths of the sensitive function triggered by the system call initiated by the target container; and if the limit check operation of the shared virtual resources related to the sensitive function is not performed on all the trigger paths aiming at the target container, determining the shared virtual resources related to the sensitive function as a potential attack object of the target container for DoS attack.

For example, if the target system call initiated by the target container may trigger the sensitive function f1, it may be further determined whether Rlimit operations related to the shared virtual resource R1 are performed on the target container on all trigger paths of the target system call trigger sensitive function f1 initiated by the target container; if the Rlimit operation related to the shared virtual resource R1 is performed on all the trigger paths for the target container, the target container is considered to be unable to take the shared virtual resource R1 as a potential attack object for performing a DoS attack; otherwise, the shared virtual resource R1 is determined as a potential attack object of the target container for DoS attack.

In the above illustrated embodiment, if the constraint check operation of the shared virtual resource related to the sensitive function is not performed on all the trigger paths with respect to the target container, in addition to determining a potential attack object of the target container for performing a DoS attack, a potential attack path of the target container for performing the DoS attack may be determined. When implemented, the method may further comprise: and determining a trigger path which does not perform the limit check operation of the shared virtual resources aiming at the target container as a potential attack path for performing the DoS attack on the target container.

For example, if the target system call initiated by the target container may trigger the sensitive function f1, it may be further determined whether Rlimit operations related to the shared virtual resource R1 are performed on the target container on all trigger paths of the target system call trigger sensitive function f1 initiated by the target container; if the Rlimit operations related to the shared virtual resource R1 are not performed on all the trigger paths with respect to the target container, the shared virtual resource R1 may be determined as a potential attack object of the target container for DoS attack, and the trigger path without the Rlimit operations related to the shared virtual resource R1 may be determined as a potential attack path of the target container for DoS attack.

< third mode >

In practical applications, it may be determined whether the shared virtual resource is isolated by a namespace mechanism of a Linux system kernel, so as to determine whether the plurality of containers can use the shared virtual resource. The namespace mechanism can be used for realizing system resource division and isolation in a Linux system kernel; if the virtual resource corresponding to a certain system resource contains a pointer pointing to namespace, the system resource is actually isolated and used for a certain container.

Therefore, if the shared virtual resource is isolated by the namespace mechanism, the shared virtual resource is not actually allocated to other containers, and DoS attack is not caused.

In one embodiment shown, it is determined whether system calls initiated by the number of containers trigger the sensitive function; if the sensitive function is triggered by a system call initiated by any one of the plurality of containers, further determining whether a pointer pointing to namespace is contained in the shared virtual resource related to the sensitive function; and if the shared virtual resources related to the sensitive functions do not contain a pointer pointing to namespace, determining the shared virtual resources related to the sensitive functions as a potential attack object for the target container to carry out the DoS attack.

For example, if a target system call initiated by the target container may trigger the sensitive function f1, it may be further determined whether a pointer to namespace is contained in the shared virtual resource R1 associated with the sensitive function f 1; if not, the shared virtual resource R1 may be determined to be a potential attack object for the target container to perform a DoS attack.

In another embodiment shown, it may be determined whether a pointer to namespace is included in the shared virtual resource associated with the sensitive function; if the shared virtual resource related to the sensitive function does not contain a pointer pointing to namespace, further determining whether the sensitive function is triggered by the system calls initiated by the containers; and if the sensitive function is triggered by the system call initiated by any one of the plurality of containers, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

For example, it may be determined whether a pointer to namespace is contained in the shared virtual resource R1 associated with the sensitive function f 1; if not, further determining whether the system calls initiated by the containers trigger a sensitive function f 1; if a target system call initiated by any one of the containers triggers the sensitive function f1, the shared virtual resource R1 may be determined as a potential attack object for the target container to perform a DoS attack.

It should be noted that, in the above-illustrated embodiments, only one of the first manner, the second manner, and the third manner is exemplarily described to filter the analysis result, besides, the analysis result may also be filtered by a plurality of the first manner, the second manner, and the third manner.

According to the technical scheme, all shared virtual resources provided by the kernel of the Linux system can be identified firstly by scanning the kernel code of the Linux system, and then the shared virtual resources which can be used by the target container are determined from all the identified shared virtual resources, namely, the target container carries out a potential attack object of DoS attack, so that the potential attack object of carrying out DoS attack on a plurality of containers in the Linux system is automatically analyzed, and further, technical personnel can be helped to develop a safer container.

Corresponding to the above embodiments of the method for analyzing shared virtual resources, the present specification also provides an embodiment of an apparatus for analyzing shared virtual resources.

Referring to fig. 2, fig. 2 is a hardware structure diagram of an electronic device where a shared virtual resource analysis device is located according to an exemplary embodiment. On 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, although it may include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by processor 202 reading corresponding computer programs from non-volatile storage 210 into memory 208 and then running. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

Referring to fig. 3, fig. 3 is a block diagram of a shared virtual resource analysis apparatus according to an exemplary embodiment. The shared virtual resource analysis apparatus may be applied to the electronic device shown in fig. 2 to implement the technical solution of the present specification. Wherein the shared virtual resource analysis apparatus may include:

an identifying unit 302, configured to scan kernel codes of the Linux system, identify a sensitive function included in the kernel codes and a shared virtual resource related to the sensitive function; wherein the sensitive function is a function related to the use of the shared virtual resource;

a determining unit 304, configured to determine whether the sensitive function is triggered by the system calls initiated by the containers; and if the sensitive function is triggered by the system call initiated by any one of the plurality of containers, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

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

In this embodiment, the identifying unit 302 is specifically configured to:

acquiring kernel parameters of the Linux system;

locating a first type code segment containing the kernel parameter in the kernel code; wherein, the first type code segment at least comprises relevant codes for utilizing the kernel parameter to carry out restriction check on the use of the shared virtual resource;

determining an allocation function included in the first type code segment, for allocating the shared virtual resource to the at least part of containers, as a sensitive function included in the kernel code; and determining the shared virtual resource quoted by the allocation function as the shared virtual resource related to the sensitive function.

In this embodiment, the identifying unit 302 is specifically configured to:

positioning a second type code segment in the kernel code; wherein, the second code segment at least comprises related codes which carry out mutual exclusion access to the shared virtual resource through lock operation or atomic operation;

determining an allocation function included in the second type code segment, which is used for allocating the shared virtual resource to the at least part of containers, as a sensitive function included in the kernel code; and determining the shared virtual resource quoted by the allocation function as the shared virtual resource related to the sensitive function.

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

if the system call initiated by any one of 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 that the system call triggering the sensitive function is prohibited;

and if the seccomp configuration information does not indicate that the system call triggering the sensitive function is forbidden, determining the shared virtual resource related to the sensitive function as a potential attack object of the target container for DoS attack.

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

if the sensitive function is triggered by the system call initiated by any target container in the plurality of containers, further determining whether the limit check operation of the shared virtual resource related to the sensitive function is performed on the target container on all trigger paths of the sensitive function triggered by the system call initiated by the target container;

and if the limit check operation of the shared virtual resources related to the sensitive function is not performed on all the trigger paths aiming at the target container, determining the shared virtual resources related to the sensitive function as a potential attack object of the target container for DoS attack.

In this embodiment, the determining unit 304 is further specifically configured to:

and determining a trigger path which does not perform the limit check operation of the shared virtual resources aiming at the target container as a potential attack path for performing the DoS attack on the target container.

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

if the sensitive function is triggered by a system call initiated by any one of the plurality of containers, further determining whether a pointer pointing to namespace is contained in the shared virtual resource related to the sensitive function;

and if the shared virtual resources related to the sensitive functions do not contain a pointer pointing to namespace, determining the shared virtual resources related to the sensitive functions as a potential attack object for the target container to carry out the DoS attack.

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

and if any system call initiated by any target container in the plurality of containers triggers the sensitive function, determining that the system call initiated by the target container triggers the sensitive function.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are only illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A shared virtual resource analysis method is characterized by being applied to terminal equipment loaded with a Linux system; the Linux system is loaded with a plurality of mutually isolated containers respectively corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources comprise shared virtual resources which can be shared by at least part of the plurality of containers; the method comprises the following steps:

2. The method of claim 1, wherein the sensitive function comprises an allocation function for allocating the shared virtual resource for the at least partial container.

3. The method of claim 2, wherein the identifying the sensitive function contained in the kernel code and the shared virtual resource associated with the sensitive function comprises:

acquiring kernel parameters of the Linux system;

4. The method of claim 2, wherein the identifying the sensitive function contained in the kernel code and the shared virtual resource associated with the sensitive function comprises:

5. The method of claim 1, wherein if the sensitive function is triggered by a system call initiated by any target container in the plurality of containers, determining a shared virtual resource associated with the sensitive function as a potential attack object for a DoS attack on the target container comprises:

6. The method of claim 1, wherein if the sensitive function is triggered by a system call initiated by any target container in the plurality of containers, determining a shared virtual resource associated with the sensitive function as a potential attack object for a DoS attack on the target container comprises:

7. The method of claim 6, further comprising:

8. The method of claim 1, wherein if the sensitive function is triggered by a system call initiated by any target container in the plurality of containers, determining a shared virtual resource associated with the sensitive function as a potential attack object for a DoS attack on the target container comprises:

9. The method of claim 1, wherein the determining whether the sensitive function is triggered by the system calls initiated by the number of containers comprises:

10. A shared virtual resource analysis device is characterized by being applied to terminal equipment loaded with a Linux system; the Linux system is loaded with a plurality of mutually isolated containers respectively corresponding to different tenants; the Linux system kernel provides a plurality of virtual resources; the plurality of virtual resources comprise shared virtual resources which can be shared by at least part of the plurality of containers; the device comprises:

11. An electronic device is characterized by comprising a communication interface, a processor, a memory and a bus, wherein the communication interface, the processor and the memory are connected with each other through the bus;

the memory stores machine-readable instructions, and the processor executes the method of any one of claims 1 to 9 by calling the machine-readable instructions.

12. A machine-readable storage medium having stored thereon machine-readable instructions which, when invoked and executed by a processor, carry out the method of any of claims 1 to 9.