System and method for container file integrity monitoring

Abstract

A system for monitoring file integrity in a host computing device, the host computing device having a processor and a storage device storing computer executable code. The computer executable code is configured to: provide a container, an agent outside the container, and a policy file for configuring a policy for the container; intercept a system call indicating mounting, and construct a first correspondence between a container file path and a host file path having a mount correspondence; intercept a system call of the container indicating opening a policy file, and construct a second correspondence between the container file path and a violation of the container file path; aggregate the first correspondence and the second correspondence to obtain a correspondence between the host file path and the violation; and monitor the file integrity of the container by detecting a violation of the host file path.

Description

[0001] Cross-references

[0002] Several references are cited and discussed in the description of the present disclosure, which may include patents, patent applications, and various publications. The citation and discussion of such references are provided solely to clarify the description of the present disclosure and are not intended to admit that any such reference is "prior art" to the disclosure described herein. All references cited and discussed in this specification are incorporated herein by reference in their entirety and to the same extent as if each reference were individually incorporated by reference. Technical Field

[0003] The present disclosure relates generally to the field of information security, and more particularly, to systems and methods for file integrity monitoring (FIM) of containers using an agent. Background Art

[0004] The background description provided herein is for the purpose of generally presenting the context of the present disclosure. No admission is made either explicitly or implicitly that the work of the presently named inventors (to the extent described in this background section) and certain aspects of the description that may not qualify as prior art at the time of filing are prior art to the present disclosure.

[0005] File integrity monitoring (FIM) is the act of verifying the integrity of a file system (including operating system (OS), software, configuration files, and certificate files, etc.) between the current state and the desired state in order to detect invalid modifications, deletions, replacements, etc., which can effectively detect illegal actions performed by conventional hackers or ordinary malware (Trojans, Rootkits, etc.). For example, advanced persistent threats (APTs), such as government-sponsored cyber espionage, can be detected by a well-designed FIM strategy. Specifically, for persistent attacks, APT malware needs to modify OS credentials (e.g., .ssh / id_rsa.pub. / etc / shadow, / usr / bin / passwd, etc. on Linux), or hide itself in the target machine by replacing ordinary binaries (e.g., ps, ls, ifconfig, etc.) with malicious binaries or by deleting log information / etc / localtime or bash history .bash_history. FIM policies can be configured to detect these modifications or deletions.

[0006] FIM is implemented by a software system (such as an agent) running on a host system (also called a host-based system) of a computing device (e.g., a host) that uses a FIM policy. FIM policies are typically specified by a user, such as a system administrator, who defines violation actions related to files and / or file paths via a file structure, and detected violations result in alerts for file integrity. For example, a FIM policy is represented by a rule list, which can be formatted as<file,violation> , where file refers to a full file path that can be understood by the host to find the corresponding file stored in the file path, and violation indicates an action that would violate the integrity of the file. For example,< / bin / ls,‘w,d’> This means that if the file in the path / bin / ls is modified or deleted, an alert for file integrity will be triggered. For example, EP 2228722B1, US 7,526,516 B1, KR 20100125116 A, US 7,457,951 B1, US 7,069,594 B1, US 8,819,225 B2 (

[14] -

[19] ), etc. have described how to perform FIM on a host.

[0007] Currently, containers, as a lightweight virtualization technology that provides a virtual host environment for applications, play an increasingly important role in physical machines such as hosts. Unlike traditional virtual machines ([2]-[5]), all containers on a physical machine share the same kernel for better resource utilization and efficiency. Thanks to their efficiency and advantages, containers have been widely adopted in microservices ([6]) and serverless computing architectures ([7]). It has been shown ([8]) that cloud providers including Amazon AWS, Google Cloud, Microsoft Azure, etc. use containers as their core technology. For example, instead of running directly on the host system (e.g., Linux) of a computing device, all applications can run in a large number (such as tens of thousands) of containers, which in turn run on the host system, so that applications running in one container can achieve a relatively secure operating environment isolated from other applications in other containers.

[0008] For container security, the virtualization host isolates containers from each other by using the Linux namespace abstraction ([1]) technology. In particular, the abstraction includes inter-process communication (IPC), network, mount, process identifier (PID), user, and UNIX time sharing system (UTS). Each container has its own user space and can only "see" its own file system. The container is isolated from the host.

[0009] Regarding FIM for containers, mounts provide a virtual view of the file system for each container, even though the same file path may refer to different real files stored on the host. Figure 1 As shown, container 1 mounts / mount / bin on the host to / bin in container 1, so the absolute path / bin in container 1 points to the path / mount / bin on the host. Similarly, the absolute path / usr / bin in container 2 points to the path / var / lib / docker / overlay2 / fa98b6e93 / merged / usr / bin on the host.

[0010] Since the file structure of a container-based system is different from that of a traditional host-based system, the existing FIM policies and methods used in the host-based system as described above are no longer applicable to the container-based system.

[0011] Therefore, there is an unresolved need in the art to address the aforementioned deficiencies and inadequacies. Summary of the invention

[0012] In some aspects, the present disclosure relates to a system for monitoring file integrity (FIM) of multiple containers in a host computing device. In some embodiments, the host computing device has a processor and a storage device storing computer executable code. When executed at the processor, the computer executable code is configured to:

[0013] Provides containers, agents outside containers, and policy files for configuring policies for containers;

[0014] intercepting, by the agent, a first system call to one of the containers, the first system call indicating that a container file path is mounted to a corresponding host file path;

[0015] The agent constructs a first correspondence between the container file path and the host file path;

[0016] intercepting, by the agent, a second system call to the one of the containers, the second system call instructing to open a policy file, and the policy file includes a container file path and a violation corresponding to the container file path;

[0017] A second correspondence between the container file path and the violation is constructed by the agent;

[0018] aggregating, by an agent, the first correspondence and the second correspondence to obtain a third correspondence between a host file path and a violation of a container; and

[0019] The agent monitors the file integrity of the container by detecting violations of the host file path in the third correspondence.

[0020] In some embodiments, each of the first correspondence and the second correspondence is identified by a container identifier (cid), and when the first correspondence and the second correspondence have the same cid, they are aggregated.

[0021] In some embodiments, the cid of the first system call is defined based on a process identification (pid) of the first system call, and the cid of the second system call is defined based on the pid of the second system call.

[0022] In some embodiments, at least one of the pid of the first system call and the pid of the second system call is the same as a pid of a process that initializes the container.

[0023] In some embodiments, at least one of the pid of the first system call and the pid of the second system call is a derivative of the pid of the process that initialized the container.

[0024] In some embodiments, the computer executable code is further configured to: construct a mapping between a process identifier and a container identifier, so that the pid of the process can be converted into the cid of the process based on the mapping.

[0025] In some embodiments, the computer executable code is further configured to: update a policy file using the third correspondence, and monitor file integrity of the container using the updated policy file.

[0026] In some embodiments, the computer executable code is further configured to: after intercepting the second system call and before building the second correspondence, obtain a policy for the container from a policy file.

[0027] In some aspects, the present disclosure relates to a method for monitoring file integrity of a container in a host computing device. In some embodiments, the method includes:

[0028] providing an agent in a host computing device external to the container and a policy file configuring a policy for the container;

[0029] intercepting, by the agent, a first system call to one of the containers, the first system call indicating that a container file path is mounted to a corresponding host file path;

[0030] The agent constructs a first correspondence between the container file path and the host file path;

[0031] intercepting, by the agent, a second system call to the one of the containers, the second system call instructing to open a policy file, and the policy file includes a container file path and a violation corresponding to the container file path;

[0032] A second correspondence between the container file path and the violation is constructed by the agent;

[0033] aggregating, by the agent, the first correspondence and the second correspondence to obtain a third correspondence between the host file path and the violation of the container; and

[0034] The agent monitors the file integrity of the container by detecting violations of the host file path in the third correspondence.

[0035] In some embodiments, each of the first correspondence and the second correspondence is identified by a container identifier (cid), and when the first correspondence and the second correspondence have the same cid, they are aggregated.

[0036] In some embodiments, the cid of the first system call is defined based on a process identification (pid) of the first system call, and the cid of the second system call is defined based on the pid of the second system call.

[0037] In some embodiments, at least one of the pid of the first system call and the pid of the second system call is the same as a pid of a process that initializes the container.

[0038] In some embodiments, at least one of the pid of the first system call and the pid of the second system call is a derivative of the pid of the process that initialized the container.

[0039] In some embodiments, the method further includes: constructing a mapping between the process identifier and the container identifier, so that the pid of the process can be converted into the cid of the process based on the mapping.

[0040] In some embodiments, the method further includes: updating a policy file using the third correspondence, and monitoring file integrity of the container using the updated policy file.

[0041] In some embodiments, the method further includes: after intercepting the second system call and before building the second correspondence, obtaining a policy for the container from a policy file.

[0042] In some aspects, the present disclosure relates to a non-transitory computer readable medium storing computer executable code. In some embodiments, when executed at a processor of a computing device, the computer executable code is configured to perform the method described above.

[0043] The above and other aspects of the present disclosure will become apparent from the following description of the preferred embodiments taken in conjunction with the following drawings and description thereof, although changes and modifications therein may be effected without departing from the spirit and scope of the novel concepts of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings illustrate one or more embodiments of the present disclosure, which together with the written description serve to explain the principles of the present disclosure. Wherever possible, the same reference numerals are used throughout the drawings to indicate elements of the same or similar embodiments.

[0045] Figure 1 An example of mounting a file path in a container to a file path on a host in the prior art is schematically shown.

[0046] Figure 2 A file integrity monitoring (FIM) architecture for multiple containers running on a host according to some embodiments of the present disclosure is schematically illustrated, wherein each container is provided with an agent and a FIM policy dedicated to the container.

[0047] Figure 3 The diagram schematically illustrates a FIM architecture for multiple containers running on a host according to a certain embodiment of the present disclosure, wherein an agent is set outside the container to perform centralized FIM of the container.

[0048] Figure 4 The structure of a host system with a centralized FIM agent according to some embodiments of the present disclosure is schematically shown.

[0049] Figure 5 Schematically shown in Figure 4 The processing flow of the centralized FIM agent running on the host system.

[0050] Fig. 6A The process of executing interception according to some embodiments of the present disclosure is schematically illustrated.

[0051] Figure 6B The process of performing mapping according to some embodiments of the present disclosure is schematically illustrated.

[0052] Figure 6C The process of performing parsing according to some embodiments of the present disclosure is schematically illustrated.

[0053] Fig.6D The process of performing aggregation according to some embodiments of the present disclosure is schematically illustrated.

[0054] Figure 7 The structure of a computing device according to a certain embodiment of the present disclosure is schematically shown.

[0055] Figure 8 The FIM method according to a certain embodiment of the present disclosure is schematically illustrated.

[0056] Fig. 9 The FIM workflow according to a certain embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0057] The present disclosure is described in more detail in the following examples, which are intended for illustrative purposes only, as many modifications and variations therein will be apparent to those skilled in the art. Various embodiments of the present disclosure are now described in detail. With reference to the accompanying drawings, similar reference numerals indicate similar components throughout the views. As described herein and used throughout the appended claims, the meanings of "one", "an" and "the" include plural forms, unless the context clearly indicates otherwise. Moreover, as described herein and used throughout the appended claims, the meaning of "in..." includes "in..." and "on...", unless the context clearly indicates otherwise. Moreover, for the convenience of the reader, titles or subtitles may be used in the specification, but they should have no effect on the scope of the present disclosure. In addition, some terms used in this specification are defined in more detail below.

[0058] The terms used in this specification generally have conventional meanings in the context of the present disclosure and in the specific context in which each term is used. Certain terms used to describe the present disclosure are discussed below or in the specification to provide additional guidance to practitioners described in the present disclosure. It will be understood that the same thing can be described in more than one way. Therefore, any one or more of the terms discussed herein may use alternative language and synonyms, and there is no special meaning whether or not a term is elaborated or discussed herein. Synonyms for certain terms are provided. The recording of one or more synonyms does not exclude the use of other synonyms. The examples used anywhere in this specification, including examples of any term discussed herein, are only for illustration and are in no way intended to limit the scope and meaning of the present disclosure or any example term. Similarly, the present disclosure is not limited to the various embodiments given in this specification.

[0059] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the present disclosure belongs. It will be further understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure, and will not be interpreted in an idealized or overly formal sense unless explicitly so defined herein.

[0060] Unless otherwise defined, “first,” “second,” “third,” etc. used before the same object are intended to distinguish these different objects rather than to limit any order thereof.

[0061] As used herein, "roughly," "approximately," "substantially," or "approximately" shall generally mean within 20%, preferably within 10%, and more preferably within 5% of a given value or range. The values ​​given herein are approximate, meaning that if not explicitly stated, the term "roughly," "approximately," "substantially," or "approximately" can be inferred.

[0062] As used herein, "plurality" means two or more.

[0063] As used herein, the terms "comprising," "including," "carrying," "having," "containing," "involving," and the like should be construed as open ended, ie, meaning including but not limited to.

[0064] As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical OR. It should be appreciated that one or more steps within a method can be performed in a different order (or concurrently) without altering the principles of the present disclosure. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0065] As used herein, the term "module" may refer to, be part of, or include an application specific integrated circuit (ASIC); an electronic circuit; a combinational logic circuit; a field programmable gate array (FPGA); a processor (shared, dedicated, or group) that executes code; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip. The term module may include a memory (shared, dedicated, or group) that stores code executed by a processor.

[0066] As used herein, the term "code" may include software, firmware, and / or microcode, and may refer to a program, routine, function, class, and / or object. As used herein, the term shared refers to that some or all of the code from multiple modules can be executed using a single (shared) processor. In addition, some or all of the code from multiple modules can be stored by a single (shared) memory. As used herein, the term group refers to that some or all of the code from a single module can be executed using a processor group. In addition, some or all of the code from a single module can be stored using a memory group.

[0067] As used herein, the term "interface" generally refers to a communication tool or device at an interaction point between components for performing data communication between components. Typically, interfaces can be applied to both hardware and software levels, and can be unidirectional or bidirectional interfaces. Examples of physical hardware interfaces can include electrical connectors, buses, ports, cables, terminals, and other I / O devices or components. The components that communicate with the interface can be, for example, multiple components or peripherals of a computer system.

[0068] The present disclosure relates to computer systems. As shown in the accompanying drawings, computer components may include physical hardware components, which are shown in solid boxes, and virtual software components, which are shown in dashed boxes. It will be understood by those of ordinary skill in the art that, unless otherwise specified, these computer components may be implemented in the form of, but not limited to, software, firmware, or hardware components, or a combination thereof.

[0069] The devices, systems, and methods described herein may be implemented by one or more computer programs executed by one or more processors. The computer programs include processor-executable instructions stored on a non-transitory tangible computer-readable medium. The computer programs may also include stored data. Non-limiting examples of non-transitory tangible computer-readable media are non-volatile memory, magnetic storage, and optical storage.

[0070] The present disclosure will now be described more fully with reference to the accompanying drawings, in which embodiments of the present disclosure are shown. However, the present disclosure may be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; on the contrary, these embodiments are provided so that the present disclosure will be thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art.

[0071] In some aspects, the present disclosure provides Figure 2 The strawman architecture shown is used to perform FIM for containers, where each container has a corresponding dedicated agent inside for executing the corresponding FIM policy. Similar to the file structure for FIM policies based on host systems, FIM policies specific to containers can be specified by users via a file structure to define violation actions related to files and / or file paths to files. Container-specific FIM policies can be represented by a list of rules, which can also be formatted as<file,violation> , where file indicates the file path in the container and violation indicates the action that will violate the integrity of the file.

[0072] However, the agent in the container for performing FIM (also called the FIM agent) only knows the file path in the container, but does not know the corresponding host file path outside the container due to the isolation of the container, and cannot recognize the corresponding host file path dynamically determined during the mounting of the container.

[0073] The above straw man-based technology has at least the following defects:

[0074] (1) Once the container is damaged, it is unsafe;

[0075] (2) requires additional computing resources, since each container requires a replica of the agent; and

[0076] (3) It requires additional management work and cannot scale as the number of containers increases.

[0077] As an improvement to implementing FIM for containers, in some aspects, the present invention provides a new centralized FIM architecture for managing multiple containers running on a host. Figure 3 As shown, multiple containers 1-N and an agent are all running on a host system of a computing device, and the agent is deployed outside the multiple containers to monitor the integrity of files in each of the multiple containers. That is, the present disclosure provides a host-based FIM solution for a container-based system.

[0078] In such Figure 2 In the container-based system shown, the user specifies the FIM policy for the container via a file structure, thereby defining the violation actions of the files and / or file paths in the container, and the FIM policy specific to the container can be represented by a rule list, which can also be formatted as<file,violation> , where violation indicates an action that would violate the integrity of a file, and file indicates a file path in a container (also referred to as a container file path), which can be understood by an agent in the container to find the corresponding file, as described above. However, according to some aspects of the present disclosure, an agent deployed on a host system cannot recognize the container file path in a FIM policy specified by a user for a container-based system, but can only understand the host file path, similar to the agent deployed on a host-based system described above. That is, there is a semantic generation gap between the container and the host, especially between the container file path in a user-specified FIM policy and the host file path that can be understood by an agent deployed on a host system.

[0079] In order to achieve Figure 3 With this centralized FIM architecture shown, the present disclosure provides a method for bridging the semantic gap between containers and hosts. Figure 4 Schematically illustrates a host system running on a computing device that uses an agent to manage FIM for multiple containers. Figure 5 Shown in Figure 4 The workflow in the agent running on the host system. Figure 4As shown, the host system 400 according to some embodiments of the present disclosure includes multiple containers 421, 422, ... and an agent 410 deployed outside the multiple containers. The agent 410 includes an interceptor 411, a mapper 412, a parser 413, a database (DB) 414, an aggregator 415, and a monitor 416. Figure 5 As shown in the overall workflow of , the input for the FIM system is the system call (or syscall) of the host operating system. The interceptor will capture two types of syscalls: syscalls for container file system mounting and syscalls for opening policy files. These syscalls are then sent to the mapper and parser to generate: a mapping of host file paths and container file paths, and a mapping of container file paths and violations. The former is represented in<cid,HostFilePath,ContainerFilePaht> , while the latter indicates that<cid,ContainerFilePath,Violation> Specifically, (1) cid is a unique ID for each container; (2) HostFilePath is the full path to each file in the host (e.g., / var / 123456 / usr / bin / ls); (3) ContainerFilePath is the full path to each file in the container (e.g., / bin / ls); (4) Violation indicates an action that violates the integrity of the file. Finally, the aggregator combines the two maps using the keys cid and ContainerFilePath to generate the output<cid,HostFilePath,Violation> , which can be used directly by the host FIM.

[0080] Here, the container 421 shown in solid lines is intended to exemplarily refer to such a container that has been created and is running under the FIM of the agent 410; the container 422 shown in dotted lines is intended to exemplarily refer to such a container that is being created, during which the agent 410 is used to bridge the semantic gap between the container and the host so as to execute the FIM for the container after its creation, similar to the container 421. Those skilled in the art will understand that the current processing of the agent 410 for the container 422 has been performed in the same manner for the container 421.

[0081] Thereafter, the operation of the agent 410 on the container 422 will be combined with Figure 4 and Figure 5 It should be understood that container 422 is described as an example of a container being created; although the subsequent processing is described exemplarily for only one container being created (e.g., container 422), those skilled in the art will understand that such processing can be applied to each of multiple containers being created.

[0082] The interceptor 411 is configured to intercept the system calls of the operating system of the host system 400 and bridge the semantic generation gap between the container and the host. When the user or administrator of the host system 400 uses an instruction to start creating a container 422, a series of system calls can be detected by the interceptor 411, including not only system calls related to the process of creating the container 422, but also system calls that are not related to the process of creating the container 422, such as system calls of some regular processes. When the interceptor 411 detects a system call to create a process or terminate a process, the interceptor 411 determines that a regular process or container has been created.

[0083] If the system call is made by the process that creates container 422, for example, if the process ID (also expressed as "pid", which is a unique ID for a process) of the process that creates container 422 is a derivative of the root process for the container service, interceptor 411 determines that container 422 has been created.

[0084] Next, if interceptor 411 detects a system call made by the process that creates container 422 to mount the file system of container 422 or a system call made by the same process to open the FIM policy file of container 422, interceptor 411 obtains the container ID (also expressed as "cid", which is the unique ID of the container) of container 422 based on the process that creates container 422.

[0085] In some embodiments, the container ID of container 422 may be generated based on the process ID of the process that creates container 422. Alternatively, the container ID of container 422 may be obtained based on the process ID of the process that creates container 422 and a storage mapping relationship between the process ID and the container ID.

[0086] During the creation of container 422, the file system of the container needs to be mounted to the corresponding path in the host system, and a system call for mounting the file system is generated. When interceptor 411 detects the system call for file system mounting, interceptor 411 is configured to obtain mounting information, including container ID and corresponding file paths in the container and the host, and send the mounting information to mapper 412.

[0087] Meanwhile, during the creation of container 422, it is necessary to read the configuration of the container or the FIM policy corresponding to the container, and generate a system call for opening the FIM policy corresponding to the container. When interceptor 411 detects a system call to open a corresponding policy file, interceptor 411 is configured to obtain information related to the policy file and send the information related to the policy file to parser 413. Information related to the policy file may include the id of the container, one or more container file paths, and violations defined for the container file paths.

[0088] like Figure 3 As shown, the FIM policy file for a container is located inside the host and outside the container. For many containers, there can be one or several FIM policy files. If there is only one policy file, this one policy file includes policies for all containers. If there are several policy files, each of the several policy files can correspond to a class of containers with similar policies. A container-specific FIM policy can be identified by a rule list, which can be formatted as<file,violation> , where file refers to the file path in the container and violation indicates the action that would violate the file integrity of the file.

[0089] In some embodiments, interceptor 411 uses Fig. 6A The interception operation is performed by following the process shown in the figure. Fig. 6A As shown, the interceptor 411 hooks the process creation and termination system calls, whose callers are derivatives of the root process for the container service (lines 02 and 05), uses the process ID (pid) to identify the process that created the container, and stores the process ID in con_process (line 03), thereby maintaining a set of container-related processes responsible for mounting the container file system (lines 01-06). If the system call is made by a container-related process (line 08), and the system call opens a policy file (expressed as "FILE_OPEN") (line 09) or mounts its file system (expressed as "FILESYSTEM_MOUNT") (line 10), the interceptor 411 will obtain the container ID (cid) for each container being mounted (lines 11-15). Specifically, the container ID can be obtained based on the process ID of the process that creates the container 422 and the storage mapping relationship between the process ID and the container ID (line 12), or it can be generated based on the process ID (pid) of the process that creates the container (line 14). If the system call (syscall) is FILE_OPEN, the container ID and policy file will then be dispatched to the parser 413 (lines 16, 17), and if the system call (syscall) is FILESYSTEM_MOUNT, the container ID and mount information will then be dispatched to the mapper 412 (lines 18, 19).

[0090] In some embodiments, instead of the above process, if the container management system "docker" is available for the agent 410, the interceptor 411 can be configured to use the process "dockerd" under "docker" to detect the container file system mount.

[0091] After receiving the obtained container ID of container 422 and the mount information of its file system from interceptor 411, mapper 412 generates a file path mapping relationship between container 422 and host system 410 based on the container ID and the mount information, and saves the generated file path mapping relationship in DB 414.

[0092] In some embodiments, the mapper 412 may first determine a basic mount point based on the container ID and the mount information; and then generate a file path mapping relationship between the container 422 and the host system 410 based on the determined basic mount point.

[0093] In some embodiments, the file path mapping relationship generated by the mapper 412 includes the obtained container ID, the first container file path set of files in the file system of the container 422, and the host file path set of files in the first container file path set, wherein the host file path is dynamically determined during the mounting of the container 422. For example, the file path mapping relationship generated by the mapper 412 can be expressed as<cid,HostFilePath,ContainerFilePath> of the form, where cid (e.g., Figure 5 1234) is the unique ID of container 422, and ContainerFilePath is the full path of each file in container 422 (e.g., Figure 5 ), and HostFilePath is the full path of the corresponding file in the host system 400 (e.g., Figure 5 / var / 123456 / usr / bin / ls) shown in , which is dynamically determined during the mounting of container 422.

[0094] In some embodiments, the mapper 412 uses Figure 6B The mapping operation is performed by the process shown in FIG. Figure 6B As shown, the mapper 412 generates a file path mapping relationship between the container and the host system 400 for each mount operation, and stores the file path mapping relationship in the DB 414. Specifically, the mapper 412 first finds the basic mount point and saves it to the DB 414 (line 06); then generates a file path mapping relationship between the container and the host system 400 based on the basic mount point (lines 07-12) and saves it to the DB 414 (line 12). In some embodiments, the above information is saved in the DB 414 as an entry of the database.

[0095] After receiving the system call to open the policy file from the interceptor 414, the parser 413 reads the corresponding policy rules for the container from the policy file (FIM policy file) in the host, and stores the policy rules in the DB 414. In some embodiments, before storing in the DB 414, the parser 413 may assemble these policy rules into a policy file, wherein the generated policy file is called a container-based FIM policy file, because it is specific to the one container, has a container file path, and can be understood only inside the container.

[0096] The container's FIM policy file is a file pre-stored on the host system 400, indicating the container's FIM policy defined by the user via a file structure to define which actions on files in the container are violation actions. The container-specific FIM policy can be represented as a rule list, which can be formatted as<file,violation> , where file refers to a file path in a container, and violation indicates an action that would damage the file integrity of the file. In some embodiments, the FIM policy file is defined by a user for at least one of the multiple containers, that is, the same FIM policy file can be used for different containers.

[0097] Assuming that the FIM policy file in the host system 400 includes a second container file path set of files in the container's file system and violations for files in the second container file path set, the parser 413 obtains the second container file path set, the violations of the container file paths, and the associated container ID (cid) from the open policy file system call and the FIM policy file, and stores the information to the DB 414, which is accessible by the aggregator 415. Each violation may indicate an action that would destroy the file integrity of each file in the second container file path set.

[0098] It can be understood that the second container file path set is a subset of the first container file path set included in the file path mapping relationship generated by the mapper 412 discussed above, because not all files in the container's file system have corresponding FIM rules. In some embodiments, the second set is not a subset of the first container file path set, but the first container file path set and the second container file path set have overlapping file paths.

[0099] The information obtained by the parser 413 can be expressed as<cid,ContainerFilePath,Violation> of the form, where cid (e.g., Figure 5 1234) is the unique ID of container 422, and ContainerFilePath is the full path of each file in container 422 (e.g., Figure 5), and Violation indicates an action that would destroy the file integrity of the corresponding file (for example, Figure 5 "write" shown in FIG.

[0100] In some embodiments, the parser 413 uses Figure 6C The process shown is used to perform the parsing operation. Figure 6C As shown, the parser 413 can define the policy rules as<containerId=cid,type=RULE,ContainerPath,Violation> (Line 02), where ContainerPath can be the full path to a file or directory within the container, and Violation indicates an action that would destroy the file integrity of the file. Parser 413 is configured to save the result to DB 414 (Lines 03-07). In some embodiments, the result is saved to DB 414 as an entry in a database.

[0101] After receiving the container ID, host file path, and corresponding container file path from DB 414 (stored by mapper 412), and the container ID, container file path, and violation from DB 414 (stored by resolver 413), aggregator 415 is configured to generate a record and save the record to DB 414. In some embodiments, the record is saved to DB 414 as an entry of a database. The saved record can be accessed by monitor 416. Figure 5 As shown, the record includes the container ID, the host file path, and the violation action defined for the host file path. In some embodiments, the record is saved in the form of a configuration file. In some embodiments, the aggregator 415 generates the record in the form of a FIM policy file, which can be called a host-based FIM policy file because the file path of the container is in the form of a host file path and can be read from outside the container.

[0102] Specifically, the aggregator 415 aggregates the container ID, the first container file path set of the files in the file system of the container, and the host file path set of the files in the first container file path set included in the file path mapping relationship, as well as the container ID, the second container file path set of the files in the file system of the container, and the violations for the files in the second container file path set, thereby generating a record including the container ID, the host file path, and the violations for the host file path. The aggregation is based on the corresponding container file paths from the mapper 412 and the parser 413.

[0103] For example, aggregator 415 can use the keys cid and ContainerFilePath to map the<cid,HostFilePath,ContainerFilePath> The first path mapping relationship of the form is generated by the parser 413<cid,ContainerFilePath,Violation> The FIM policy rules of the form are combined to generate a FIM policy rule that can be used directly by the agent 410 on the host system 400.<cid,HostFilePath,Violation> In the FIM policy file located inside the host and outside the container, the container file path cannot be understood by the agent 410. Now, the record includes the host file path corresponding to the container file path, which can be understood by the agent 410. In some embodiments, the aggregator 415 can assemble these policy rules into a policy file, wherein the generated policy file is called a host-based FIM policy file because it can be understood by the agent in the host. Alternatively, the record can be input into the original FIM policy file to obtain an updated FIM policy file, so that the policy in the updated FIM policy file involves the container file path instead of the host file path. However, due to the dynamic nature of container mounting, it may be better not to use policy records to update the original FIM policy file, so that the original FIM policy is robust. Therefore, the policy record is preferably saved in a new host-based FIM policy file, or arranged in other suitable formats, as long as the monitor 416 can use the policy record to monitor the file integrity of the container. In some embodiments, the above record is saved to DB 414 as an entry in the database.

[0104] In some embodiments, aggregator 415 uses Fig.6D The aggregation operation is performed by following the process shown in the figure. Fig.6D As shown, aggregator 415 can combine the results of mapper 412 and parser 413 using the keys cid and ContainerFilePath to generate a<Container ID,type,HostFilePath,ContainerFilePath,Violation> Records in the form of.

[0105] As described above, aggregator 415 is further configured to send a record (or multiple records) to monitor 416. Based on the record, monitor 416 is then configured to monitor the host file path (corresponding to the container file path) in real time and implement the FIM function of agent 410.

[0106] Specifically, monitor 416 performs FIM on host system 400 for the file system of container 422 based on the host file paths of the files in the first container file path set and the violations for the files in the second container file path set. Figure 5 In the example of , monitor 416 can perform FIM following the FIM policy record <1234, / var / 123456 / usr / bin / ls, 'write'>, which means that if a "write" action is detected on a file of a container with a container ID of "1234" and its real file path on the host is / var / 123456 / usr / bin / ls, an alert should be issued.

[0107] In some embodiments, instead of receiving records from aggregator 415, monitor 416 can obtain new records from DB 414 using type=FIM and communicate with host system 400 to monitor file integrity by, for example, registering a FIM callback from the OS kernel (e.g., the inotify system call in Linux) or by periodically checking whether the hash value of a specified file has changed.

[0108] Thus, using the above-described process during container creation, the agent 410 running directly on the host system 400 and arranged outside the container can perform FIM for the created container based on the records received from the aggregator 415 or obtained from the DB 414, thereby linking the operation of certain host file paths or files under the host file paths to a specific container. In some embodiments, the agent 410 can also use the records to update the host-based FIM policy file. In some embodiments, the agent 410 can use the records to create a new FIM policy file.

[0109] Figure 7 The structure of a computing device according to some embodiments of the present disclosure is schematically shown. In some embodiments, the computing device 700 can be used to implement a centralized FIM for multiple containers. In some embodiments, the computing device 700 can be a server computer, a cluster, a cloud computer, a general-purpose computer, or a dedicated computer, which can execute a centralized FIM on multiple containers.

[0110] like Figure 7As shown, computing device 700 may include, but is not limited to, processor 702, memory 704, and storage device 706. In some embodiments, computing device 700 may include other hardware components and software components (not shown) to perform its corresponding tasks. Examples of these hardware and software components may include, but are not limited to, other required memories, interfaces, buses, input / output (I / O) modules or devices, network interfaces, and peripheral devices. In some embodiments, computing device 700 is a cloud computer, and processor 702, memory 704, and storage device 706 are shared resources provided on demand through the Internet.

[0111] The processor 702 may be a central processing unit (CPU) configured to control the operation of the computing device 700. The processor 702 may execute an operating system (OS) or other applications of the computing device 700. In some embodiments, the computing device 700 may have more than one CPU as a processor, such as two CPUs, four CPUs, eight CPUs, or any suitable number of CPUs.

[0112] The memory 704 may be a volatile memory, such as a random access memory (RAM), for storing data and information during operation of the computing device 700. In some embodiments, the memory 704 may be a volatile memory array. In some embodiments, the computing device 700 may run on more than one memory 704.

[0113] Storage device 706 is a non-volatile data storage medium for storing an OS (not shown) and other applications of computing device 700. Examples of storage device 706 may include non-volatile memory such as a flash memory, a memory card, a USB drive, a hard drive, a floppy disk, an optical drive, or any other type of data storage device. In some embodiments, computing device 700 may have multiple storage devices 706, which may be the same storage device or different types of storage devices, and applications of computing device 700 may be stored in one or more storage devices 706 of computing device 700. Figure 7 As shown, storage device 706 includes host system 708. Host system 708 provides a platform for executing centralized FIM on multiple containers.

[0114] like Figure 7As shown, among other things, the host system 708 includes a container module 710, an agent 712, and a FIM policy 726. The container module 710 is configured to initialize one or more containers in the host system 708. During the initialization of one of the containers, the container module 710 can mount the file path of the container to the file path in the host file system, and read the FIM policy 726 to define restrictions on the container. The agent 712 is configured to monitor the file integrity of the container based on the FIM policy 726. The FIM policy 726 is a file containing the FIM policy for the container. The FIM policy may include a container identifier, a container file path, and a violation of the container file path. In some embodiments, each container has a corresponding set of policy rules. In some embodiments, the containers are divided into multiple categories, each type of container has a set of policy rules. In the above embodiment, only one FIM policy 726 is used for the agent 712. In other embodiments, each container or each type of container has a corresponding FIM policy 726.

[0115] like Figure 7 As shown, the agent 712 includes an interceptor 714, a mapper 716, a parser 718, a database 720, an aggregator 722, and a monitor 724. In some embodiments, the agent 712 may include other applications or modules required for the operation of the above modules 714-724 (e.g., a database), which are omitted as common components so as not to obscure the principles of the present disclosure. Figure 4 A detailed description of the structure of the host system 400 of this host system 708 can be found in the previously discussed Figure 4 and Figure 5 It should be noted that the modules are implemented by computer executable code or instructions, or data tables or databases, which together form an application. In some embodiments, each module may further include submodules. Alternatively, some modules may be combined into a stack. In other embodiments, some modules may be implemented as circuits rather than executable code.

[0116] The interceptor 714 is configured to monitor the system calls of the host system 708. The system calls include conventional system calls of the host system 708 that are not related to the operation of the container and system calls related to the operation of the container. When the system call is to create or terminate a process (PROCESS_CREATION or PROCESS TERMINATION), the system call is related to the creation or termination of the process. In this case, the interceptor 714 is configured to check the process ID (pid) of the process. When pid is a derivative of the container daemon, it indicates that the process is the creation of the container. In some embodiments, the interceptor 714 is configured to mark or record the pid, and store this pid in con_process. Afterwards, when monitoring a process with the pid, and the system call is FILE_OPEN (open file) and the opened file is FIM policy 726, or the system call is MOUNT (mount), the interceptor 714 is configured to dispatch the system call to the mapper 716 and the parser 718 respectively. In some embodiments, the interceptor 714 is further configured to generate a container id (cid) corresponding to a pid associated with the container, build a pid to cid relationship, and store the pid-cid relationship in pid_cid, so that the interceptor 714 can easily link the process to the container.

[0117] The mapper 716 is configured to generate a file path mapping between the source (container) and the target (host) for each mount operation upon receiving a system call (MOUNT) from the interceptor 714, and store the output in the database 720. Return to Reference Figure 5 , each mapping includes a container identifier, a mounted host file path, and a container file path corresponding to the host file path.

[0118] Parser 718 is configured to define policy rules for container file paths upon receiving a system call (opening a policy file) from interceptor 714 and store the policy rules in database 720. Figure 5 , the policy rule includes a container identifier, a container file path, and a violation of the container file path. In some embodiments, the parser 718 can directly obtain the container identifier, the container file path, and the violation from the open policy file system call. In other embodiments, the parser 718 is configured to read the FIM policy 726 and obtain this information from the FIM policy 726 based on the identifier included in the system call.

[0119] Aggregator 722 is configured to obtain file path mappings stored in database 720 by mapper 716 and policy rules stored in database 720 by parser 718, combine these results to generate a policy record, and store the policy record in database 720, which can be accessed by monitor 724. In some embodiments, aggregator 722 is configured to combine results based on the container identifier of the results, where results with the same container identifier are combined if possible. In some embodiments, the policy record includes the container identifier, the host file path, and the violation. In some embodiments, the policy record may also include the container file path. In this embodiment, aggregator 722 is configured to obtain information from database 720. In other embodiments, database 720 is not required, and aggregator 722 receives this information directly from mapper 716 and parser 718.

[0120] Monitor 724 monitors the container based on the policy record in response to receiving the policy record from aggregator 722, and provides a warning when the operation of the host file path violates the rules. In some embodiments, monitor 724 is configured to directly use the policy record to monitor host system 708. In some embodiments, monitor 724 is configured to update the FIM policy using the policy record, and monitor host system 708 based on the updated FIM policy 726.

[0121] Figure 8 A FIM method 800 according to one embodiment of the present disclosure is described. In some embodiments, the method 800 comprises Figure 7 The computing device 700 is used to execute and apply Figure 7 The host system 708 or Figure 4 The host system 400 shown in FIG. 4 is used to perform centralized FIM for multiple containers created on the host system. Thereafter, Figure 8 The method will combine Figure 7 Although the computing device 700 is described, it should be understood that Figure 7 The processing on the host system 708 of the computing device 700 may also be applied to Figure 4 It should be noted that unless otherwise stated in the present disclosure, the steps of the method can be arranged in a different order, and are therefore not limited to Figure 8 For the sake of simplicity, some detailed descriptions discussed previously will be omitted.

[0122] like Figure 8 As shown, at process 802 , the interceptor 714 monitors the system calls of the host system 708 , intercepts the mount system calls of the container, and sends the mount system calls of the container to the mapper 716 .

[0123] At process 804 , upon receiving the mount system call, the mapper 716 generates a file path mapping between the container file path and the host file path, and stores the mapping to the database 720 .

[0124] At process 806 , the interceptor 714 monitors system calls of the host system 708 , intercepts an open policy file (FIM policy 726 ) system call, and sends an open policy file system call to the parser 718 .

[0125] At process 808 , upon receiving the open policy system call, the parser 718 defines policy rules for the container file path and stores the policy rules in the database 720 .

[0126] At process 810, the aggregator obtains the mappings stored by the mapper 716 and the policy rules stored by the parser 718 in the database 720, combines the results to generate a policy record, and stores the policy record in the database 720, where it can be accessed by the monitor 724. In some embodiments, the aggregator can also send the policy record directly to the monitor 724. By combining the two types of results, violations for the container are directly linked to the host file path instead of the container file path.

[0127] At process 812, monitor 724 monitors the operation of the host file path for illegal actions based on the policy record. Agent 712 operates outside the container. Due to the isolation effect of the container, monitor 724 of agent 712 cannot see the container file path in the container. Through the above method, based on the policy record, monitor 724 can monitor the host file path corresponding to the container file path, thereby realizing the monitoring of file integrity in the container.

[0128] Fig. 9 The FIM workflow according to one embodiment of the present disclosure is schematically shown. Figure 8 The described policy rules and policy records are not independent rules and records, but are completed by updating FIM policy 726. In some embodiments, agent 712 can also create a dynamic FIM policy file to store these policy records related to operating containers. When a container is created, the policy record for the container is added to the dynamic FIM policy file, and when the container is terminated, the policy record can be removed from the dynamic FIM policy file.

[0129] like Fig. 9 As shown, at process 902 , the interceptor 714 monitors system calls of the host system 708 .

[0130] Since the interceptor 714 can detect a series of system calls when creating a container, including not only system calls related to the process that creates the container, but also system calls that are not related to the process that creates the container, the interceptor 714 determines at process 904 whether a system call made by the process that creates the container to mount the container's file system (also called the first system call) or a system call made by the same process to open the container's FIM policy file (also called the second system call) is detected.

[0131] If the interceptor 714 determines that the first system call is detected (the left branch of process 904, labeled as "first system call"), method 900 proceeds to process 906, where the interceptor 714 obtains the container ID of the container based on the process that creates the container and obtains the mount information of the container's file system from the first system call, and sends it to the mapper 716; the mapper 716 generates a file path mapping relationship between the container and the host system 708 based on the container ID and the mount information.

[0132] If the interceptor 714 determines that a second system call is detected (the right branch of process 904, labeled "second system call"), method 900 proceeds to process 908, where the interceptor 714 obtains the container ID of the container based on the process that creates the container and sends it to the parser 716, and notifies the parser 718 that the FIM policy file of the container needs to be obtained from the host system 708; the parser 718 generates a container-based FIM policy file based on the container ID of the container and the FIM policy file obtained from the host system 708.

[0133] At process 906 or 908, in some embodiments, the interceptor 714 may generate a container ID for the container based on the process ID of the process that creates the container; alternatively, the interceptor 714 may obtain the container ID for the container based on the process ID of the process that creates the container and a storage mapping relationship between the process ID and the container ID.

[0134] In some embodiments, the file path mapping relationship includes a container ID, a first container file path set of files in the container's file system, and a host file path set of files in the first container file path set; the container-based FIM policy file includes a container ID, a second container file path set of files in the container's file system, and violations for files in the second container file path set, wherein the second set is a subset of the first set.

[0135] At process 910 , the aggregator 722 generates a host-based FIM policy file based on the file path mapping relationship generated by the mapper 716 and the container-based FIM policy rules generated by the parser 718 .

[0136] In some embodiments, at process 810, the aggregator 720 aggregates the container ID included in the file path mapping relationship, the first container file path set of files in the container's file system, and the host file path set of files in the first container file path set, and the container ID included in the container-based FIM policy file, the second container file path set of files in the container's file system, and the violations for the files in the second container file path set to generate a generated host-based FIM policy file, which includes the container ID, the host file path of the files in the first container file path set, and the violations for the files in the second container file path set.

[0137] At process 812, monitor 722 performs FIM for the container's file system based on the generated host-based FIM policy file. In some embodiments, monitor 722 performs FIM on host system 708 for the container's file system based on the host file paths of the files in the first set of container file paths and violations for the files in the second set of container file paths.

[0138] In some embodiments, method 800 is applied to host system 708 to perform centralized FIM for multiple containers created on host system 708, which may have the following benefits:

[0139] Among other things, the systems and methods for centralized FIM for multiple containers according to some embodiments of the present disclosure have the following advantages:

[0140] (1) Less resource consumption - it achieves better resource utilization because only one agent is deployed on the host system (no need to copy it for each container);

[0141] (2) Ease of agent management and greater scalability—when agents or policies need to be updated, only the centralized agent needs to be updated to support a large number of containers; and

[0142] (3) More secure FIM, because if the container is compromised by an attacker, the centralized agent in the host is still secure due to its isolation from the container namespace.

[0143] The foregoing description of exemplary embodiments of the present disclosure is provided for purposes of illustration and description only and is not intended to be exhaustive or to limit the disclosure to the precise form disclosed.Many modifications and variations are possible in light of the above teachings.

[0144] The embodiments are selected and described in order to explain the principles of the present disclosure and their practical applications, so that other persons skilled in the art can utilize the present disclosure and the various embodiments and various modifications suitable for the specific use contemplated. Alternative embodiments will become apparent to those skilled in the art to which the present disclosure belongs without departing from its spirit and scope. Therefore, the scope of the present disclosure is defined by the appended claims rather than the foregoing description and exemplary embodiments described herein.

[0145] References

[0146] 【1】http: / / man7.org / linux / man-pages / man7 / namespaces.7.html;

[0147] 【2】https: / / www.linux-kvm.org / page / Main_Page;

[0148] 【3】https: / / www.xenproject.org / ;

[0149] 【4】https: / / www.virtualbox.org / ;

[0150] 【5】https: / / www.vmware.com / products / esxi-and-esx.html;

[0151] 【6】https: / / microservices.io / patterns / microservices.html;

[0152] 【7】https: / / aws.amazon.com / serverless / ; 【8】

[0154] https: / / www.datamation.com / cloud-computing / aws-vs.-azure-vs.-google-cloud-comparison.html:

[0155] 【9】https: / / coreos.com / clair / docs / latest / ;

[0156]

[10] https: / / docs.docker.com / engine / security / seccomp / ;

[11]

[0158] https: / / cloudplatform.googleblog.com / 2018 / 05 / Open-sourcing-gVisor-a-sandboxed-container-runtime.html;

[0159]

[12] https: / / docs.docker.com / engine / security / apparmor / ;

[0160]

[13] Secure Serverless Computing Using Dynamic Information Flow Control, Kalev Alpernas et al., https: / / arxiv.org / abs / 1802.08984.

[0161]

[14] EP 2228722 B1, Kaspersky Lab ZAO, 2011;

[0162]

[15] US 7,526,516 B1, Kaspersky Lab ZAO, 2009;

[0163]

[16] KR 20100125116A, 2010;

[0164]

[17] US 7,457,951 B1, Hewlett-Packard Development Co LP, 2008;

[0165]

[18] US 7,069,594 B1, McAfee LLC, 2006;

[0166]

[19] US 8,819,225 B2, George Mason Research Foundation Inc., 2014.

Claims

1. A system for monitoring file integrity of a plurality of containers in a host computing device, the host computing device comprising a processor and a storage device storing computer executable code, wherein when executed at the processor, the computer executable code is configured to: Providing the container, an agent outside the container, and a policy file for configuring a policy for the container; intercepting, by the agent, a first system call to one of the containers, the first system call indicating that a container file path is mounted to a corresponding host file path; The agent constructs a first correspondence between the container file path and the host file path; intercepting, by the agent, a second system call to the one of the containers, the second system call instructing to open the policy file, and the policy file including the container file path and a violation corresponding to the container file path; The agent constructs a second correspondence between the container file path and the violation; aggregating, by the agent, the first correspondence and the second correspondence to obtain a third correspondence between the host file path and the violation of the container; as well as The agent monitors the file integrity of the container by detecting violations of the host file path in the third correspondence. 2 . The system according to claim 1 , wherein each of the first correspondence and the second correspondence is identified by using an identifier cid of the container, and when the first correspondence and the second correspondence have the same cid, they are aggregated.

3. The system according to claim 2, wherein the cid of the first system call is defined based on the process identifier pid of the first system call, and the cid of the second system call is defined based on the pid of the second system call. 4 . The system of claim 3 , wherein at least one of the pid of the first system call and the pid of the second system call is the same as the pid of a process that initializes the container. 5 . The system of claim 3 , wherein at least one of the pid of the first system call and the pid of the second system call is a derivative of the pid of a process that initializes the container.

6. The system according to claim 3, wherein the computer executable code is further configured to: construct a mapping between a process identifier and an identifier of the container, so that a pid of a process can be converted into a cid of the process based on the mapping. 7 . The system according to claim 1 , wherein the computer executable code is further configured to: update the policy file using the third correspondence, and use the updated policy file to monitor file integrity of the container.

8. The system according to claim 1, wherein the computer executable code is further configured to: after intercepting the second system call and before building the second correspondence, obtain the policy for the container from the policy file.

9. A method for monitoring file integrity of a plurality of containers in a host computing device, the method comprising: providing an agent in the host computing device external to the container and providing a policy file configuring a policy for the container; intercepting, by the agent, a first system call to one of the containers, the first system call indicating that a container file path is mounted to a corresponding host file path; The agent constructs a first correspondence between the container file path and the host file path; intercepting, by the agent, a second system call to the one of the containers, the second system call instructing to open the policy file, and the policy file including the container file path and a violation corresponding to the container file path; The agent constructs a second correspondence between the container file path and the violation; aggregating, by the agent, the first correspondence and the second correspondence to obtain a third correspondence between the host file path and the violation of the container; as well as The agent monitors the file integrity of the container by detecting violations of the host file path in the third correspondence.

10. The method according to claim 9, wherein each of the first correspondence and the second correspondence is identified by using an identifier cid of the container, and when the first correspondence and the second correspondence have the same cid, they are aggregated.

11. The method according to claim 10, wherein the cid of the first system call is defined based on the process identifier pid of the first system call, and the cid of the second system call is defined based on the pid of the second system call. 12 . The method according to claim 11 , wherein at least one of the pid of the first system call and the pid of the second system call is the same as the pid of a process that initializes the container.

13. The method of claim 11, wherein at least one of the pid of the first system call and the pid of the second system call is a derivative of the pid of a process that initializes the container.

14. The method according to claim 11, further comprising: A mapping between the process identifier and the container identifier is constructed so that the pid of the process can be converted into the cid of the process based on the mapping.

15. The method according to claim 9, further comprising: The policy file is updated using the third correspondence, and the updated policy file is used to monitor the file integrity of the container.

16. The method according to claim 9, further comprising: After intercepting the second system call and before constructing the second corresponding relationship: obtaining a policy for the container from the policy file.

17. A non-transitory computer readable medium storing computer executable code, wherein when executed at a processor of a computing device, the computer executable code is configured to: Providing a plurality of containers, agents outside the containers, and policy files for configuring policies for the containers; intercepting, by the agent, a first system call to one of the containers, the first system call indicating that a container file path is mounted to a corresponding host file path; The agent constructs a first correspondence between the container file path and the host file path; intercepting, by the agent, a second system call to the one of the containers, the second system call instructing to open the policy file, and the policy file including the container file path and a violation corresponding to the container file path; The agent constructs a second correspondence between the container file path and the violation; aggregating, by the agent, the first correspondence and the second correspondence to obtain a third correspondence between the host file path and the violation of the container; as well as The agent monitors the file integrity of the container by detecting violations of the host file path in the third correspondence.

18. The non-transitory computer readable medium of claim 17, wherein each of the first correspondence relationship and the second correspondence relationship is identified by using the identifier cid of the container, and when the first correspondence relationship and the second correspondence relationship have the same cid, they are aggregated; and The cid of the first system call is defined based on the process identifier pid of the first system call, and the cid of the second system call is defined based on the pid of the second system call.

19. The non-transitory computer-readable medium of claim 18, wherein at least one of the pid of the first system call and the pid of the second system call is the same as or a derivative of a pid of a process that initializes the container.

20. The non-transitory computer-readable medium of claim 19, wherein the computer-executable code is further configured to: update the policy file using the third correspondence, and monitor the file integrity of the container using the updated policy file.

Images